Delphi vs. C++

← →
Суслик © (2004-09-06 11:38) [40]

> Григорьев Антон © (06.09.04 11:34) [38]

мне не хватает:
1) друзей классов
2) private конструторов и деструкторов (т.е. никто не может создать и удалить объект - только статический собственный метод).
3) статических переменных.

← →
Игорь Шевченко © (2004-09-06 11:48) [41]

Григорьев Антон © (06.09.04 11:34) [38]

> Единственное, чего лично мне не хватает в ООП-модели Delphi
> - это возможности создания объектов в стеке, чтобы они автоматически
> освобождались, когда переменная выходит из области видимости.

AFAIK, классы, объявленные не через class, а через object позволяют такое. Впрочем, за давностью лет, могу ошибаться.

Суслик © (06.09.04 11:27) [35]

У каждого языка свои возможности. Ну и что ?

← →
wicked © (2004-09-06 11:49) [42]

Григорьев Антон [38] прав, этого ну очень не хватает...
а вот с этим
> чем, от этого отказываются не только в Delphi, но и в других
> языках (если не ошибаюсь, в той же Java)

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

а вот в списке
> 1) друзей классов
> 2) private конструторов и деструкторов (т.е. никто не может
> создать и удалить объект - только статический собственный
> метод).
> 3) статических переменных.

необходим только пункт 2 (если такого нету конечно, поправьте меня)... остальное прекрасно осуществляется таким средством языка, как модуль...

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

ЗЫ всё высказанное в этом постинге является имхо"м, и может быть преосмысленно и переоспоренно.... :)

← →
Суслик © (2004-09-06 11:55) [43]

> Игорь Шевченко © (06.09.04 11:48) [41]
> У каждого языка свои возможности. Ну и что ?

Ты сказал, что у каждого языка свои возможности. Ну и что?

Если по сути, то - ничего. Я что-то НЕсубъективно утверждал? Если нет, то какое может быть всем дело до моего субъективного мнения? А высказываться тут вроде никто не запрещал?

← →
Думкин © (2004-09-06 11:57) [44]

> [43] Суслик © (06.09.04 11:55)

Субъективное мнение имеет один недостаток - оно может оказаться не объективным.

← →
Суслик © (2004-09-06 12:02) [45]

> Субъективное мнение имеет один недостаток - оно может оказаться
> не объективным.

А это недостаток? :))) На то и есть субъективное мнение.
Если я считаю, что мне так лучше - то так лучше. Я же никого не заставляю делать также - я просто поделился мнением.

← →
wicked © (2004-09-06 12:06) [46]

> Игорь Шевченко © (06.09.04 11:48) [41]

> AFAIK, классы, объявленные не через class, а через object
> позволяют такое. Впрочем, за давностью лет, могу ошибаться.

Цитата из справки Delphi 6 (топик Object types, в конце):
Object types are supported for backward compatibility only. Their use is not recommended.

как видим, проблема есть, поскольку единственный способ не рекомендуют...

← →
Игорь Шевченко © (2004-09-06 12:06) [47]

Суслик © (06.09.04 11:55) [43]

> Если по сути, то - ничего.

Если по сути, то не стоит делать далеко идущих выводов о преимуществах объектной модели одного языка над другим.

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

← →
Акуличев Дмитрий (2004-09-06 12:11) [48]

> Единственное, чего лично мне не хватает в ООП-модели Delphi
> - это возможности создания объектов в стеке, чтобы они автоматически
> освобождались, когда переменная выходит из области видимости.
> Впрочем, от этого отказываются не только в Delphi, но и
> в других языках (если не ошибаюсь, в той же Java). Почему
> - я так и не понял.

Всё с точностью до наоборот, не "от этого отказываются не только в Delphi, но и в других языках", а Ц++ -- чуть ли не единственный язык, где это было.

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

← →
Суслик © (2004-09-06 12:20) [49]

> Игорь Шевченко © (06.09.04 12:06) [47]

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

Все же хочу заметить, что во всех своих высказываниях я упоминал термин "компилятор" или глаголы он него.

Способов полно (например, newinstance+freeinstance), но все они будут работать в runtime.
Если интересно, далее могу объяснить, чем runtime плох.

По сути единственный способ предложил ЮЗ - написать эксперта с проверкой кода перед компиляцией.

