С++ Builder и Delphi

← →
AlexG © (2004-06-22 16:17) [0]

Разница понятна - в языке. И схожесть понятна - почти Delphi. И все-таки хочется узнать: на сколько они друго от друга отличаются и на сколько похожи? Можно ли сказать, что это почти одно и тоже или нет?

← →
Reindeer Moss Eater © (2004-06-22 16:20) [1]

Первое - тупиковоя ответвление. Второе - жизнеспособный продукт.

← →
AlexG © (2004-06-22 16:25) [2]

Да, но некоторые продолджают програмировать на Builder...

← →
Reindeer Moss Eater © (2004-06-22 16:26) [3]

И что?

← →
AlexG © (2004-06-22 16:31) [4]

Работу предлагают.

← →
Игорь Шевченко © (2004-06-22 16:33) [5]

> Работу предлагают.

И ты, натурально, решил переложить ответственность на обитателей форума

← →
Paul © (2004-06-22 16:39) [6]

> [1] Reindeer Moss Eater © (22.06.04 16:20)
> Первое - тупиковоя ответвление. Второе - жизнеспособный
> продукт.

Почему же. Бизнес-логику делают на С++, а интерфейс на VCL. Примерно такая же комбинация как Visual Basic и С++, только в билдере удобнее.

← →
AlexG © (2004-06-22 16:45) [7]

Игорь Шевченко
Какую ответственность? Ты о чем?

← →
TUser © (2004-06-22 16:48) [8]

Если честно, это одно и то же. Слово begin, конечно, в 5 раз круче фигурной скобки, ибо в 5 раз длиннее, + бонус за то, что не надо жать шифт. Но и к тому и к другому можно привыкнуть.

В билдере менее удобно работать с дин. массивами, так что если размер задачи заранее не известен, то гораздо лучше - Delphi. Кроме того, по delphi существенно больше литературы, как бумажной так и электронной. И хелп у билдера плохой. Хотя на билдер почти все переводится один в один, но по Дельфовому хулпу и литературе Delphi изучать все-таки удобнее, чем все остальные языки. Многие компоненты поставляются в 2х вариантах - для D и для CB, но есть те которые толко для delphi. Людей, котрые пишут на Delphi больше, т.е. больше вероятность получить ответ на вопрос в форуме.

← →
PVOzerski © (2004-06-22 16:52) [9]

BTW, в состав Builder"а входит компилятор Delphi. Так что если не "засвечивать" свои исходники :^)...

← →
AlexG © (2004-06-22 16:56) [10]

PVOzerski
Да уж. Вот это хитрость! А может перед компиляцией Builder транслирует все в Delphi? :)

← →
Reindeer Moss Eater © (2004-06-22 16:57) [11]

Почему же. Бизнес-логику делают на С++, а интерфейс на VCL. Примерно такая же комбинация как Visual Basic и С++, только в билдере удобнее.

Ой!
И чем это бизнес логика реализованная на C++ удобнее такой же реализованной не на C++?

Интерфейс на VCL?
На VCL, написанном на OP

только в билдере удобнее.
Тема не про VB, а про билдер и Delphi. Тем более что "удобнее" - очень субъективное понятие.

← →
Paul © (2004-06-22 16:57) [12]

> [8] TUser ©
> В билдере менее удобно работать с дин. массивами...

STL для этого есть.

← →
Paul © (2004-06-22 17:04) [13]

> Ой!
> И чем это бизнес логика реализованная на C++ удобнее такой
> же реализованной не на C++?

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

← →
Reindeer Moss Eater © (2004-06-22 17:07) [14]

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

Вся бизнес логика, даже самая изощренная, редко выходит за рамки четырех арифметических действий.

← →
Игорь Шевченко © (2004-06-22 17:08) [15]

По-моему скромному мнению C++ Builder лично мне неудобен тем, что VCL-таки на паскале со всеми вытекающими, а язык программирования - С(++)

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

Reindeer Moss Eater © (22.06.04 17:07)

> Вся бизнес логика, даже самая изощренная, редко выходит
> за рамки четырех арифметических действий.

Ну да, а Буч, Фаулер, Гамма сотоварищи натурально, даже этих действий не знают

