С++ 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]

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

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

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

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

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

}|{yk © (22.06.04 17:39)

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

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

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

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

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

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

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

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

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

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

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

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

--

Если Вы задаетесь вопросом, является ли это уместным, только взгляните на состояние развития программного обеспечения после 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, только основные операторы
* Соглашения по именованию строго определены

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

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

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

--

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

--

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

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

--

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

--

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

--

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

ЧЕЛОВЕЧЕСКИЕ качества важны для организации здоровых отношений в коллективе. На счет выбранного языка реализации: одной кафедре нужно было засветиться в оборонном ведомстве одной из эсенгешных держав. Необходимо было сделать (очень быстро!) пилот-проект с достаточно навороченным интерфейсом пользователя. Это был 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++ стремятся использовать огромные префиксы и неудобные имена для любых идентификаторов, которые описаны в заголовочных файлах. Эти префиксы, естественно, не определены жёстко раз и навсегда, они должны базироваться на каких-то соглашениях. Неправильно написанные или пропущенные префиксные строки не вызовут со стороны компилятора никаких нареканий.

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