Delphi vs C++ , Часть 1

[archimed7592]

Цитата Romkin @ 09.03.08, 14:58

Еще будешь цепляться к словам

. Просто не люблю, когда разбрасываются красивыми выражениями не соответствующими действительности.

Цитата Romkin @ 09.03.08, 14:58

- буду игнорировать. Терпеть не могу демагогов.

Я пойду в уголок, проплачусь, ладно?

Цитата Romkin @ 09.03.08, 14:58

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

Ок, давай не будем ссылаться на "флюсоватость" друг друга, а попробуем пойти академическим путём: есть Delphi без UUID'ов, встал вопрос о добавлении UUID'ов в язык(в том виде, в котором они присутствуют сейчас) - какие аргументы ты приведёшь за то, чтобы добавить эту ф-циональность в язык?

Цитата Romkin @ 09.03.08, 14:58

Кстати, насколько мне известно, именно в С++ такого понятия, как интерфейс, нет. Они эмулируются через абстрактные классы, не так ли?

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

Цитата Romkin @ 09.03.08, 14:58

Не беспокойся

Ромкин, сбрось обороты - я вообще то ни о чём не беспокоился.

Цитата Romkin @ 09.03.08, 14:58

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

Вообще говоря такая простота развития говорит об уровне языка. Возьми ту же Java - у неё нет Стандарта, но, тем не менее, нет такого стремительного развития, а всё потому, что Java широко применяется в ынтырпрайзе и имеет огромный комьюнити и не может себе позволить меняться по велению пятки левой ноги.
Из стремительно развивающихся технологий получается неповоротливый монстр, который потом развалится под своим же весом.

Цитата Romkin @ 09.03.08, 14:58

И по крайней мере, уж точно ничему не мешает и вполне универсален.

Возможность вставить в любое место программы слово "kukareku" тоже никому не помешала бы, но, тем не менее её нет - это я к тому, что то в чём нет острой необходимости в язык добавлять не нужно. Ну, впрочем, я тебя уже попросил привести аргументы в пользу добавления такой возможности в язык...

[--Ins--]

Цитата

Вообще говоря такая простота развития говорит об уровне языка. Возьми ту же Java - у неё нет Стандарта, но, тем не менее, нет такого стремительного развития, а всё потому, что Java широко применяется в ынтырпрайзе и имеет огромный комьюнити и не может себе позволить меняться по велению пятки левой ноги.

Java - язык новый. Pascal и C++ - относительно старые. Однако прогресс не стоит на месте, языки либо должны развиваться в ногу со временем, либо умереть. Вот чистый C уже можно сказать умер с той точки зрения, что для прикладного программирования практически не используется. Его основные области применения - это микроконтроллеры и прочий низкоуровневый код. Но и туда придет прогресс рано или поздно. Да и C++ судя по тенденции - загибается

[Romkin]

Цитата archimed7592 @ 09.03.08, 19:40

Еще будешь цепляться к словам

. Просто не люблю, когда разбрасываются красивыми выражениями не соответствующими действительности.

Что именно во фразе "обеспечивать встроенную в язык поддержку интерфейсов в полном соответствии с международными стандартами" не соответствует действительности? В Delphi интерфейсы обладают встроенными IID в соответствии с рекомендациями ISO/IEC 11578:1996. Фраза полностью верна

Цитата archimed7592 @ 09.03.08, 19:40

Ок, давай не будем ссылаться на "флюсоватость" друг друга, а попробуем пойти академическим путём: есть Delphi без UUID'ов, встал вопрос о добавлении UUID'ов в язык(в том виде, в котором они присутствуют сейчас) - какие аргументы ты приведёшь за то, чтобы добавить эту ф-циональность в язык?

Та, которая присутствует во вставшем вопросе, разумеется Это по поводу "добавлять или нет". А как добавлять - тоже понятно: так, чтобы один раз написал - и забыл, потому что человеку не особенно нужно его видеть.
Так что я бы сделал так, как есть сейчас: это наилучшее. Может быть, просто в квадратных скобках.
ТАк достигается максимальная абстракция и прозрачность. Опыт такого тоже есть: IDL. Я понимаю, что некоторые упертые сишники об IDL даже и не слышали, но он есть!