← →
Paul © (2004-06-22 17:15) [17]

> [14] Reindeer Moss Eater © (22.06.04 17:07)
>
> Вся бизнес логика, даже самая изощренная, редко выходит
> за рамки четырех арифметических действий.

Человек думает и рассуждает не арифметическими действиями, а скорее объектами (существительными), взаимодействиями между ними (глаголами) и атрибутами. Не арифметика сложна, а логика задачи.

← →
Reindeer Moss Eater © (2004-06-22 17:16) [18]

Не арифметика сложна, а логика задачи.

И для этого конечно же позарез необходимо множественное наследование.

← →
Игорь Шевченко © (2004-06-22 17:17) [19]

Reindeer Moss Eater © (22.06.04 17:16)

> И для этого конечно же позарез необходимо множественное
> наследование.

А в ряде случаев очень удобно, кстати. Мне иногда в Delphi его сильно не хватает, писать приходится больше, код распухает

← →
Reindeer Moss Eater © (2004-06-22 17:18) [20]

Что бы было совсем понятно - я пытаюсь разглядеть преимущества объектной модели C++ билдера над моделью OP

← →
Игорь Шевченко © (2004-06-22 17:19) [21]

> Что бы было совсем понятно - я пытаюсь разглядеть преимущества
> объектной модели C++ билдера над моделью OP

Чтобы было совсем понятно - нельзя ли поподробнее об этих самых моделях, а то, может оказаться, что мы на разных языках говорим

← →
Reindeer Moss Eater © (2004-06-22 17:23) [22]

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

← →
Paul © (2004-06-22 17:23) [23]

> И для этого конечно же позарез необходимо множественное
> наследование.

Его применять никто не заставляет.
"Множественное наследование это как запасной парашют. В большинстве случаев он не нужен, но иногда он спасает когда под рукой" (автор не помню кто). Да и множественное наследование не главное.

← →
Paul © (2004-06-22 17:24) [24]

> логику, которую заметно удобнее реализовывать на C++.

Не заметно удобнее, а иногда проще.

← →
Игорь Шевченко © (2004-06-22 17:27) [25]

> Особенно после поста про бизнес логику, которую заметно
> удобнее реализовывать на C++.

Если читать внимательно тот пост, то слово "удобнее" относилось к Visual Basic.

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

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

← →
Reindeer Moss Eater © (2004-06-22 17:29) [26]

Хорошо.

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

В общем-то поспорить не с чем. Тем более, что количество информации в таком утверждении совсем невелико.

← →
blackman © (2004-06-22 17:30) [27]

>Всякий овощ приносит пользу, будучи употребленным надлежащим образом в надлежащее время.
Из сказанного следует, что нельзя есть все подряд :)

← →
Игорь Шевченко © (2004-06-22 17:32) [28]

> Из сказанного следует, что нельзя есть все подряд :)

Можно. Но не постоянно

← →
Paul © (2004-06-22 17:38) [29]

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

← →
}|{yk © (2004-06-22 17:39) [30]

А я-то бизнес-логику реализую на тригграх/сохраненных процедурах,
на PL-SQL или Interbase SQL. Или ты по другую бизнес логику?

← →
Reindeer Moss Eater © (2004-06-22 17:40) [31]

Про бизнел логику на клиенте и в среднем звене

← →
Игорь Шевченко © (2004-06-22 17:42) [32]

}|{yk © (22.06.04 17:39)

Дело в том, что бизнес-логика, она не обязательно наличие SQL-сервера подразумевает. Кроме того, для общения с сервером базы данных тоже ведь нужны какие-то классы иногда.

ЗЫ: Ты хоть пиши, к кому обращаешься :)

← →
J_S © (2004-06-22 18:17) [33]

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

← →
}|{yk © (2004-06-22 18:20) [34]

Посмотри хотя бы функцию
Format

← →
wl (2004-06-22 18:33) [35]

Откровенно говоря у билдера есть ОООЧЕНЬ большой недостаток - слишком долгое время компиляции при достаточно большом проекте, нажимаешь f9 и можешь курить бамбук...

← →
J_S © (2004-06-22 18:36) [36]

2 }|{yk
ну через массив можно сделать - это понятно... это я конечно же знаю:))...эдак и на любом другом языке извернуцца можно:)))