Никто другой не предложил ( и не может этого сделать ) способа создания private конструктора и деструктора, уровень видимости которых отследживался бы во время компиляции.

← →
Акуличев Дмитрий (2004-09-06 12:23) [50]

> мне не хватает:
> 1) друзей классов

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

> 2) private конструторов и деструкторов (т.е. никто не может
> создать и удалить объект - только статический собственный
> метод).

Ой... А это зачем?

> 3) статических переменных.

Т.е. ещё одного костыля...

← →
Суслик © (2004-09-06 12:25) [51]

Удалено модератором
Примечание: Offtopic

← →
Суслик © (2004-09-06 12:26) [52]

Удалено модератором
Примечание: Offtopic

← →
Ермак © (2004-09-06 12:29) [53]

Может, немного не втему, но... Если уж народ начал сравнивать ООП в языках...
Очень советую посмотреть книжку: Г. Саттер. Решение сложных задач на С++.
Я тоже думал, что ничего осбенного не узнаю, типа, какая разница, на чем писать?
В результате - узнал столько тонкостей об ООП-проектировании, которые даже и в Дельфи оказались полезны. После прочтения класики о С++ (СТрауструп, например, и Саттер) понимаешь, зачем нужен С++. Он не лучше Дельфи, а просто другой. Такой мощности обобщенного программирования нет почти ни в одном языке.

← →
Суслик © (2004-09-06 12:32) [54]

> Такой мощности обобщенного программирования нет почти ни
> в одном языке.

сейчас получишь на орехи от знатоков.

ЗЫ. Я во многом согласен с тобой в этом высказывании. Чем дальше изучаю с++, тем больше чую в нем именно то, что ты описал.

← →
Акуличев Дмитрий (2004-09-06 12:41) [55]

Удалено модератором
Примечание: Offtopic

← →
lipskiy © (2004-09-06 12:48) [56]

Господа, правильно ли я понимаю, что каждый язык изначально создавался для решения каких-то определенных типов задач? Иначе как объяснить изобилие языков? А если это так, то для каких конкретных типов задач были изначально задуманы C и Pascal (и их модификации)?

← →
Kerk © (2004-09-06 12:49) [57]

> Суслик © (06.09.04 12:25) [51]

Все же соглашусь с Дмитрием, что friend-классы - это скорее костыль.