Цитата archimed7592 @ 09.03.08, 19:40

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

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

Цитата archimed7592 @ 09.03.08, 19:40

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

Скорее такой монстр уже получился из С++, с его нагромождением идиом.

Да что тут говорить, еще лет пять назад я понял, что такое знающий программист на С++: язык знает, но больше ничего. Не знает и знать не хочет. То, чего нет в С++ нет в природе, и это надо делать. Чтобы понять это, достаточно посмотреть реализацию внешних компонент в 1С

Добавлено 10.03.08, 08:06
"Строковые классы должны представлять строчки в виде граждан первого класса. Они абстрагируются от того, что строки — штуки сложные, и дают возможность работать с ними легко, ну прям как с числами. Почти все строковые классы C++ перегружают оператор +, и для конкатенации строчек можно писать s+"bar". Но как ни старайся, никакой на свете строковый класс C++ не даст вам написать "foo"+"bar", поскольку строковые литералы в C++ всегда имеют тип char*, а не string. Абстракция прохудилась так, что языком C++ её не заткнёшь. (Интересно, что историю развития C++ можно описать как историю затыкания дырок в абстракции строк. Уж не знаю, отчего бы не добавить к языку элементарный класс строчек.)"
(с) Джоэл Спольски

[Stratocoder]

Цитата Romkin @ 10.03.08, 07:57

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

Уж не знаю, отчего бы не добавить к автомобилю пятое колесо...

Добавлено 10.03.08, 09:38

Цитата Romkin @ 10.03.08, 07:57

Та, которая присутствует во вставшем вопросе, разумеется Это по поводу "добавлять или нет". А как добавлять - тоже понятно: так, чтобы один раз написал - и забыл, потому что человеку не особенно нужно его видеть.
Так что я бы сделал так, как есть сейчас: это наилучшее. Может быть, просто в квадратных скобках.
ТАк достигается максимальная абстракция и прозрачность. Опыт такого тоже есть: IDL. Я понимаю, что некоторые упертые сишники об IDL даже и не слышали, но он есть!

А что абстракция достигается не спомощью использования интерфейсов, а с помощью UUID'ов? И они уж никак не прозрачны (ни они, ни их использование).
И вообще, сам говорил о демагогии, а аргументов, о которых спросил Архимед, чето не видно...

[Romkin]

Цитата Stratocoder @ 10.03.08, 09:32

А что абстракция достигается не спомощью использования интерфейсов, а с помощью UUID'ов?

Абстракция достигается, когда есть отдельный абстрактный тип данных. Если вместо интерфейсов использовать абстрактный класс - это не абстракция, это костыль.
А идентификация интерфейсов по стандарту позволяет елинообразно и абстрактно общаться с интерфейсом, откуда бы он ни взялся. И если UUID в С++ это не пришей кобыле хвост - то в Delphi их вообще-то практически не видно, как раз очень прозрачно все
Какие аргументы еще нужны? Включить новый тип "интерфейс" с IID:
1. Удобно
2. Повышается уровень абстракции
3. Согласуется с идеологией языка, позволяет максимально скрыть детали реализации.
Все.
А теперь давайте аргументы против.

[trainer]

Дельфистов понесло...

Цитата Romkin @ 10.03.08, 10:31

Если вместо интерфейсов использовать абстрактный класс - это не абстракция, это костыль.

Абстрактный класс - это то, как называется интерфейс в C++. Я конечно понимаю, что нет пророков кроме дельфистов, но интерфейсы пришли из С, там они вообще оформлены в виде структур. Внесение отдельной категории типов interface в Delphi - вынужденная мера. Borland было необходимо и на елку забраться(угнаться за COM/OLE/ActiveX/CORBA) и ж..у не ободрать(получить двоичную совместимость с структурами/классами C/C++).

Добавлено 10.03.08, 11:45
У тебя вообще не возникало вопроса, почему интерфейсы COM в C++ просто получаются из абстрактных классов, а в Delphi для этого пришлось вводить interface?

Добавлено 10.03.08, 11:47

Цитата archimed7592 @ 09.03.08, 19:40