но я говорю немного про другое - есть ли в Дельфях аналоги va_arg, va_end?... то есть СПЕЦИАЛЬНО для этого.

← →
Mystic © (2004-06-22 18:48) [37]

Не знаю. Мне С++ просто неудобен, хотя я начинал с языка С. У паскаля более академический стиль, что доставляет больше удовольствия. Несколько цитат (не всегда разделяю мнение авторов):

Вирт: "Инструменты программирования должны вести к корректным программам естественно, а НЕ ПРИ ПОМОЩИ исключительных интеллектуальных упражнений!".

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

Я эти годы на освоение С++ так и не пожертвовал. О чем не жалею.

--

Если Вы задаетесь вопросом, является ли это уместным, только взгляните на состояние развития программного обеспечения после 50 лет практики. Несмотря на весь теоретический прогресс, большинство кода все еще опасно нестабильно, что ярко показано неудачей Microsoft, которая не способна предоставить операционную систему, которая является хоть в вполовину такой же устойчивой, как старые многопользовательские системы от IBM и DEC. И это после миллиардов и миллиардов долларов, брошенных на развитие Windows! До сих пор мы наблюдаем многочисленные "переполнения буферов" и прочие подобные ошибки, которые напрямую связаны с кодом на C/C++. Недавний exploit Outlook""а использует специфическую слабость обрабоки исключений на C++, связанную с обычным плачевным управлением памятью в этом языке.

--

Программирование немного подобно этому, но тут появляется компьютер. Он может проверить ваш код при переводе (это то, что делают компиляторы). Только удостоверитесь, что любое "предложение" кода очень точно. Если не имеется никакого риска измененить значение кода, изменяя отдельный знак, то Вы должны сделать прекрасный код. Даже лучше, почти любое случайное изменение нескольких знаков должно быть отклонено как неверное, прежде, чем будет сделан любой вред. Но всё не так для C/C++. Односимвольные ошибки возможны во многих местах и не будут обнаружены компилятором.

Тут мне вспоминается несколько неестественное
if (0 == func1()) proc1();

--

Марсианский зонд СССР, вышедший из атмосферы Земли 27 ноября 1971 разбился при посадке на поверхность Марса, потому что его ракета-носитель сломалась. Отказ был из-за единственной ошибки знака в алгоритме приземления, который был написан на ФОРТРАНе. Это было прерывание цикла ожидания вида "FOR I=1,1000", который не исполнился должным образом, потому что запятая была заменена точкой, что скомпилировалось как "FORI=1.1", переменной "FORI" было присвоено значение "1.1"

--

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

--

Да, C++ огромнен и имеет кучу возможностей... но сколько из них фактически используются?

Недавно я делал некоторую консультантскую работу для Немецкого Банка и имел шанс поработать с их командой разработчиков. Когда я рассматривал код их главного приложения, мне потребовалось время, чтобы понять, что оно, фактически, было написано на C++. Код выглядел скорее как Java или Modula-2 исходник (если не принимать во внимание {}). Говоря с лидером проекта, я узнал, что они имеют очень строгие руководящие принципы программирования:

* одна инструкция на строку
* каждая инструкция с комментарием
* НИКАКОГО множественного наследования
* НИКАКИХ макросов
* НИКАКИХ "generic" (не-объектных) модулей
* НИКАКИХ перегрузкок операторов
* НИКАКИХ причудливых выражений в стиле C, только основные операторы
* Соглашения по именованию строго определены

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

← →
Mystic © (2004-06-22 18:48) [38]

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

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

--

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

--

