С++ Builder и Delphi

← →
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]

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

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

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

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

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

>Почему нет ?

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

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

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

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

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

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

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

← →
Paul © (2004-06-23 09:30) [56]

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

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

← →
Paul © (2004-06-23 09:43) [57]

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

← →
pasha_golub © (2004-06-23 09:46) [58]

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

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

← →
Григорьев Антон © (2004-06-23 10:59) [59]

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

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

const int a = 10;

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

← →
Mystic © (2004-06-23 11:04) [60]

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

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

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

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

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

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

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

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

--

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

if (flag1 && flag2)

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

if (flag1 & flag2)

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

← →
wicked © (2004-06-23 11:52) [61]

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

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

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

Mystic © (23.06.04 11:04)

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

(с) Н. Вирт

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

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

← →
Mystic © (2004-06-23 12:24) [63]

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

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

← →
Igorek © (2004-06-23 13:29) [64]

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

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

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

>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 Найти похожие ветки