А можно ли изменить сам синтаксис языка в компиляторе или где нить там ?  
 я вот например хочу поменять begin на {, а end на }. (а коментарии сделать так : /*...*/ )
Реальноли это? если да, то где это менять? 

Это сообщение отредактировал(а) Burka - 30.5.2008, 15:19

В компиляторе нереально. Но можно попробовать поюзать препроцессоры, которые будут преобразовывать твой синтаксис к стандартному.

Нагуглил парочку:
1) Deex
2) http://andy.jgknet.de/dlang

Спасибо, попробовал Deex, но че то результат не порадовал, не удобно очень, компилировать постоянно через батник.

Ну это не С++
Паскаль - язык строгий. Вольностей не позволяет.
Так что только через внешний препроцессор, компиляция сторонняя, проверка синтаксиса отсутствует.
Паскаль не терпит подобных извращений.
Он от рождения строг и консервативен.
Как английский лорд обязан говорить на безупречном британском, так и программист на языках Вирта должен создавать чёткий, недвусмысленный код.
Такова суть строгих языков - не допускаются никакие разночтения.
А все кустарные поделки - кустарно и работают.
Если хочется лепить что попало и как угодно - это вам к плюсам.
Дельфи вольностей не допускает. Это строгий и чёткий язык.

извращенство, и вообще не понятно зачем это нужно



      

Snowy, точно, и в этом плюс Паскаля!  

Я подобными извратами занимался на Сях. Там это дело легко решается макросами.  А ща привык и begin-end нравятся даже больше...

Изменять синтаксис Delphi на синтаксис C++ - бред... Синтаксис Delphi - один из главных плюсов перед С++!
Хочешь использовать Delphi с синтаксисом плюсов - Borland C++.

А вообще - для мазохистов есть отдельные форумы.

Snowy, в каждой строчке одно и тоже написано   

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

А ни у кого нет исходников компилятора делфи?   

Эх... Нарываешся на минуса...
begin...end - это то, что удобно программистам Delphi. Не нравится - используй Borland C++. И хватит тут бред писать!

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

Со скобками есть проблема. При компиляции сторонних .pas файлов могут возникнуть Серьезные Проблемы из-за того что {комменты} будут третироваться как код.


Ищи free pascal compiler или gnu pascal compiler. 

Можешь ещё попробовать настроить Текстовой Редактор чтобы по нажатию на { вставлялось begin и по нажатитю на } - end.
Правда удалять их одной клавишей затрундительно.

ps. В мире есть ровно два Тектстовых Редактора: это vi(ныне его отпрыск vim) и emacs. Остальное - 


[flame mode]

Как жалок язык что синтаксис является его одним из главных плюсов перед с++. БУГАГАГА.  
[/flame mode]

Это сообщение отредактировал(а) Mayk - 31.5.2008, 05:50

Жалок не язык, а тот кто не умеет им пользоваться по назначению, пытаясь переделать, либо тот, кто не понимает плюсов языка. БУГАГАГА.

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

Господа паскалисты, что вы понимаете под "строгостью" синтаксиса. Просто я впервые вижу? что-бы данный эпитет применялся к синтаксису языка.  
С++ - язык со статической строгой типизацией, все проверяется в compile time, причем даже такие мелочи как возможное несоответстие размера указателя размеру переменной в которую его записывают в случае перехода на 64х битную платформу. 

Добавлено через 29 секунд

  

Аналог boost::lambda уже появился? 

Alexeis, ты не отвечаешь на мой ответ © , у тебя разрыв?

  Я что маньяк круглые сутки сидеть на форуме   .

Хочешь пример?


  Попробуй после это скомпилировать любую программу. Синтаксис не просто может меняться, его можно превратить во что угодно, так что потом не найдешь концов. 