Народ! Ведь не за горами очередная революция в области полупроводниковой техники. И гораздо раньше, чем вы ожидаете! Вы не боитесь, что она приведет к изменению не только архитектуры компов, но и к необходимости пересмотра самих принципов построения программ (в общеархитектурном смысле)? Ну, например, полетит к чертовой бабушке само понятие наследования. Я серьезно! (Кто хочет поподробнее обсудить эту тему - милости просим! Жду вопросов) Да, так вот, что тогда? Вы что, еще раз расширите С++ добавлением новых синтаксических уродств? А нет риска, что они придут в противоречие с имеющимися? И вы опять нагрузите имеющиеся в языке слова еще несколькими значениями? Или добавите новые? Да, еще не забудьте о новых библиотеках (и стандартах)! А еще надо обеспечить совместимость со старьем! Сколько страниц будут занимать руководства по ++С++ (или С**, или С!!) через 10 лет? Вы спросите: Ну, мужик, а ты-то что предлагаешь? А я ничего не предлагаю! Я за виртовскую линию языков спокоен. Может быть она и останется не столь популярной, но кардинальных изменений не претерпит. И не потому, что костна или неповоротлива. Просто в основе ее лежат строгие математические основания (а не сиюминутные модные поветрия)

Не так давно M$ хвастались, что их компилятор соответствует стандарту на 98%. И я подумал --- это же какой стандарт надо было придумать, чтобы через столько лет его смогли почти выполнить ;)

--

Кто-то упомянет о .NET, но она появилась только сейчас, а виртовскому детищу уже около пятнадцати лет! Так что же? Вся эта братия во главе с Мелкософтом пыхтит, раздувает щеки, произносит фразы, но в конце концов приходит к принципам, заложенным командой Вирта (только в других формах). Так не лучше ли изначально не водить народ сорок лет по пустыни (чего кстати никогда не было...), а прямо заняться внедрением умных вещей с умной организацией. Или по-прежнему нам будут тыкать в лицо аргументами совместимости, соблюдения стандартов и массового переучивания народа? Но, что касается первого: а не дороже ли обходится поддержание старого маразма в рабочем состоянии (и попыток его развития), чем построения новых аккуратных систем? А по поводу второго: ТЕ стандарты тоже когда-то были приняты... По третьему же замечу, что когда-то ходила шутка, что даже внутри IBM никто полностью не знает PL/1. Это я к тому, что не дороже ли обходится обучение народа кучеобразному нагромождению средств в языке, все нюансы которого знают только гуру, чем показ средства, воплощающего на практике основные подходы и принципы построения программных систем?

--

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

--

Простой и примитивный - не одно и тоже. Автомат Калашникова - простой. Дубина - примитивна. Кстати, если проводить параллели, АК - Паскаль, М-16 - С++ (особенно в части сочленения магазина и коробки - но это уже для спецов...).

← →
vuk © (2004-06-22 18:49) [39]

to J_S © (22.06.04 18:36) [36]:
>то есть СПЕЦИАЛЬНО для этого
А зачем?

← →
Mystic © (2004-06-22 18:49) [40]

ЧЕЛОВЕЧЕСКИЕ качества важны для организации здоровых отношений в коллективе. На счет выбранного языка реализации: одной кафедре нужно было засветиться в оборонном ведомстве одной из эсенгешных держав. Необходимо было сделать (очень быстро!) пилот-проект с достаточно навороченным интерфейсом пользователя. Это был 1993 год. Технику помните? Безденежье? Решили интерфейс делать на турбо-вижине. Скомпилировали одну из демонстрашек на Паскале - 23 секунды. Тот же пример на С++ - 45 минут. Вопросов ни у кого не было...

--

Не путайте ООА/ООП2 с программированием на конкретном языке. На первое ГОДЫ уходят по причине новизны и продолжающегося процесса формирования самих взглядов и подходов. На второе тратятся годы по причине искуственно привнесенной сложности, перегруженности и распухнутости (есть такое слово?) (и непомерных амбиций?).

Первое конечно стоит, чтобы его изучать!

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

C++ -- это просто попытка добавить новые возможности в старый язык C (да так, чтобы не нарушить совместимость). Автор C++ (Страуструп, если кто не знает) никогда не делал исследований, могущих послужить доказательством необходимости и удобства тех "рюшечек", которые были добавлены в язык (о чём Страуструп, кстати, сам пишет в своей книге по C++: "Формальной спецификации языка никогда не было. Мы придумывали что-то, и сразу добавляли это в компилятор". Кулибины, блин. Ketmar). Страуструп включил в язык всё, что можно было: множественное наследование, шаблоны, перегрузку операторов... все те рюшечки, от которых так "балдеют" цисты.

