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-контейнеры. 



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

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


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