Потом посмотри чего можно замутить в операторе if . Это ж форменное безобразие! Таких опасных фич. в синтаксисе десятки. Например структуры. Нет ни какой гарантии что они будут бинарно совместимы с чем нибудь. По правилам структуру можно пронаследовать от класса   
  Сравни с Delphi Record! Структура без возможности наследования, безо всяких виртуальных функций и деструкторов, чистые бинарные данные в строгом порядке. Можно создавать в стеке, по дефолту ни чем не инициализируется. Все четко и по делу. 
  На счет фигурных скобок, опять же они мелкие и плохо заметные, постоянно путаешься какая скобка от какого блока. Посмотри на синтаксис switch, не дай бог забыть break после очередного case. Идем дальше операторы цикла while. На кой черт он вообще сдался в С++  если есть цикл for, который его заменяет на 100%, намного лучше его и логичнее, включает в себя секцию инициализаций, секцию условий и секцию для пост операций преимущественно для инкремента счетчиков.
  Макросы - еще одно жуткое изобретение при наличии инлайн функций. Какое количество трудноанализируемых ошибок можно сделать на них!
  Межмодульное связывание extern  . Что с чем связывается? Где объявление? При том синтаксис допускает ЛОКАЛЬНОЕ связывание extern переменных. Ужоснах просто. Просто кладезь случайных ошибок. 
  Объявление функций классов. Можно запросто объявить функцию и ни где ее не реализовать. И это будет правильно. 

  Я согласен, что все это можно не использовать когда программу пишешь сам, но реальность такова, что помимо написания новых программ нужно осуществлять поддержку старых написанных другими людьми с их естественной кривизной рук. Уверяю тебя такого безобразия на Delphi встретить нельзя.
 

ну во первых, вся эта чертовщина унаследована от С, во вторых иногда это бывает нужно


эдакое самоубийство  


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



а что если он там и не нужен?









я им пользовался за всю жизнь 2 раза


зато пользователь класса видит только интерфейс класса, а не реализацию, намного меньше зависимостей в коде, например

foo.h


или

foo.h


foo.cpp


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

а как-же славные традиции писать программу в обработчиках событий    

Это сообщение отредактировал(а) Lazin - 31.5.2008, 14:45

 А чем begin..end путается хуже? ))
лезть в этот разговор не хотел, но прямо таки интересно стало )

P.S. ну раз все равно залез, то:
C++ - это гибкость.
Pascal - это строгость.

Естественно гибкий язык имеет бОльшие возможности, но строгость - тоже хорошо.

Например мне нравится делфи во всем, кроме синтаксиса паскалеподобного. Именно за строгость и однозначность.

 Везде такая традиция. Но только у нубов либо в программах уровня "хеллоуорлд".

 Кто это написал - тот дурак либо западлостроитель. Не ставь в пример дураков.


 Уверяю тебя, можно. Я в универе учился, у одногруппников такое видел =\
Причем везде. Самое сложное - это не разгребать код, а алгоритм. Сложно сть несоизмерима ;)
Так что разбор кода будем считать меньше погрешности.

надеюсь что нет  
Если это появится раньше полноценных замыканий/лямбд в дельфи (кстати как с этим в дельфи.нет?)  то это смерти подобно

Добавлено через 59 секунд
Жестокой! Беспощадной! Безжалостной смерти!

Добавлено через 9 минут и 48 секунд
А может разделим эту эпическую тему и половину выкинем нафик в релвойну к подобному треду?




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




И конечно же наименования элементов на форме(такая же феерия и на builder c++, да)

  Если он не нужен, то должна быть команда сквозного прохода. В С++ любят так делать. Фича используется в 1% случаев, а предусматривать обход нужно в остальных 99% случаев. 
 

  А мне приходиться дорабатывать софт где такие экстерны исчисляются десятками. 
 

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

На счет возможностей языка. 
  Попробуйте на С++ создать класс у которого будут 2е виртуальные функции с одним именем и одинаковым перечнем параметров или реализовать интерфейс без использования виртуальных методов, попробуйте делегировать реализацию интерфейса объекту члену класса. Или создать объект по его строковому имени. Можно ли в С++ вызвать функцию зная только ее имя (строка). Может ли статическая функция быть виртуальной? В Delphi можно реализовать полноценный Singleton вообще не создавая экземпляра класса.
  Как видите тонкими механизмами делфи не обделен тонкими механизмами, при этом он более логичен.
  Взять хотя бы циклы. Из 3х циклов нет ни одного лишнего. Цикл for только для целых и перечисляемых типов, цикл While с предусловием цикл Repeat с постусловием. Оператор выбора простой и очевидный. Если это функция так она и называется функцией, процедура называется процедурой. Если объявляется переменная, то будь добр пиши var, перешел к объявлению типа пиши type. А то объявил переменную фиг знает где, потом скопипастил код и закрыл имя переменной из внешней области. 
  Теперь пройдусь по массивам. В С++ некоторые вместо нормального a[i] умудряются писать *(a + 1), плюс в сочетании. Массив - указатель палка о двух концах. В функции никак не возможно определить что тебе передали массив или указатель. В Delphi строго, если передаешь указатель, то это указатель, если массив, то это массив. 

  Так что строгости в любом случае больше.

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

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