--

Проблема: Отсутствие модулей
Описание:
Модули признаны фундаментальными строительными блоками для программ с конца восьмидесятых годов. Modula-2 -- важный (но, естественно, не единственный) член (извините... Ketmar) семьи модульных языков. Пакеты есть в Ada, нечто похожее имеется в Java и Eiffel. У C++ есть include-файлы. Так в чём тогда проблема?
* В C++ нет концепции "локальности". Все глобально. Когда вы объявляете глобальную переменную, процедуру или класс в вайле CPP, это потенциальный конфликт с любой переменной, имеющей то же имя и находящейся в другом CPP-файле, который будет прилинкован к программе. Можули же предоставляют пространства имён "бесплатно".
* Модуль -- важный структурный элемент, который хорошо представляется в UML-диаграммах. Модуль -- это не просто файл, и класс чаще всего не заменитель модулю. Взаимоотношения между классами могут быть установлены внутри модуля, уничтожая необходимость в "дружественных" ("firend") отношениях. Зависимые классы могут быть расширены "снаружи", если они экспортированы, что невозможно для дочерних классов в C++.
* Использование классов для инкапсуляции и как заменителей модулям -- преступление в программировании. Это полностью уничтожает концепцию ООП, что ведёт к синтаксическим и семантическим проблемам. В процессе анализа становится невозможно отделить одни сущности от других. Но такой подход -- единственная возможность преодолеть недостаток C++ (отсутствие модулей). И подход этот создаёт кучу новых проблем.
* Символьные файлы намного увеличивают скорость компиляции. Любая компиляция, импортирующая заголовочные файлы Windows будет "ползать" в C++

Проблема: "Неквалифицированные" идентификаторы
Описание:
При использовании общего механизма #include невозможно определить, из какой секции кода (не говоря уже о том, из какого файла) пришёл данный идентификатор. Он может быть определён в том же самом файле, в заголовочном файле, в заголовочном файле, который используется в другом заголовочном вайле, и так далее... Вот почему программисты на C/C++ стремятся использовать огромные префиксы и неудобные имена для любых идентификаторов, которые описаны в заголовочных файлах. Эти префиксы, естественно, не определены жёстко раз и навсегда, они должны базироваться на каких-то соглашениях. Неправильно написанные или пропущенные префиксные строки не вызовут со стороны компилятора никаких нареканий.

← →
Mystic © (2004-06-22 18:51) [41]

Ну и несколько цитат отсюда: (статья Редкая профессия)

http://beda.stup.ac.ru/psf/ziss/wmaster/books/magazine/pcmag/9705s/05S979.htm

Не знаю, решились бы мы на этот проект [разработка компилятора С++], если бы сразу представляли (так, как знаем сейчас) его истинную трудоемкость. Тогда язык Си++, судя по учебным пособиям, казался нам... да, непростым для компиляции, с корявым и неоднозначным синтаксисом, сильно усложненной семантикой традиционных конструкций, но вполне сравнимым, например, с объектной версией Паскаля фирмы Borland. Так что срок, названный шефом, поначалу не вызвал у нас протеста. Однако чтение первой же действительно серьезной и подробной книги - перевода авторского определения языка [1], предложенного в качестве начальной версии для его стандартизации, повергло нас в ужас и панику. Казалось, это безумие невозможно реализовать вообще!

--

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

--

Во-вторых, в синтаксисе есть неоднозначности. Это надо оценить: в Стандарте (!) языка программирования прямо написано, что некоторые конструкции можно трактовать двояко - либо как объявление, либо как оператор! В несколько упрощенном виде формулировка из стандарта выглядит так: "выражение, содержащее в качестве своего самого левого подвыражения явное преобразование типа, которое записано в функциональном стиле, может было неотличимо от объявления, в котором первый декларатор начнается с левой круглой скобки". Классический пример: что такое T(a); если T - некоторый тип? С одной стороны, это как бы объявление переменной с именем a, тип которой задан как T. С другой - конструкцию можно трактовать как преобразование типа уже объявленной где-то ранее переменной a к типу T. Все дело в том, что в Си++ статус операторов и объявлений полностью уравнен; последние даже и называются declaration-statements - операторы-объявления, то есть традиционные операторы и объявления могут записываться вперемежку. Все же радости с круглыми скобками перекочевали в Си++ прямо из Си, в котором типы конструируются подобно выражениям, и тривиальное объявление можно задать либо как "int a;", либо как "int(a);". Все это понятно, но от этого не легче. И такой язык любят миллионы программистов?! Мир сошел с ума. Яду мне, яду!..