Возьми ту же Java - у неё нет Стандарта,

Справедливости ради - есть спецификация и есть набор тестов на совместимость виртуальной машины. И это одна из причин появления C# Судебное разбирательство между Sun и Microsoft по поводу виртуальной Ява-машины последней.

[--Ins--]

Цитата

Я конечно понимаю, что нет пророков кроме дельфистов

Секундочку! Т.е. к сишникам это выражение не относится, они себя пророками не считают?

Цитата

Абстрактный класс - это то, как называется интерфейс в C++

Абстрактный класс - это то, как РЕАЛИЗОВАН интерфейс в C++. Так как понятие интерфейс, как и класс, это термин ООП, а не какого-либо конкретного языка программирования. А реализован как класс он по всей видимости потому, что в C++ позволено множественное наследование реализаций. И дабы не плодить сущности, множественное наследование объявлений сделано аналогично и слабо отделено от наследования объявлений. В большинстве современных объектно-ориентированных языках от этого подхода (множественное наследование реализаций) благоразумно отказались

[AndNot]

Цитата archimed7592 @ 09.03.08, 19:40

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

Знаешь, а в асме тоже нет понятия символа, есть тип BYTE, и никто не жалуется Не пойми неправильно, но ты зря этим хвалишься, это прямая дорога ко многим проблемам, например при переносе программы под юникод Не зря же в плюсах не рекомендуется пользоваться этим типом для строк

Цитата archimed7592 @ 09.03.08, 19:40

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

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

Цитата archimed7592 @ 09.03.08, 19:40

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

Скорее наоборот, монстра напоминает С++, но никак не Дельфи, у которого синтаксис значительно проще и без подводных камней. Вот плюсы вполне могут загнуться под своими мудреными правилами и нюансами Что, не так? Ну посмотри на доки, сравни их объем. Для кодинга в Дельфи нужно немного знать и, главное, не обязательно знать все сразу, можно постепенно осваивать, а вот в плюсах нужно знать все, иначе есть риск налететь на "подводные камни", из-за плохой продусанности плюсов, что и не удивительно, учитывая историю этого недоязыка Впрочем это скорее относится к Си, так скать дедушке плюсов, от которого плюсы и унаследовали все недостатки.

[--Ins--]

Цитата

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

Ты прав. Собственно Вирт изначально и задумывал Pascal как язык, который будет приучать программиста к дисциплине, отсюда и строгая типизация и многое другое.

[Romkin]

Цитата trainer @ 10.03.08, 11:41

Абстрактный класс - это то, как называется интерфейс в C++. Я конечно понимаю, что нет пророков кроме дельфистов, но интерфейсы пришли из С, там они вообще оформлены в виде структур. Внесение отдельной категории типов interface в Delphi - вынужденная мера. Borland было необходимо и на елку забраться(угнаться за COM/OLE/ActiveX/CORBA) и ж..у не ободрать(получить двоичную совместимость с структурами/классами C/C++).

Мда. А сишники - скромники, значит. Все у них в С++ упирается... Угу. А объекты в Turbo Pascal по-твоему были введены для совместимости со SmallTalk? Или с Object C?
Говорить, что интерфейс это абстрактный класс - все равно, что сказать, что объект это набор данных и методов, которые с ним работают. То есть, не сказать практически ничего.
Знаешь, сделать двоичную совместимость со структурой в С++ можно по-любому. По крайней мере, при работе со структурами WinAPI особых проблем не наблюдается.
Более того, очень рекомендую почитать Дональда Бокса, "Философию СОМ", хотя бы первую главу. Он особенно подчеркивает, если мне не изменяет память, что интерфейс - это не абстрактный класс, это отдельная абстракция, не зависящая от языка. Собственно, это универсальный контракт, который может быть реализован и без спользования ООП, как правильно и упомянуто.
Да, можно сказать, что интерфейсы в Delphi были введены изначально для удобной работы с COM. Или CORBA - да как угодно. Но уже с начала века это стало полной абстракцией. Для чего есть интерфейсы в Java? Там ведь это тоже отдельные сущности, а отнюдь не классы.
Я понял, что сишники просто не знают реализации интерфейсов в Delphi. Не буду в очередной раз говорить, почему Просто покажу.
Я уже приводил описание некоторого интерфейса:

type
  IFoo = interface(IInterface)
  ['{98B1D125-A102-4566-9CE6-978AE71A2B0A}']
    procedure Bar;
  end;

У него есть IID. Для чего? Для COM или чего еще? Достаточно заглянуть в справку: для уверенной работы оператора as.
Этот интерфейс - для внутреннего применения, и я специально указал предком IInterface. Эта конструкция, вообще говоря, должна работать на любой платформе: привязки нет. Впрочем, уверенно утверждать не могу, но на Kylix это тоже должно работать, правда, понятия не имею, что такое IInterface там .
Следующее: IID не выделен в константу, прошу обратить внимание. Хотя хорошим тоном считается определение константы IID_Foo и употребление ее, но совершенно не обязательно. Просто потому что IID не нужен. Он нужен только компилятору, программист же употребляет имя интерфейса. Поэтому вполне логично встроить IID в объявление интерфейса: привязка выполняется только один раз.
Если интерфейсы и родились из С, то это совершенно не значит, что их реализация в С++ (а точнее, отсутствие таковой) - верх совершенства. Если посмотреть, то можно найти с полдюжины языков, в которых интерфейсы реализованы тем или иным способом, и не всегда точно так как в С++ (скорее, только не так)

[Flex Ferrum]

Romkin, ты, по-моему, немного путаешь курицу и яйцо, и не совсем понимаешь некоторые вещи. Давай разберемся.
Не знаю, что там пишут авторы книжек по COM, по этому обращусь к википедии:

Цитата

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

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

Цитата Romkin @ 10.03.08, 20:58

Говорить, что интерфейс это абстрактный класс - все равно, что сказать, что объект это набор данных и методов, которые с ним работают. То есть, не сказать практически ничего.

не совсем корректно, т. к. абстрактный класс - это один из способов описания интерфейса, применяемый в языке С++ (кстати, не единственный). В Delphi, Java и C# для этого используются другие способы, специфичные для этих языков.
Теперь едем дальше. Пока мы остаемся на уровне языка, поддерживающего интерфейсы как концепцию (например, перечисленные выше), то операторы наподобие as, dynamic_cast, is и прочие, предназначенные для динамического приведения типов, прекрасно работают на базе встроенного в язык RTTI. Это верно (по крайней мере) для С++, С# и, уверен, Java, т. к. ни в том, ни в другом, ни в третьем не требуется введения дополнительных сущностей (типа UUID) для преобразования экземпляра одного интерфейса в экземпляр другого интерфейса. И это логично, т. к. компилятор обладает полной информацией о типах и интерфейсах, описанных в компилируемом им исходном тексте, и может поместить эту информацию в результирующий код (это, собственно, и называется RTTI). Другими словами, в случае мало-мальски развитого RTTI UUID'ы интерфейсам не нужны, т. к. интерфейсы и так могут быт однозначно идентифицированны самим компилятором и (в последствии) средой исполнения. А когда же они нужны? А нужны они тогда, когда мы покидаем лоно родного языка, и выходим на простор межъязыкового взаимодействия. Тут все совсем по другому, т. к. нет стандарта на RTTI (если это не .NET Framework), нет стандартов на описание интерфейсов и прочее. Но жить то как-то надо, по этому (будем рассматривать на примере COM) и был введен стандарт (в рамках системы) на бинарную структуру интерфейсов (как перечень указателей на функции, в них декларированных), а также были введены всчяческие UUID'ы, GUID'ы, CLSID'ы, TYPEID'ы, и проч. проч. проч. ID'ы. Цель их введения - сделать минимальный межъязыковой аналог RTTI (тут, кстати, надо еще вспомнить про TLB). Чтобы интерфейс, описанный и реализованный в виде объекта на C# мог быть корректно использован в программе на C или на ассемблере. И наоборот. Также был предложен базовый интерфейс IUnknown, предоставляющий минимальный набор функций, предназначенный для контроля времени жизни объекта (посредством интрузивного подсчета ссылок), а также получения указателей на поддерживаемые интерфейсы.
А из утверждений:

Цитата Romkin @ 10.03.08, 20:58

У него есть IID. Для чего? Для COM или чего еще? Достаточно заглянуть в справку: для уверенной работы оператора as.
Этот интерфейс - для внутреннего применения, и я специально указал предком IInterface.

у меня получается сделать следующий вывод:
1. Delphi не поддерживает неявную идентификацию интерфейсов в среде выполнения (т. е. ее RTTI не так хорош, как его тут малюют)
2. (как следствие) Delphi использует в качестве RTTI для интерфейсов явно указываемые UUID'ы и возлагает обязанность по их созданию на программиста, что (на мой взгляд) несколько странно.
3. (как следствие) Delphi имеет определенные завязки на COM, т. к. ни в каком другом языке (из тех, с которыми я работал) нет специальных языковых конструкций, используемых для навешивания на интерфейсы UUID'ов (в С++ этого вообще нет, в C# для этого используются метаатрибуты классов, но там метаатрибутика используется много для чего еще, в Java - и быть не может, т. к. изначально формировалась в другой среде).
4. Либо говорящий не совсем понимает, о чем вообще ведется речь, и откуда у чего ноги растут.
Так ли это?

Добавлено 10.03.08, 22:10

Цитата Romkin @ 10.03.08, 20:58

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

Ну, если посмотреть в сторону C#, то там интерфейс реализован вообще хитро. Реализация методов интерфейса ищется не только в том классе, который явно описан, как реализующий интерфейс, и наследниках этого класса, но также и в предках этого класса (по сигнатуре метода интерфейса). Вот это - реализация интерфейса, как языковой конструкции. Подозреваю, что Delphi тут и рядом не стояло, и, подозреваю, что единственное отличие группы методов и свойств, описанных как interface, от аналогичного набора методов и свойств, описанных как class, заключается в том, что первый может учавствовать во множественном наследовании интерфейсов, а второй - увы, нет...

[archimed7592]

Цитата Romkin @ 10.03.08, 07:57

Та, которая присутствует во вставшем вопросе, разумеется Это по поводу "добавлять или нет". А как добавлять - тоже понятно: так, чтобы один раз написал - и забыл, потому что человеку не особенно нужно его видеть.
Так что я бы сделал так, как есть сейчас: это наилучшее. Может быть, просто в квадратных скобках.
ТАк достигается максимальная абстракция и прозрачность. Опыт такого тоже есть: IDL. Я понимаю, что некоторые упертые сишники об IDL даже и не слышали, но он есть!

Это аргументы?
Ладно, смотри, стоит вопрос "добавлять ли в язык возможность декомпозиции на ф-ции?".
Аргументы:
1) декомпозированный код прост для понимания
2) легко локализовывать ошибки и производить отладку
3) возможно повторное использование кода
4) и т.д.(надеюсь, что аргументы "за" возможность декомпозиции для всех очевидны).
Дык вот, в таком же духе: зачем нужен UIID как языковая конструкция? что эта конструкция позволит делать, чего мы не смогли бы сделать без неё? и т.д.

Цитата Romkin @ 10.03.08, 07:57

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

C#, Pascal, Delphi, VB, PHP, Java, ... продолжать?
А насчёт зоопарка со строками: как строки связаны с символами? Только тем, что строка есть последовательность символов? Вот это действительно смешно .

Цитата Romkin @ 10.03.08, 07:57

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

M

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

Цитата Romkin @ 10.03.08, 10:31

Включить новый тип "интерфейс" с IID:
1. Удобно
2. Повышается уровень абстракции
3. Согласуется с идеологией языка, позволяет максимально скрыть детали реализации.

Касательно конкретно IID:
1. Чем?
2. Как? Почему?
3. Бог мой, а детали реализации здесь вообще каким местом?

Цитата trainer @ 10.03.08, 11:41

Borland было необходимо и на елку забраться(угнаться за COM/OLE/ActiveX/CORBA) и ж..у не ободрать(получить двоичную совместимость с структурами/классами C/C++).

Ну да, ещё нужно было ввести интерфейсы, а множественное наследование воодить не хотелось .

Цитата --Ins-- @ 10.03.08, 12:16

