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

Flex Ferrum- да уж, красиво.. вот где Си и рядом не стоял.

Цитата n0p @ 08.04.07, 18:01

Flex Ferrum- да уж, красиво.. вот где Си и рядом не стоял.

И дельфя иже с ним.

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

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

Конечно, ибо не надо писать по сто раз базовые вещи.

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

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

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

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

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

А... ты про винду? Там, как известно, компили линкуют библиотеки c++ статически... У меня-то без всяких оптимизаций hello, world весит пару килобайтов...

Цитата wind @ 08.04.07, 13:35

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

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

Цитата wind @ 08.04.07, 13:35

Возможно, я избалован Java, но что тут сложного, не пойму

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

Цитата wind @ 08.04.07, 14:01

Или я упустил какой особенный тип коллекций?

Да. Для реализации многих контейнеров требуется операция сравнения (например, куча, различные деревья) или хэш-функция (хэш-таблица)... Как их задавать?

Цитата Smike @ 08.04.07, 16:23

А во вторых можно при желании в Дельфи и шаблоны организовать с помощью Include-файлов. В-третьих можно использовать динамические массивы.

О, да Шаблоны очень хорошо эмулируются include'ами Или, может, хочется чего-то в стиле C'шного препроцессора, и потом ловить баги и отлаживать свою эмуляцию шаблонов?

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

Цитата mo3r @ 08.04.07, 18:34

Да. Для реализации многих контейнеров требуется операция сравнения (например, куча, различные деревья) или хэш-функция (хэш-таблица)... Как их задавать?

А при чём тут шаблоны?

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

Цитата wind @ 08.04.07, 19:19

А при чём тут шаблоны?

Шаблоны при том, что часть вычислений при этом происходит на этапе компиляции. Простейший пример - обмен значениями:

template <class T>
void swap(T& arg1, T& arg2) {
   T temporary = arg1;
   arg1 = arg2;
   arg2 = temporary;
}

Одна шаблонная функция почти на все случаи жизни(любые типы). Нужную реализацию для конкретного типа создаст сам компилятор на основе приведенного шаблона. Без шаблона будешь вручную писать реализации для всех типов, внося ошибки.
А если сюда добавить еще и специализацию шаблона...
Аналогично и для контейнеров и для других алгоритмов. Например, алгоритм std::find понятия не имеет, в каком именно контейнере он ищет, он реализует обобщенный алгоритм поиска.

Добавлено 09.04.07, 04:45
P.S. В который раз C++-ники повторяют одно и тоже неразумным Delphi'стам?

чего стоит только то, что в OPascel'е доступ к private членам имеют все ф-ции, реализованные в том же модуле трансляции, что и сам класс (ну а класс разнести по разным подулям - нечто из разряда экспорта шаблонов в с++)...

P.P.S. Качеством генерируемого кода мерялись здесь: Скорость кода

Цитата trainer @ 09.04.07, 04:44

Одна шаблонная функция почти на все случаи жизни(любые типы). Нужную реализацию для конкретного типа создаст сам компилятор на основе приведенного шаблона.

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

Цитата archimed7592 @ 09.04.07, 07:47

чего стоит только то, что в OPascel'е доступ к private членам имеют все ф-ции, реализованные в том же модуле трансляции

По-моему, это вполне логично и весьма удобно. Лично меня возня с friend-ами в C++ весьма раздражает. Особенно это касается шаблонов. Чего только стоит тот факт, что различные специализации шаблона по умолчанию не имеют доступа к закрытым членам друг друга - IMHO, бред

Цитата archimed7592 @ 09.04.07, 07:47

чего стоит только то, что в OPascel'е доступ к private членам имеют все ф-ции, реализованные в том же модуле трансляции, что и сам класс

Да кстати, инкапсуляция на уровне файла меня в своё время очень порадовала

Цитата Dantes @ 09.04.07, 08:16

Особенно это касается шаблонов. Чего только стоит тот факт, что различные специализации шаблона по умолчанию не имеют доступа к закрытым членам друг друга - IMHO, бред

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

Мало ли что там можно. Объединение классов в один шаблон подразумевает их общность. И этой общности, на мой взгляд, вполне достаточно, чтобы автоматически считать их дружественными. Большинство шаблонов вообще не специализируется извне, и делать шаблон дружественным самому себе только из-за того, что в каких-то единичных случаях чего-то там можно, мне как-то не очень нравится.

Добавлено 09.04.07, 08:59
До кучи ещё можно добавить отсутствие прав доступа вложенного класса к закрытым членам объемлющего. Тоже радость ещё та. Особенно с учётом того, что много компиляторов это правило стандарта попросту нарушают

Цитата Dantes @ 09.04.07, 08:49

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

Общность решаемой задачи - может быть, но не зависимость реализаций шаблона друг от друга.

Цитата

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

То, что по умолчанию члены класса являются приватными - тебя не смущает, например?
Основная идея - минимизация прав. Если кому-то что-то нужно - это явно дается. В том числе и в шаблонах.

Цитата Flex Ferrum @ 08.04.07, 11:32

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

10-30 секунд -- это мягко сказано. Вот когда я в одном проекте поправлю глобальный хидер, у меня пересборка идет минут 15. А еще я готов убить тех, кто код методов прямо в хидерах пишет. Я понимаю, что inline и все такое, но, блин, как после напрягает 5 минут ждать билда
В Pascal'е Borland изначально поступил по-другому: они не стали делать include, они изобрели свой формат модулей, которые компилируются и компонуются (кстати, в BP был некислый оптимизатор: он выбрасывал из exe файла все неиспользуемые процедуры и функции), поэтому изменение одно unit'а (даже содержащего только одни константы) не приведут к пересборке всего проекта.
Кстати, компиляторы C++ тоже нельзя обвинять в излишней тормозности: им столько текста из-за этих #include обрабатывать приходится.

Цитата linuxfan @ 09.04.07, 09:19

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

У меня тоже было такое - полный ребилд проекта занимал секунд 300 (в общем можно было кружку чая не торопясь выпить).
После пересмотра структуры проекта, всех заголовков, объявлений и пр. полный ребилд стал занимать порядка 30 сек, при том, что объём кода к тому времени ещё увеличился, а сборка проекта без полной перекомпиляции - порядка 2 - 3 сек. Так что...
В общем, читайте Страуструпа, в частности, он пишет что и почему нужно можно включать в заголовки, а что не стоит.