← →
}|{yk © (2004-09-06 12:51) [58]

Тот же Дэвид Парнас говорит, что имено С++ является причиной того, что ООП не стал до сих пор основной парадигмой в программировании. Сложность языка - не показатель его "крутости"

← →
pasha_golub (temp) (2004-09-06 12:51) [59]

Удалено модератором
Примечание: Offtopic

← →
Ермак © (2004-09-06 12:53) [60]

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

Позвольте не согласиться. Вся беда в том, что у большинства занкомство с языком С++ начиналась в 90-е годы на Борланд С++, когда еще не было нормального стандарта языка. Если кто не знает: последний полный стандарт С++ - 1998 год. То что раньше - это либо не совсем, либо вообще не С++.

Так вот, в С++ есть полная поддержка модульности. Это простарнства имен (namespaces). И, кстати говоря, очень удобно, что они не привязаны к конкретному файлу, а могут быть раскиданы так, как тебе хочется. То, что я говорил о С++, основывается на реальном опыте решения задачи, решить которую в рамках ООП Дельфи было бы на несколько порядков сложнее. Чего стоит одна невозможность перекрестного подключения модулей! В С++ я знаю, что смогу реализовать ЛЮБУЮ взаимосвязь между сущностями, которую захочу. Но если для конкретной задачи не нужна сложная иерархия сущностей, то я безусловно выбираю Дельфи.

← →
wicked © (2004-09-06 12:54) [61]

> lipskiy [56]

> Господа, правильно ли я понимаю, что каждый язык изначально
> создавался для решения каких-то определенных типов задач?
> Иначе как объяснить изобилие языков? А если это так, то
> для каких конкретных типов задач были изначально задуманы
> C и Pascal (и их модификации)?

именно pascal задумывался, как язык обучения программированию...
а c задумывался, как заменитель ассемблера (в чём он может конкурировать только с фортом)...
но здесь сравнивать пытаются object pascal и c++ - это не pascal и c...

← →
Ega23 © (2004-09-06 12:58) [62]

Мда, Holy War....

← →
lipskiy © (2004-09-06 12:59) [63]

> но здесь сравнивать пытаются object pascal и c++ - это не
> pascal и c...

Это я понимаю, но разве C++ вырос не из С, а object pascal не из pascal?
Причины развития каждого направления - это тоже отдельный вопрос. С чего начинался каждый путь - это одно, и каким путем пошел каждый... путь - это другое, и тоже интересно.
Выходит что оба языка в итоге развились к состоянию, способному решать одни и те же типы задач? Не так ли?

← →
Ермак © (2004-09-06 13:01) [64]

lipskiy © (06.09.04 12:48) [56]
>>Господа, правильно ли я понимаю, что каждый язык изначально >>создавался для решения каких-то определенных типов задач? >>Иначе как объяснить изобилие языков? А если это так, то для >>каких конкретных типов задач были изначально задуманы C и >>Pascal (и их модификации)?

Изначально C - высокоурвневый "ассемблер" для платформы Юникс. Pascal - обучающий язык. Теперь C не нужен почти никому кроме системщиков низкого уровня.

C++ - это не С, это абсолютно другой язык.
Object Pascal - это не Pascal, а язык абсолютно другого уровня.
Хотя общая концепция сохранилась: основная идея Delphi - помочь решить почти любую задачу с минимальными затартами времени. Основная задача С++ - дать возможность решить задачу именно так, как вы сами того хотите, то есть оптимизацией либо по времени написания, либо по расширяемости кода.

>>Тот же Дэвид Парнас говорит, что имено С++ является причиной >>того, что ООП не стал до сих пор основной парадигмой в >>программировании. Сложность языка - не показатель его "крутости"

Между прочим, это так. Эталоном ООП является Smalltalk. Это действительно очень интересный динамический язык, который по быстроте разработки и ошибкобезопасности не имеет себе равных. По многим причинам коммерческого распротсранения не получил. Зато его виртальная машина в сильно обкоцанном виде была использована Sun при разработке Java/

← →
pasha_golub (temp) (2004-09-06 13:01) [65]

А что правда, то что написано в интервью Страуструпа?

← →
Акуличев Дмитрий (2004-09-06 13:02) [66]

> Господа, правильно ли я понимаю, что каждый язык изначально
> создавался для решения каких-то определенных типов задач?

Не правильно. Многие классы задач появились только после появления тех или иных языков. До того эти классы задач просто вообразить было трудно.

> Иначе как объяснить изобилие языков?

Примерно так, как и изобилие видов животных -- эволюцией.

← →
Ozone © (2004-09-06 13:04) [67]

jack128 © (06.09.04 11:38) [39]

И ты в это веришь? Он где-то на своем сайте сам сказал, что это все стебы.

← →
lipskiy © (2004-09-06 13:07) [68]

> основная идея Delphi - помочь решить почти любую задачу
> с минимальными затартами времени.

Значит я сделал правильный для себя выбор! Это радует.

> > Иначе как объяснить изобилие языков?
>
> Примерно так, как и изобилие видов животных -- эволюцией.

Ясно, везде бардак, хаос, спонтанность...

← →
Акуличев Дмитрий (2004-09-06 13:28) [69]

> Так вот, в С++ есть полная поддержка модульности. Это простарнства
> имен (namespaces). И, кстати говоря, очень удобно, что они
> не привязаны к конкретному файлу, а могут быть раскиданы
> так, как тебе хочется.

А в словарик за словом "модуль" заглянуть?

Нэймспейсы -- это не поддержка (тем более -- ха-ха! -- полная) модульности, это даже не её имитация. Это ещё один костыль при её (модульности) полном отсутсвии. Костыль для обхода одной из проблем, которые возникают, когда программа собирается -- концептуально, я не рассматриваю тут технические ухищрения различных сред (опять костыли!) -- как один большой исходный текст.

> Чего стоит одна невозможность перекрестного подключения
> модулей!

Т.е. опять не хватает недостатка -- свалить всё в один большой исходник.

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

>>Акуличев Дмитрий
Зачем столько эмоций? Еще раз скажу: ЕСТЬ широкий класс задач, в которых перекрестно связанные объекты невозможно хорошо реализовать на Дельфи без тройного а то и более уровня косвенноых ссылок и потери наглядности. Как я буду писать - в виде ли одного большого исходного текста - или каждый намеспасе в отдельном файле - это уже мое дело, а дело среды - предоставить мне как можно больше вариантов.
В простых задачах мое мнение о том, как нужно писать программы, приблизительно совпадает с Борландовским - и я использую Дельфи. В том же случае, если я считаю, что что-то нужно реализовать по другому (напр, через множественное наследование), а среда мне этого не позволяет, я не собираюсь подлаживаться под среду, я просто напишу на том, на чем я могу напрямую воплотить свою концепцию.

> Ермак © (06.09.04 13:57) [72]

Моличи, Илюха - у тебя налицо недостаток мышления. :))

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