И дабы не плодить сущности, множественное наследование объявлений сделано аналогично и слабо отделено от наследования объявлений.

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

Цитата --Ins-- @ 10.03.08, 12:16

В большинстве современных объектно-ориентированных языках от этого подхода (множественное наследование реализаций) благоразумно отказались

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

Цитата AndNot @ 10.03.08, 14:15

Знаешь, а в асме тоже нет понятия символа, есть тип BYTE, и никто не жалуется Не пойми неправильно, но ты зря этим хвалишься, это прямая дорога ко многим проблемам, например при переносе программы под юникод

А при чём тут Юникод? Или, может быть, в Дельфи не различается AnsiChar и WideChar? Или же поставлю вопрос иначе: с какими такими проблемами переноса на Юникод столкнётся С++ программист и не столкнётся Delphi-программист?

Цитата AndNot @ 10.03.08, 14:15

Не зря же в плюсах не рекомендуется пользоваться этим типом для строк

Извини, что повторяюсь, но, каким местом ты сюда строки приплёл? Я про символы говорил...

Цитата AndNot @ 10.03.08, 14:15

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

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

Цитата AndNot @ 10.03.08, 14:15

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

Если выкинуть из С++ все те возможности, которых лишён Delphi(т.е. не пользоваться ими), то доки по оставшимся возможностям будут такими же по объёму(если не меньше). Знать всё не нужно: просто не нужно изображать из себя обезьяну с калашем в руках пытаясь пользоваться теми возможностями С++, которыми пользоваться не умеешь. Я с тем же успехом нарвусь на кучу подводных камней, если попытаюсь реализовать хороший COM-сервер на Delphi, без соответствующих знаний и опыта.

Цитата Romkin @ 10.03.08, 20:58

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

А какое отношение имеют POD-структуры WinAPI к С++?

Цитата Flex Ferrum @ 10.03.08, 22:00

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