это как? как компилятор будет определять какую из них вызывать?



на то нам и дан паттерн NVI  

легко




да, рефлексии у нас нет


  как это можно использовать

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

  Это как?   

  В таком как в примере это никому и не нужно. При наследовании виртуальной функции, можно запретить предкам начиная с определенного колена вызывать виртуальную функцию того класса, который реально создан. Т.е. в одном из наследников вводиться новый виртуальный метод, точно такой же как и прежний, но с директивой reintroduce, после чего в таблицу VMT вводиться новая запись, а старая остается. Т.о. можно добиться разных действий, в зависимости от того к какому из предков был приведен объект. Довольно тонкий механизм, но в VCL используется.
  Статические виртуальные функции используются при приведении классов наследников к классам предов (не путать с приведением объектов). Фактически для класса создается своя таблица VMT. 
  На счет синглтона. В Delphi каждая статическая функция получает один неявный параметр как и обычная, но это не указатель на объект, а указатель на класс, т.е. ведет себя точно также как и обычная, можно определять статические поля, виртуальные статические функции, которые в наследнике перекрываются. Класс может иметь свои свойства, точно также как объект. Можно создать сколько угодно переменных класса и при этом это всегда будет тот же самый класс. Объявляется тип класса точно также как и обычный.

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



  Смотри при выходе из процедуры в Delphi ты пишешь exit, т.е. выхожу, в С++ тоже самое действие будет называться "возвращаю ничего".

  Код Delphi самоописателен. Чисто виртуальная функция пишется и директивой abstract, перекрыл функцию пиши override. Вызываешь виртуальный метод предка из перекрытого пишешь Inherited. Это по любому более читабельно, чем если ничего не писать.

Мне кажется совместимость с C сильно испортила язык С++.  Можно было обойтись раздельной компиляцией. Билдер, например, может скомпилировать код делфи, код C++ и слинковать в один исполняемый файл. И ни каких проблем.

Alexeis, 
1. в Delphi объекты классов можно создать в стеке?
2. можно ли определить свой аллокатор для класса? (аналог перегрузки new в С++)
3. есть ли аналог спецификатора volatile?
4. есть ли аналог элипсисов? (оператор ...)
5. можно ли создать массив в стеке с неконстантным значением числа элементов? (типа int array[count], где count - не константа)
6. есть ли аналог объединений? (union)
7. есть ли аналог mutable-полей?
8. есть ли возможность метапрограммирования?
9. есть ли аналог виртуального наследования?
10. есть ли встроенная поддержка комплексной арифметики?
11. есть ли аналог спецификатора restrict?

12. есть ли аналог ссылок
13. есть ли аналог модификатора const для параметров функций
14. есть ли спецификации исключений
15. какие возможности управления временем жизни объектов в стеке
16. можно-ли на Delphi реализовать функтор
17. можно-ли реализовать смарт-поинтер
18. можно-ли реализовать сборку мусора, используя только возможности стандартных библиотек

как уже задолбал этот холивар, Delphi-программисты не понимают что дают возможности языка С++, какие паттерны можно реализовать и тд. 
например идиома RAII, без нее очень сложно пользоваться исключениями... но в паскале это невозможно, так как там объекты классов не создаются в стеке, можно конечно сделать то-же самое с помощью finaly(наверное???), но это уже совсем не то, ведь это делается вручную а компилятор С++ делает такие вещи сам.
Конечно делфи для чего-то то-же хорош, наверное, но для чего конкретно я не знаю   

Только классические паскалевские (не VCL ские)

  Угу.

  Не знаю че за хрень
4. есть ли аналог элипсисов? (оператор ...)
  Тоже ни знаю че такое

  угу

  Не знаю че это такое

  Аналогично, звучит как-то абстрактно

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



  Не я его начал. Ты бы видел как изящно реализуются многие паттерны на Delphi. С++ просто нервно курит в сторонке.

грубо говоря
запрет кэширования переменной

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



функции с переменным числом параметров




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



можно ли в Delphi вычислить факториал константы во время компиляции?



требуется создать класс D, унаследованный от B, C, и при этом B, C, D будут использовать один и тот же объект A

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

