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

Цитата

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

В первом сообщении темы просили

Цитата

<...>
Нус, продолжимс, пожалуй. Итак, критерии для сравнения:

1) Выразительные средства самого языка. Что (с точки зрения языка) позволяет Delphi, и что - С++.
2) Стандартные и стандартные де-факто библиотеки. Что есть у Delphi, и что есть у С++. И что это позволяет делать.
<...>

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

Сообщение отредактировано: Pourtous - 08.04.07, 09:51

Цитата Pourtous @ 08.04.07, 09:46

В первом сообщении темы просили

Угумс. Именно. Я потому и спросил - какие фишки можно вытворять с делегатами в дельфях? Задачи отнюдь не синтетические. Зачем мне плодить десяток функций, если я могу обойтись одной? Да вот, опять же, вполне себе реальная задачка пятидневной давности. Перед пользователь список, с элементами которого можно делать разного рода действия (выбираемые из контекстного меню). Пусть это будут Action1, Action2 и Action3. В списке - названия элементов. С каждым элементом списка проассоциирован некий идентификатор, передающийся в функции, осущесвляющие эти самые Action1, Action2 и Action3. Т. е. прямого доступа к манипулируемым объектам интерфейсная часть приложения не имеет. Список допускает множественный выбор (т. е. пакетную обработку элементов). Каким образом может быть реализована обработка элементов контекстного меню в данном случае?

Цитата mo3r

А в дельфи можно написать коллекцию, сравнимую с C++'ным map?
или vector?

Глубоко сомневаюсь, что кто либо из С++ програмистов, засаживаеться писать подобные колекции, нижнего белья, на все случаи жизни.
Потом - известно к чему приводят все эти iostream и вектора, к колосальным обьёмам кода, от 500килобайт и более, в простейших прогах хелловорлд. Либо большому количеству вызовов в C++ либы, которые отнюдь не грешат отсутствием багов. Простейший пример - либа imprec на С++, реконструирует таблицу импортов, нужна при снятии дампа пакованых прог.

Уж в чем, чем, а там эти классы, вовсе бы и не были нужны. Как результат - DLL скомпиленая в билдере - не работает, на VC5- работает. Опять же, компилю со статической либой - не работает. Приходиться, хоть и постепено, но изгонять все эти вкусности C++. Дабы перепортировать на дельфи. Благо можно используя старые компилеры, миксить код, аля ms VC++ & Delphi))) Так что теория теорией, а на практике (особенно системной) больше рулит, 'практика чистого Си'.

Цитата n0p @ 08.04.07, 10:19

Потом - известно к чему приводят все эти iostream и вектора, к колосальным обьёмам кода, от 500килобайт и более, в простейших прогах хелловорлд. Либо большому количеству вызовов в C++ либы, которые отнюдь не грешат отсутствием багов.

:LOOL:, сына. Ты явно не знаешь, о чем говоришь. Пример кода и его ассемблерный листинг (на сотни килобайт) в студию.

Цитата

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

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

Цитата

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

В STL много багов?Возьмите гцц и приведите хотя бы пяток. Оченно интересно взглянуть.

Цитата

Простейший пример - либа imprec на С++, реконструирует таблицу импортов, нужна при снятии дампа пакованых прог.

Ммм. Это к чему? На дельфи тоже глючных поделок много.

Цитата

Уж в чем, чем, а там эти классы, вовсе бы и не были нужны. Как результат - DLL скомпиленая в билдере - не работает, на VC5- работает. Опять же, компилю со статической либой - не работает. Приходиться, хоть и постепено, но изгонять все эти вкусности C++. Дабы перепортировать на дельфи. Благо можно используя старые компилеры, миксить код, аля ms VC++ & Delphi))) Так что теория теорией, а на практике (особенно системной) больше рулит, 'практика чистого Си'.

Ну не нужны - не используйте, кто ж заставляет то. А практика разная бывает.

Сообщение отредактировано: Pourtous - 08.04.07, 10:32

Цитата n0p @ 08.04.07, 10:19

к колосальным обьёмам кода, от 500килобайт и более

1. Мы пишем на очень высоких абстракциях
2. Все это долго и мучительно компилируется
3. В итоге получается ужатый оптимизатором код, содержащий исключительно реализацию

Цитата Flex Ferrum

Ты явно не знаешь, о чем говоришь. Пример кода и его ассемблерный листинг (на сотни килобайт) в студию.

дык хотя-бы вот
Элементраная прога 156кб
или вот
Visual Studio vs GCC

А что там говорить про отладку таких 'хелловорлдов', когда с головой уходишь в дебри либ?

Цитата Pourtous

На дельфи тоже глючных поделок много

ну да, глюки - всегда, где то рядом.