← →
Mystic © (2004-06-22 18:51) [42]

Смысл правил разрешения неоднозначностей сводится, по существу, к поразительной фразе, простодушно выведенной в "Зеленой книге": "если конструкция выглядит как объявление, то это и есть объявление. В противном случае это оператор". Иными словами, чтобы разрешить неоднозначность, следует рассмотреть всю конструкцию целиком; фрагмент "T(a)" для анализа недостаточен - за ним сразу может следовать либо точка с запятой, тогда выбор делается в пользу объявления, либо "что-то еще". Например, вся конструкция может выглядеть как "T(a)->m = 7;" или "T(a)++;" - это, конечно, операторы (точнее, операторы-выражения, в терминах стандарта). Ну а как понимать следующее: "T(e)[5];" или "T(c)=7;"? А это, будьте уверены, еще не самые разительные примеры - загляните в разд. 6.8 Стандарта.

--

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

Спасибо, в "Зеленой книге" подсказали схему такого анализа. Не знаем, как и благодарить, сами бы ни за что не придумали...

--

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

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

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

← →
Mystic © (2004-06-22 19:00) [43]

J_S © (22.06.04 18:17) [33]

const X: Array of const

← →
Игорь Шевченко © (2004-06-22 22:23) [44]

Mystic © (22.06.04 19:00)

Можно я про Паскаль такое же поищу ? :)

← →
Ломброзо © (2004-06-22 23:14) [45]

хехех... вот у меня всего три критериев выбора компилятора
1) масксимально кросс-платформенный
2) бесплатный
3) с открытым кодом

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

Что-то краем уха слыхал про мифические SmallTalk и Eiffel, однакож про реализации коммерческих проектов на оных не слышал.

← →
Polevi © (2004-06-22 23:18) [46]

> [45] Ломброзо © (22.06.04 23:14)
>1 максимально это как ?
>2 ну это понятно
>3 а это зачем ????

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

← →
Polevi © (2004-06-22 23:20) [47]

>Mystic
насчет отмены наследования нельзя ли поподробнее.. какие альтернативные модели можете предложить

← →
Palladin © (2004-06-22 23:21) [48]

> [45] Ломброзо © (22.06.04 23:14)

Точно... Java - кросс-платформенный (ну почти, ибо с Midlet"ами у них все таки вышел прокол) интерпритатор скомпилированного байт-кода, а Perl - непонятно что, никогда с ним не работал...

← →
Игорь Шевченко © (2004-06-22 23:31) [49]

> хехех... вот у меня всего три критериев выбора компилятора
> 1) масксимально кросс-платформенный
> 2) бесплатный
> 3) с открытым кодом

GCC ?

← →
Ломброзо © (2004-06-22 23:52) [50]

>Polevi © (22.06.04 23:18) [46]
-1 Так, чтобы мне не было потребности думать, к примеру, как создать поток - пусть компилятор сам разруливает, вставлять ли ему CreateThread в Win или создать дочерний процесс в UNIX-системах. Или там, файл открыть.
-3 наличие обратной связи между создателями компилятора и разработчиками. Всем известно, что Java-GUI приложения и апплеты шибко тормознутые, а почему они такие?

>Игорь Шевченко © (22.06.04 23:31) [49]
Стоит ли выделить мои требования в демагогическую ветку "каким я вижу идеальный язык и идеальную среду разработки"? ) gcc, конечно, супер. За исключением того, что забыл дописать:)
4) не С/C++
5) наличие приличной кросс-платформенной IDE.

Palladin © (22.06.04 23:21) [48]
Perl - это сказка ))

← →
Polevi © (2004-06-23 00:04) [51]

> [50] Ломброзо © (22.06.04 23:52)
>1 Так, чтобы мне не было потребности думать, к примеру, как создать >поток - пусть компилятор сам разруливает, вставлять ли ему CreateThread в >Win или создать дочерний процесс в UNIX-системах