Хм. А кто сказал, что в Борландовском Паскале нет перекрестного подключения модулей?! Типа A uses B и B uses A? Что мешает? Лень в справку по uses глянуть?
Ермак © (06.09.04 13:57) [72] Есть множественное наследование в Delphi. Пользуйте интерфейсы. И, на мой взгляд, с интерфейсами это самое наследование гораздо прозрачнее.
Подытоживая, единственное, чего нет в Delphi по сравнению с C++ - это шаблонов. Еще, пожалуй, inline методов.
Все остальное - есть. Аналоги.

Да ну, перекрестное подключение в С++ - это такой головняк, какое же это преимущество

> Romkin © (06.09.04 14:14) [74]

> Есть множественное наследование в Delphi

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

> Подытоживая, единственное, чего нет в Delphi по сравнению
> с C++ - это шаблонов

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

> Все остальное - есть. Аналоги.

Хи...

> Суслик © (06.09.04 14:24) [76]

> Romkin © (06.09.04 14:14) [74]

Про имитацию множественного наследования интерфесами.
Хотел бы добавить, что такую конструкцию можно назвать множественное наследование ИНТЕРФЕЙСА класса, но никак не реализации. Реализацию можно имитировать интерфейсы + делегирование, т.е. когда классы, с которыми непосредственно работает пользователь, ничего не делают сам:
1) реализуют интерфейсы (т.е. смотри на класс с любой стороны)
2) реализацию делегируют. (т.е. запускай меня через любой интерфейс, а я (класс) просто предам твой вызов своему подчиненному объекту).
Но все же это не то - это не множественное наследование.

И не понимаю я этих войн. Мне на практике не встречались задачи, которые я не мог бы решить с комфортом на Delphi.
Причина, кстати, весьма банальна - Объектный паскаль гораздо проще в изучении, нежели С++. Посмотрите хотя бы на объем Lang Ref :)
Поэтому, увы, в среде программистов на DElphi довольно большая доля, хм, как бы помягче... программистов низкой квалификации. Отсюда и сложилось постепенно мнение, что Delphi - для ламеров, а нормальные пацаны только на сях программируют.
В 96-97 годах была, между прочим, абсолютно обратная ситуация: многие программисты (и хорошие программисты!) перешли с C++ на Delphi. Тогда Delphi была безусловно лучшим инструментом программирования под Windows. И никому в голову не приходило ее хаять или сравнивать с VB или VC ;)
Теперь - отстой и устарело. Во-первых, обидно. Во-вторых, абсолютно несправедливо :))
А в-третьих, через пять лет отстоем будет C# :) К этому идет: простой язык, многое, очень многое взявший от Паскаля. И будут топики, подобные этому, правда, с чем его будут сравнивать - я сказать затрудняюсь. Может, это будет "отстой" по сравнению с C++, может - с Delphi.
Я не берусь гадать. Я не берусь заявлять, что какой-то язык умирает или уже умер. Я просто программирую на том, что мне нравиться. Нравится сейчас, а не через пять лет.

Суслик © (06.09.04 14:28) [77] Пусть. Мне, собственно, пофигу, как называют, лишь бы в печь не ставили. Если что-то, что нельзя назвать множественным наследованием, позволяет тожесамо, что и это самое множественное наследование... И, кстати, прозрачнее :)
То нафиг мне нужно множественное наследование в С++?
Мне, если честно, множественное наследование вообще ни разу не понадобилось :))
>Вот видишь, и ты находишь, что в сях есть то что нет в дельфи.
И что? А в Delphi есть то, чего нет в сях, и что с того?

Delphi vs. C++ Найти похожие ветки