Да? А std::vector<t>::size() для кого?

Добавлено через 4 минуты и 3 секунды
Кстати в паскале нельзя вычислить факториал в compile time.

ps. а в си++ нельзя вычслить синус - 

но тссс, это секрет.

  Так это ж класс...

это стандартная замена массива

ИМХО Дельфям глубоко плевать на ФП.


  


Смысл непонятен. Только проблемы ИМХО 


Стоп. А в Дельфи разве есть статические поля?


В С++ они унаследованы от С, потому в оч недобном виде. Ими, по-моему, никто не пользуется (в плюсах).


Записи с вариантами?


Дык множественного ж вроде нет - зачем виртуальное?!


Немного оффтоп. Какие компилеры на сегодня юзают рестрикт для оптимизации?


Да - const  Причём AFAIK для 32-битных (или меньше) типов аналогично передачи по значению. Иначе - константная ссылка.


Delphi .Net?  


AFAIK только глобально. Разве я не прав?


Эт которые с object вместо class? Если да - тогда фтопку, точно не помню, но помню, что это нечто кривое и недоделанное 


А какое отношение это имеет к mutable?


Нелогично  


Нетипизрованный массив, если я правильно понял, как-то можно в дельфях передавать в функцию. Как затем юзать - фиг его 


Ну, в С++ тоже много чего нельзя в компайл-тайм (не тот язык всё-таки) - так что кодогенераторы рулят  

Насчёт виртуальных конструкторов и виртуальных статических методов - респект. Гуд 

ЗЫ Блин, хорошая вещь холивары  

В справочной системе приведен пример:

Для последней версии Dephi можно для прохода использовать оператор for..in..do


Прямого аналога нет, но для вызовов функций, там, где в С++ любят использовать ссылки, используется оператор @

Это сообщение отредактировал(а) Rrader - 1.6.2008, 17:42

Действительно, хорошая штука 

  Неправ, память для классов выделяет виртуальная статическая функция, которую можно переопределить для любого класса и все наследники этого класса автоматом будут использовать ее для выделения памяти, потому что конструктор в Delphi это статическая функция класса с дополнительными скрытыми вызовами. 


  Ну не то чтобы кривое, просто старый механизм. Есть целая библиотека KOL которая живет этим механизмом, код получается самый чистый и маленький, они то как раз ближе всего к классам С++.


  Как я понял это механизм ограничения доступа к полям данных. Тут оно работает несколько другим образом. Доступ к свойству можно ограничить или расширить в наследнике, передавая объект как предка. В отличие от С++, здесь можно свойство поднять из private в public, при необходимости в наследнике расширить доступ к свойству или функции. Нельзя требовать от языка, чтобы он полностью повторял механизмы другого. В замен одного механизма может быть совершенно другой или два заменяют один. Соответвтенно алгоритмы и структура программы строиться по другому. Так вот ограничить часть свойств так чтобы их нельзя было изменить при передаче в функцию возможно.


Что именно нелогично? То что если внутри объекта возникнет исключение, то вся динамическая память которая была выделена до того повиснет ввиде утечки? Это логично? Или логично, то что проверка принадлежности указателя на базовый класс к наследнику при помощи is пройдет, а попытка использования базового как наследника при помощи as провалиться в исключение, потому что видите ли это не первый базовый класс, а лишь второй, а второй базовый уже для этого не годиться. Или то что при присваивании стековых объектов поля копируются лишь бинарно, потому все внутренние объекты созданные в куче будут одним, а потом, когда уничтожат второй объект, деструтктор упадет на AV потому что объект поле был у них общим и его уничтожил первый владелец, а второй уже удаляет мусор. Чего дальше перечислять все особенности "безопасной" работы с объектами в С++? Или все таки согласишься, что большой объект должен иметь встроенные механизмы безопасности, а простой можно создавать хоть у черта на рогах. Будте уверены, что создание объектов в куче это не глупое ограничение, а серьезный механизм безопасности и исключения случайных ошибок при работе с памятью.

Добавлено через 2 минуты и 15 секунд

  var параметр это как раз такой параметр, который передается по ссылке, а @ это аналог &

Mayk, спасибо за максимально полный ответ и за то что он по теме =)



да, я думал над этим. я бы написал программку которая конвертирует исходники под мой синтаксис, это не сложно.



Как вариант подходит, но крайне удобно перед каждой компиляцией это проделовать. даже через батник будет не то   

Еще подумаю может чего придумаю.

вот-вот. делаешь внешний препроцессор в виде расширения ide и подключаешь к среде разработки ;) уж извини, для таких экзотических требований готовых решений либо нет, либо совсем уж никому неизвестные.

ну, скажем так: после привычной модели штука выглядит... .ээээ... коряво. но если уж сильно хочется иметь в стеке объект - то решение есть. разве нет?