это не есть задача компилятора.. это задача библтотек

← →
Ломброзо © (2004-06-23 00:13) [52]

>Polevi © (23.06.04 00:04) [51]

Дыкъ! Я не хочу даже знать о том, чья это задача )) а хочу иметь на руках спецификацию, в которой чётко описано, что такое поток, как его создавать и как с ним работать. Притом сноска "Так при работе с потоками делать не следует" в идеале должен отсутствовать вовсе.

> Стоит ли выделить мои требования в демагогическую ветку
> "каким я вижу идеальный язык и идеальную среду разработки"?
>

Почему нет ? Хорошая идея

>Почему нет ?

Да незачем. Выродится в C++ / Delphi.

Вот интересно: прикладному программированию уж полвека, не меньше. Автомобили всё совершеннее, телефоны всё навороченнее, ан в прикладом программировании ни коммерсанты, ни GNU-сообщество ничего идеального так и не придумали. Или сложно и чревато ошибками, или медленно, или вырождается в какое-нибудь детище гонки технологий навроде .NET. Не знаю, правда или нет, но где-то я вычитал, что второй пентиум в режиме реального времени вполне в состоянии рассчитывать траектории всех искусственных спутников Земли.

> но где-то я вычитал, что второй пентиум в режиме реального
> времени вполне в состоянии рассчитывать траектории всех
> искусственных спутников Земли.

А это смотря на каком языке программа написана :)

> в прикладом программировании ни коммерсанты, ни GNU-сообщество
> ничего идеального так и не придумали. Или сложно и чревато
> ошибками, или медленно, или вырождается в какое-нибудь детище
> гонки технологий навроде .NET.

А может быть, не стоит искать универсальный инструмент на все про все ? Шуруп забитый молотком держится лучше, чем гвоздь, завернутый отверткой :)

[38] Mystic ©
> Не так давно M$ хвастались, что их компилятор соответствует
> стандарту на 98%. И я подумал --- это же какой стандарт
> надо было придумать, чтобы через столько лет его смогли
> почти выполнить ;)

Дело в не стандарте, а в MS. Они всегда сильно отставали в этом. Большинство разработчиков компиляторов сделало соответствие стандарту в течении года.

На многочисленные цитаты Mystic-а я могу сказать только одно: если бы С++ (билдер) был бы так неудобен, плох, коряв и т.д., клянусь, я бы его не использовал (в тех случаях когда у меня есть такой выбор)!

Вот я долго не мог понять, почему компилятор С многопроходный, а Паскаля - однопроходный. Ведь, исходя из логики, имея нормальную грамматику языка, ИМХО, всегда это можно сделать за один проход. И вот спасибо Mystic"y, прояснилось вроде. Так ли я все понял? Или многопроходность компилятора - это багаж других зависимостей. Спасибо.

{$IFDEF OFFTOP}
Если б был PHP с паскалеподобным синтаксисом, я был бы очень счастлив. Сила Паскаля, действительно, в его строгости и академичности.
{$ENDIF}

> pasha_golub © (23.06.04 09:46) [58]
> Вот я долго не мог понять, почему компилятор С многопроходный

Вот ещё один пример. Пусть есть объявление

const int a = 10;

Как компилятор должен это воспринимать? Можно рассматривать эту константу как переменную, которую запрещено изменять, т.е. выделить для неё память в сегменте данных и при упоминании в выражениях брать значение этой ячейки. Или можно тупо на этапе компиляции заменить все упоминания этой константы значением 10. Так вот, согласно спецификации C++, компилятор должен выбрать один из этих двух способов в зависимости от того, как в дальнейшем используется эта константа. Если где-нибудь появляется указатель на неё, то выбирается первый вариант, если указателей нет - второй. Отсюда следует, что компилятор не может решать, что за объект объявлен до тех пор, пока не посмотрит, как он в дальнейшем используется. Ну какая тут может быть однопроходность?

Дело в не стандарте, а в MS. Они всегда сильно отставали в этом. Большинство разработчиков компиляторов сделало соответствие стандарту в течении года.

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