перегрузка глобального new и boost threads?
(хотя boost threads вроде пока не стандартная)

Добавлено через 7 минут и 37 секунд

плохо
да и вообще, как-то паскаль и делфи не сильно со стеком дружат

  Это вообще, не имеет отношения к языку. Скорее директива определенного компилятора.


  Делается, но несколько иным образом через array of const, при этом число параметров получается автоматически. Кстати в С++ нельзя получить число элементов динамического массива, типа High(mas)    
 

  В этом смысле существует несколько другой механизм. Механизм ReadOny и WriteOnly свойств, ограничивающих возможность изменения состояния объекта.


  Класс будет использовать объект   . Чета тут перемудрили ИМХО.


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

Часть стандарта. 



Можно пример? Мне кажется, что использование массивов к эллипсису никакого отношения не имеет. 



Для этого, в прицнипе, и существуют стандартные STL-контейнеры. 



Нет, на самом деле всё просто.

Обычное наследование:


Виртуальное:

Да? А 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


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


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


Новая эпоха  

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

даже во FreePascal сие есть

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

к примеру, тыц

Добавлено через 5 минут и 19 секунд
оказалось, я все же не от Alexis'a услышал про  static-поля   

Понятно. Буду знать 

  

структура (record) может содержать методы? 



ничего опасного нет
при условии, что язык позволяет осуществлять полное управление жизненным циклом объекта



у нас наследование не обычное
без виртуального механизма будет создано 2 объекта A: по ветке B и ветке C
ладно, проехали, как тут уже сказали, в Delphi нет множественного наследования


читай пост Lazin
от себя замечу, что как я и предполагал, плохо и непродуманно Delphi работает со стеком
кроме того, я не получил ответа на вопрос: как куча в Delphi предотвращает возникновение приведенных тобой "проблем"?
тем, что ты явно вызываешь конструктор/деструктор?
извини конечно, но такой подход еще больше увеличивает вероятность ошибок


а вот здесь уже на вкус и цвет...



глупо
но и строгость не панацея



Это сообщение отредактировал(а) MAKCim - 2.6.2008, 09:17

Lazin, вот пример


  Как в этом случае спасти объект b? Его член member при создании вызвал исключение и вышел аварийно, требуется отработать эту ситуацию и пересоздать объект member или вообще отказаться от него.



  Привожу пример.



Все члены member1, member2, member3 повисли утечкой, хотя память выделенная под b будет возвращена в кучу. Если бы объект b был предварительно занулен, то для очистки member1 - member3 можно было вызвать деструктор ~b, а так это сделать невозможно, потому что в этом случае возникнет исключение в деструкторе на строчке delete member4; и настанет полный северный пушистый зверек, поэтому в С++ при возникновении исключения в конструкторе никогда не вызывается деструктор.


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

  Вот это и называется опасный код, не интуитивный код, который приводит к возникновению ошибок.

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


Да, в том числе конструкторы с параметрами, свойства и даже операторы.

есть. но объявления(интерфейса),  а не реализации. через абстрактные классы - т.н. interface
это к обсуждаемому виртуальному наследованию не относится, но уже столько раз звучало про "отсутствие множественного наследования", что не смог промолчать. 

создай объект в стеке и вставь в конструкторы - деструкторы брейкпоинты, и ты увидишь что в этом случае деструкторы вызываются
если-бы obj был смарт поинтером, например shared_ptr-ом, то и в твоем примере все будет нормально удалено

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

опять-же, здесь поля объекта - голые указатели, поэтому память освобождена не будет, если-бы это были объекты, то деструкторы были-бы вызваны...
если-бы здесь поля member были-бы смарт поинтерами, то все было-бы корректно удалено

Добавлено через 9 минут и 27 секунд
если написать это развернуто, то получится вот что



во время раскрутки стека вызываются деструкторы сконструированных объектов в порядке обратном их созданию, тоесть 

если member - голый указатель, то ничего не удалиться, так как у POD типов нет деструкторов, а если смарт поинтер, например auto_ptr, то его деструктор вызовет delete для объекта, который он содержит

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

никто не заставляет им пользоваться, однако в случае необходимости Delphi будет курить   

по поводу стека, ответом Lazin удовлетворен?    

  Первый код был примером не для утечек, а для исключений. См. выше. Здесь невозможно отработать исключение, с утечками тут все ОК.


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

Добавлено через 1 минуту и 17 секунд

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