Не совсем - у интерфейсов в Delhi есть ещё некое подобие GC .
Вот это меня поражает в языке больше всего .
К примеру, Java и C# [почти] все заботы об освобождении ресурсов берут на себя.
С++ предоставляет широчайший выбор: от полностью автоматического управления ресурсами(RAII) до полностью ручного управления(вплоть до собственных пулов для маленьких объектов и т.д.
И особняком стоит Delphi со своим блоком var в начале ф-ции, а как следствие, полностью ручной инициализацией всех переменных и, главное, деинициализацией. И тут, их величество интерфейсы ни с того ни с чего умеют подсчитывать ссылки(это на уровне языка/language core).
Да, я верю, что это кроссплатформенная особенность, но, пусть первым кинет в меня камень тот, кто считает, что эта особенность была добавлена не из соображений простоты работы с COM - вот это я и называю рющечками: взята конкретная платформа(win32), конкретная технология(COM) и добавлена рющечка в язык, чтобы проще было жить программистам под эту конкретную платформу и эту конкретную технологию.

Ещё один пример стройности архитектуры в др. языках против разброда в Delphi.
Есть языки, которые не имеют строгой типизации и, как следствие там разрешено пихать в любую переменную что угодно(число, строку, объект). К примеру PHP. Там можно совершенно не имея представления о типе объекта просто написать obj->foo(1, 2, 3); - если такой метод у объекта есть, то он будет вызван, если нет - будет run-time ошибка.
С др. стороны, есть типизированные языки, такие как Java или C# - в них можно запихнуть что угодно в переменную типа object, но, чтобы вызвать какой-нибудь метод нужно, либо привести object к какому-нибудь конкретному типу/интерфейсу, либо воспользоваться механизмами рефлексии(reflection), которые в язык не встроены - некая виртуальная машина предоставляет эти механизмы.
И теперь сравнить всё это с Delphi . К TObject можно привести только его наследников, но никак не втсроенные типы аля integer, double, boolean, string и т.д. Но не всё так плохо - есть некоторой тип variant в который можно засунуть что душе угодно. Что же касается механизмов рефлексии - они есть отдельно, но, зачем-то во встроенный тип variant встроили возможность на уровне языка писать variantObj.foo(1, 2, 3). Зачем нужно было добавлять эту рюшечку в язык? Может быть потому что механизмами рефлексии настолько неудобно пользоваться? А может быть просто потому что так удобнее программировать под COM? И это ли не рюшечки?

Господа Дельфисты, признайте уже, что Delphi - это Windows-only язык/компилятор и т.д., а программирование на Kylix столь же широко распространёно, сколько сайтостроение на С++.

[Romkin]

Цитата Flex Ferrum @ 10.03.08, 22:00

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

Взято отсюда: Интерфейс (объектно-ориентированное программирование)
Таким образом, интерфейс - это, в первую очередь, контракт, который обязуются поддерживать классы, его реализующие. ООП не накладывает никаких специальных требований на то, как именно этот контракт должен быть реализован в языке. Главное, чтобы таковая возможность вообще была. По этому говорить:
Цитата (Romkin @ Вчера, 23:58)
Говорить, что интерфейс это абстрактный класс - все равно, что сказать, что объект это набор данных и методов, которые с ним работают. То есть, не сказать практически ничего.

не совсем корректно, т. к. абстрактный класс - это один из способов описания интерфейса, применяемый в языке С++ (кстати, не единственный). В Delphi, Java и C# для этого используются другие способы, специфичные для этих языков.

Брр. Чем отличается то, что сказал ты, от того, что сказал я? Я с самого начала утверждал, что интерфейс - абстракция, и нельзя говорить, как именно он обязан реализоваться.

Цитата Flex Ferrum @ 10.03.08, 22:00

Теперь едем дальше. Пока мы остаемся на уровне языка, поддерживающего интерфейсы как концепцию (например, перечисленные выше), то операторы наподобие as, dynamic_cast, is и прочие, предназначенные для динамического приведения типов, прекрасно работают на базе встроенного в язык RTTI.
<skip>
Другими словами, в случае мало-мальски развитого RTTI UUID'ы интерфейсам не нужны, т. к. интерфейсы и так могут быт однозначно идентифицированны самим компилятором и (в последствии) средой исполнения. А когда же они нужны? А нужны они тогда, когда мы покидаем лоно родного языка, и выходим на простор межъязыкового взаимодействия.

Все абсолютно верно.

Остаток - ниже

Сообщение отредактировано: Romkin - 11.03.08, 07:51

[--Ins--]

Цитата

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

А не нужно "подозревать" и бросаться голословными "Delphi тут и рядом не стояло" У меня такой код - компилируется и работает, что я делаю неправильно?

type
  IMyPersist = interface
    procedure Assign(Source: TPersistent);
  end;
 
  TMyStream = class(TGraphic, IMyPersist) // Метод Assign присутствует в классе TGraphic и именно к нему будет привязан интерфейс. Объявлять и реализовывать в классе Assign не нужно
  end;

Однако с вышесказанным, что в Delphi интерфейсы сделаны совместимыми с COM - согласен, я это уже говорил. Но совместимые - не есть привязанные. Они прекрасно могут быть использованы, и используются (я далек от COM, но интерфейсы в моем коде фигурируют повсеместно) и без этой технологии. Кстати, совместимость с COM не делает язык платформозависимым. Если бы существовали другие реализации языка от других фирм (кстати, я не знаю как интерфейсы реализованы во Free Pascal, так что конкретным примером подтвердить не могу), в нем вовсе не обязательно было бы использовать именно такой способ идентификации интерфейсов. Стандарта идентификации интерфейсов в Delphi - нет, так что можно считать что это лишь особенность реализации языка под конкретный компилятор, который предназначен для конкретной платформы.

[trainer]

Кстати.

Цитата Romkin @ 10.03.08, 07:57

Опыт такого тоже есть: IDL. Я понимаю, что некоторые упертые сишники об IDL даже и не слышали, но он есть!

И ты наверное не поверишь, но IDL-компиляторы генерируют файлы на C/С++. Правда, Borland и тут вывернулась, состряпав на Java пакет idl2pas.jar. Удивительное дело. Абстрактные классы, получается, костыль, но именно их генерируют IDL-компиляторы. А не такие превосходные и удобные интерфейсы Delphi. Это "жжжжж" наверное неспроста?