Или многопроходность компилятора - это багаж других зависимостей

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

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

Я же писал, что не всегда разделяю точку зрения авторов. Большая часть это просто выдержки из статей (переведены Ketmar-ом).

Можно я про Паскаль такое же поищу ? :)

Конечно можно ;)

--

Ну и еще. В паскале удаление/вставка/изменение одного символа приведет в большинстве случаев к ошибке в исходном тексте. Более того, сообщение об ошибке в большинстве случаев выведется в месте этого символа. Этот вопрос изучался при проектировании языка. В С (и С++) это далеко не так. Например, если имелось в виду

if (flag1 && flag2)

но написалось

if (flag1 & flag2)

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

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

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

Mystic © (23.06.04 11:04)

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

(с) Н. Вирт

"Я утверждаю, что Паскаль очень близок языку Си. Одни, быть может, этому удивятся, другие - нет... Даже интересно, насколько они близки друг другу"

(с) Деннис Ритчи

Я утверждаю, что Паскаль очень близок языку Си
Даже интересно, насколько они близки друг другу

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

Мне Билдер больше нравится. С++ все таки. Свои лучшие вещи я делал именно на Билдере. И один. Потом перешел на Дельфи, работу в комманде - фигня, а не софт пошла.

> На самом деле, близость, имхо, может быть разная. Можно,
> например, в качестве примера взять количество неоднозначностей
> при синтаксическом разборе... А можно взять наличие основных
> операторов (ветвления, циклы, выбор, переход).

А можно просто взять общность конструкций языка :)

>Igorek © (23.06.04 13:29) [64]
Потом перешел на Дельфи, работу в комманде - фигня, а не софт пошла.

так может дело вовсе не в Дельфи? ;-)

Сравнительный анализ компиляторов С++
http://www.comizdat.com/3/4/90/90/3808/3810/

> Сравнительный анализ компиляторов С++
> http://www.comizdat.com/3/4/90/90/3808/3810/

тестирование там какое-то однобокое...
да и утверждения типа
"Многие разработчики указывают на ошибки при формировании кода у Borland Builder (в частности, при использовании ссылок его поведение становится непредсказуемым). Кроме того, Borland Builder C++ явно наследует многое от Delphi (один модификатор вызова метода DYNAMIC чего стоит), в результате чего при компилировании абсолютно правильного С++ кода могут возникать ошибки (например, отсутствие множественного наследования для VCL-классов; а все потомки от TObject являются VCL-классами)."
пахнут очень уж жареным...

например, вот статья с более серьезными тестами и, кы-гм, слегка другими результатами - http://www.ddj.com/documents/s=9132/ddj0405a/0405a.htm

хотя истина, как всегда, где-то сбоку.... :)

> вразлет © (23.06.04 13:37) [66]
> Ой, а можно что -нибудь из раннего?

Можно. Вообще очень много всего было. Но поскольку тут речь идет о Билдере то приведу часть своего резюме:

Июнь – июль 2001 г. «ЕкспоТорг 1.0 – рабоча станція», «Экспоторг - Администратор»
Сетевая система учета закупок с/г продукции по договорам с поставщиками, хранения на складах, экспорта по договорах с покупателями, учет движения денег в разных валютах. Администрирование прав пользователей системы.
ОС: Windows 95/98/2000
Язык программирования: C++
Среда разработки: Borland C++ Builder 5.0
Роль: самостоятельная разработка
Статус проекта: программа продана и используется ТзОВ «Крокимекстрейд»;

Январь – февраль 2000 “CrossWord Maker 1.0”
Программа для создания сканвордов и кроссвордов.
ОС: Windows 95/98/2000
Язык программирования: C++
Среда разработки: Borland C++ Builder 4.0
Роль: самостоятельная разработка
Статус проекта: программа продана и используется редакцией журнала в г. Ивано-Франковске.

---
Первое - легкая в написании БД, короче имхо трвиальная БД.
Второе - неплохая шустрая прога, относительно сложные алгоритмы.

Первое - легкая в написании БД, короче имхо трвиальная БД.
Второе - неплохая шустрая прога, относительно сложные алгоритмы.

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

С++ Builder и Delphi Найти похожие ветки