Цитата n0p @ 08.04.07, 10:50

дык хотя-бы вот
Элементраная прога 156кб

Ну а у меня другие результаты получались:
EXE-шник меньше 1К на VC++ 6.0

Цитата Мяут

1. Мы пишем на очень высоких абстракциях

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

Цитата Мяут

2. Все это долго и мучительно компилируется

а для меня - скорость компиляции очень критична. Поэтому я практикую даже урезку хидеров. на C/C++. На дельфи же все из коробки, молниеносно компилируеться.

Цитата Мяут

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

забыл добавить - 'мы никада не ошибаемся, поэтому версии для отладки нам не нужны'

Цитата n0p @ 08.04.07, 10:50

А что там говорить про отладку таких 'хелловорлдов', когда с головой уходишь в дебри либ?

Вопрос - насколько часто в такие дебри залазить надо. На моей практике - очень нечасто.

Добавлено 08.04.07, 11:02

Цитата n0p @ 08.04.07, 11:00

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

Ну это ты у нас любитель на уровне ядра проги писать. Тем более, не могу согласиться с твоим утверждением.

Цитата n0p @ 08.04.07, 11:00

а для меня - скорость компиляции очень критична. Поэтому я практикую даже урезку хидеров. на C/C++. На дельфи же все из коробки, молниеносно компилируеться.

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

Цитата n0p @ 08.04.07, 11:00

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

Большая часть пользовательских программ в режиме ядра не работает Вот тебе еще одно преимущество: в C++ высокоуровневые и низкоуровневые абстракции - делимы, а в Дельфях - нет. Асмом надо пользоваться

Цитата n0p @ 08.04.07, 11:00

забыл добавить - 'мы никада не ошибаемся, поэтому версии для отладки нам не нужны'

Ну пользователь-то в магазине-то (на варезном сайте, на торрентах, нужное подчеркнуть) получает все равно релиз.

Цитата n0p @ 08.04.07, 11:00

а для меня - скорость компиляции очень критична.

В ущерб удобству и скорости работы программы? Фиии

Цитата

В ущерб удобству и скорости работы программы? Фиии

От того, что туева куча по сути левого текста, в подключеных хидерах, тогоже Windows.h, остаёться за бортом, удобство не страдает (за редкими исключениями -которые можно считать 'грязными хуками'). А вот, скорость, работы программы-компилятора весьма-с увеличиваеться. На том же билдере, или консольном компилере. Хотя, это всё хитрости кухни. Как С++ программер, я не понимаю, ожианий в 10-30секунд, если нужно перепробывать подставить другие значения переменных, или использовать другие решения.. поэтому и приходиться выбирать этот стрёмный дельфи. Даже проекты, в C++Builder, основной рабочий код, приходиться выносить в OPascal модули. Ибо готовиться быстро.

Цитата n0p @ 08.04.07, 11:27

От того, что туева куча по сути левого текста, в подключеных хидерах, тогоже Windows.h, остаёться за бортом, удобство не страдает (за редкими исключениями -которые можно считать 'грязными хуками'). А вот, скорость, работы программы-компилятора весьма-с увеличиваеться. На том же билдере, или консольном компилере. Хотя, это всё хитрости кухни.

Precompiled Headers + Incremental Linking спасут отца русской демократии. 10-30 секунд - это действительно достаточно много, если ты правишь всего один исходник. Хотя, смотря с чем сравнивать.

Цитата impik777 @ 08.04.07, 09:38

имеется транспортная сеть, состоит из узлов, узлы делятся на источники и потребители
источник маркируем числом -1 а потребитель положительным целым означающим потребность
также узлы соединяются между собой путями, каждый путь маркируется сложностью (положительным целым числом)

Принимаю вызов, жду реализации на C++

Цитата Flex Ferrum @ 08.04.07, 10:03

Да вот, опять же, вполне себе реальная задачка пятидневной давности. Перед пользователь список, с элементами которого можно делать разного рода действия (выбираемые из контекстного меню). Пусть это будут Action1, Action2 и Action3. В списке - названия элементов. С каждым элементом списка проассоциирован некий идентификатор, передающийся в функции, осущесвляющие эти самые Action1, Action2 и Action3. Т. е. прямого доступа к манипулируемым объектам интерфейсная часть приложения не имеет. Список допускает множественный выбор (т. е. пакетную обработку элементов). Каким образом может быть реализована обработка элементов контекстного меню в данном случае?

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

Добавлено 08.04.07, 12:27

Цитата Мяут @ 08.04.07, 11:11

В ущерб удобству и скорости работы программы? Фиии

Скорость больше, удобства больше, что еще не нравится?

Цитата Smike @ 08.04.07, 12:26

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

Ну проассоциировал. А дальше что делать?