статические методы есть и в 6(насколько помню, работать начал с 7-ки). статические поля, насколько помню, уже в BDS 2005 есть. кстати, об этом узнал от Alexis'a, так что он точно скажет.

это, как уже заметили, стандарт
в низкоуровневом коде volatile встречается повсеместно


потому что в С/С++ нет понятия динамического массива   
нет вообще динамических массивов
есть указатели
указатели относятся к простым типам данных

я даю 95%, что динамический массив в Delphi - это ни что иное, как объект соответствующего класса, только он завуалирован синтаксисом Delphi, т. е по сути является встроенным
приведи ассемблерный листинг функции, работающей с динамическим массивом, сразу все станет видно



не то
вот пример mutable




скажем так, при создании объекта D, создается только один объект A


больших это сколько?


а если объект маленький, но структурой не представим (нужна семантика класса)?   
не гибко и притянуто за уши


GCC



а причем здесь стек и куча?
если объекты в куче выделяются ничего не повиснет?   



это все от того, что в Delphi нет конструкторов копирования, перегрузки operator= и т. д  
в С++ настраивается любое поведение


это именно глупое ограничение (читать абзац выше)

skyboy, расширения ide - ты имеешь виду что то типа плагина делать для делфи или просто прогу отдельную. 
И вообще как плагины делать? Где про них понятней написано?

Это сообщение отредактировал(а) Burka - 1.6.2008, 20:40

  Он может все кроме того что связанно с наследованием, даже больше.


Большие это те которые содержат вложенные или пронаследованы, т.е. включаются опасные механизмы.
 

  Все равно не ясно, зачем создавать 2 объекта, при наследовании и так создается только 1 объект В наследник A, объекту A не зачем создаваться, это же наследование, а не композиция.



  Это часть общего механизма безопасности объектов. Если объект создается в стеке, то его конструктор вызывается в неопределенное время и деструктор тоже, потому его нельзя поместить в блок try...except и правильно отработать исключения. Аналогично происходит в случае глобальных объектов. Кроме того объекты в C++ не инициализируются нулями, потому при возникновении исключения в конструкторе, нельзя вызвать деструктор, так как в последнем невозможно узнать какие из вложенных объектов уже были созданы и соответственно уничтожить только их, ведь если в объекте мусор, то указатели не нулевые. Исключение в конструкторах для Delphi это не критическая ситуация, а механизм сигнализации о неверных параметрах.
  

  Все в Delphi есть, но дело не в том что можно все сделать правильно, а в том, чтобы язык не давал лишней возможности для возникновения трудно анализирумых ошибок. Можно все делать правильно, но факт остается фактом, что ошибки в программах исправляются годами и количество совершаемых в средней программе исчисляется сотнями, потому задача языка свести к миниму возможности появления.
  При разработке программы не исходят из того, что в ней не будет ошибок, порядочный программист при написании программы должен понимать что ошибки будут, однозначно будут, их не избежать и нужно так спланировать написание ПО, чтобы все ошибки легко находились, поэтому безопасность ООП это не последнее дело в программировании.


  Глупо надеятся что можно писать идеальные программы без ошибок с идеальной структурой, где предусмотрено все на все случаи жизни. 

я понял в чем твое заблуждение, на самом деле все происходит немного не так как ты думаешь. стандартом четко определен порядок создания и удаления стековых объектов, в С++ порядок вызова деструкторов всегда противоположен порядку создания объектов

стек, он на то и стек, что-бы все работало по принципу FIFO
если где нибудь в функции возникнет исключение, то стековые объекты будут удалены в порядке обратном их созданию

часто в С++ делают так, например есть класс Mutex - который работает как мьютекс  , тоесть используется для синхронизации чего-то в многопоточной программе



обычный способ его использования



если между вызовами enter и leave, произойдет исключение, то это приведет к блокировке программы, все встанет колом  

так вот, можно описать такой класс


это все))

теперь в коде можно писать вот так

исключения в конструкторах в С++ - нормальное явление, деструкторы для полей объекта вызываются, следуя все тому-же принципу... 
и вообще там все происходит намного интереснее чем ты думаешь, инициализация нулями отношения к делу не имеет никакого =)

Добавлено через 3 минуты и 21 секунду

конструкторы копирования и операторы присваивания, никогда небыли источником ошибок  


модульные тесты не помогают?  

господа, а почему, собственно, обсуждение не продолжается в pascal vs с++?!
зачем нам клоны?

Вообщем-то да. Компилер вставляет вызовы внутренних функций рантайма. Даже присваивание для них переопределено (работает reference counting, в частности).


+1


Красиво сказал 


А чем эт они опасны?!


Новая эпоха  

Хотелось бы узнать - что там со статическими полями? В современной дельфе. Для общего развития