templates, STL

ПЕРВОЕ средства обобщенного программирования в С++ (templates)
ВТОРОЕ библиотека STL, контейнеры и алгоритмамы STL

в чем разница первого и второго?

спасибо.

0

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

1

Сообщение от AnyOne697 Очень советую избегать шаблонов там, где только можно. И с осторожностью использовать стороннии библиотеки на STL. Они, часто, очень мощные, но сами по себе шаблоны не торт.

Это че это? Использование шаблонов увеличивает время компиляции, однако уменьшает время выполнения (естественно я имею ввиду вычисления на этапе компиляции).
Любую возможность языка стоит использовать там где это нужно, что понятно. Но "избегать" некую возможность языка (причем далеко не самую плохую) это, простите, бред.

4

Сообщение от ForEveR Это че это? Использование шаблонов увеличивает время компиляции, однако уменьшает время выполнения (естественно я имею ввиду вычисления на этапе компиляции). Любую возможность языка стоит использовать там где это нужно, что понятно. Но "избегать" некую возможность языка (причем далеко не самую плохую) это, простите, бред.

Потому что возможность очень даже хреновая. Я долго не замечал, как это удобно программировать БЕЗ шаблонов. Это как глоток свежего воздуха. Реализация шаблонов в C++ не без... багов. Я уже смирился с тем багом, но только усугубляет и так не очень хорошее положение. Идею многократного использования кода можно решить и без использования шаблонов, а лишь используя наследование и инкапсуляцию.

Что я вообще несу?.. Окей, закроем глаза на "баг". Просто используем шаблон.
А теперь попробуем отнаследоваться:
Вроде жить можно. Не очень красиво, но жить можно. Только... Что произошло с неперегруженными реализациями?.. Упс...
Окей, не забываем, что в C++ нет никакой рефлексии, и мы не можем посмотреть на типы в шаблоне. А код. Ну что за код?.. Он некрасив. Ладно, к этому тоже можно привыкнуть.

Но ко всему сразу?.. ИМХО, нужно просто избегать шаблонов там, где они не нужны. А не нужны они почти всегда.

0

Сообщение от AnyOne697 Что произошло с неперегруженными реализациями?..

А что с ними произошло?
Кстати, о каком баге идет речь?

0

Сообщение от castaway А что с ними произошло?

ЕМНИП, когда мне пришлось такое сотворить, компилятор не нашёл реализации конкретно для этого класса. Вылечилось переходом к чистому наследованию.
Имхо, в Java сделал более качественная объектная модель. Не холивара и оффтопа ради, а лишь ради сравнения с Си++.

0

Сообщение от AnyOne697 ЕМНИП, когда мне пришлось такое сотворить, компилятор не нашёл реализации конкретно для этого класса. Вылечилось переходом к чистому наследованию.

Может, вы просто не знаете как это правильно сделать?

0

Сообщение от castaway Может вы просто не знаете как это сделать?

Может просто не стоит заставлять делать из кодовой базы помойку. Засовывать 1k строк кода для реализации предка (это всё header), в другой заголовочный файл с уже более чем 1k строк кода мне совсем не хотелось. Тем более, что предок в ближайшей перспективе должен был иметь ещё несколько детей.

Перейдя на чистую объектную модель мы ускорили время компиляции более чем в 5 раз (производительность снизилась в пределах погрешности). К тому же, количество кода в заголовчных сократилась в 10 раз (хоть за счёт и расширения cpp-файлов, но им 2k это нормально).

Собственно, мы просто применили этот инструмент неправильно. Вот и всё.

1

Вы в каменном веке живете? Что за претензии к размерам заголовочных файлов.., ко времени компиляции? Вы компилируете 10 программ в секунду не ради производительности программы а ради 10 компиляций в секунду?
По-моему ваши утверждения чистой воды бредовые. Шаблоны дают дополнительный функционал языку. Пользоваться ими или не пользоваться - ваше личное мнение, но судить о том нужны ли они или нет по-моему уже просто глупо.

0

Сообщение от AnyOne697 Я долго не замечал, как это удобно программировать БЕЗ шаблонов. Это как глоток свежего воздуха. Реализация шаблонов в C++ не без... багов. Я уже смирился с тем багом, но только усугубляет и так не очень хорошее положение. Идею многократного использования кода можно решить и без использования шаблонов, а лишь используя наследование и инкапсуляцию.

Вы не могли бы привести пример того, как должен выглядеть программный
интерфейс list без шаблонов, используя только наследование и инкапсуляцию ?
Разумеется, должна быть поддержка любых типов. Только не говорите, что
будете делать это через макросы или приведения к <void *> - ни за что не
поверю, что это и есть "чистая объектная модель".

1

Сообщение от AnyOne697 в Java сделал более качественная объектная модель

Загнали в жесткие рамки, где все наследуется от Object, нет user-defined value types (aka structs), где кривые generics (из-за чего приходится или copy-paste кода делать или боксить примитивные типы). Это называется "качественная объектная модель"?

А если с этой качественной моделью нужна хоть какая-то сравнимая с C/C++ производительность, то всю эту модель посылают куда подальше и работают с ByteBuffer.

1

Сообщение от Убежденный Вы не могли бы привести пример того, как должен выглядеть программный интерфейс list без шаблонов, используя только наследование и инкапсуляцию ? Разумеется, должна быть поддержка любых типов. Только не говорите, что будете делать это через макросы или приведения к <void *> - ни за что не поверю, что это и есть "чистая объектная модель".

Всё очень просто. Пришлось правда сделать Complex -> Real -> Integer -> Unsigned -> Object.
Ну и банальное:
Сравнения заявлены в Object.
Не стоит сразу так кидаться палками. Я уже говорил, что время полной компиляции уменьшилось в 5 раз. С 70 часов до 12 часов. Имхо, это очень и очень существенно. В случае инкрементальной сборки, то сильно зависит от количества изменений их локации. При небольших изменениях в 3-4 относительно новых файлах (не в глубокой иерархической ( . )) собирается за секунды. Против от минуты до часа.
Из проблем - огромное количество кастов. Обобщений здесь нет и приходиться творить огород. Был даже сделать специальный кастер - темплейтовая штука, которая делает это чуть удобнее. Но она нигде не наследуется, а её использования необязательно. Почти как Java.
И уйдите подальше от камней. Да, почти как Java. Были вполне объективные причины не использовать Java. Наконец, было потрачено огромное количество времени на переписывание с нуля библиотек, ограничения в использовании буста и прочего. Но 12 часов собирается вместе с библиотекой. Да и писали мы по мере необходимости нередко быстро оборачивая шаблонный аналог, а потом переписывая оптимальнее. Если я правильно знаю, то до сих пор пишеться.

Вас, наверное, интересует производительность. Вот здесь я просто убился об стенку, когда узнал, как плохо написана библиотека. Поразительно, но заменив красно-чёрные деревья на куда более интересные декартовы деревья (они были немного изменены), произоводительность деревьев возрасла раза в 3, хоть разница и падала с ростом дерева. Но. Требовалось забить 2.5 гигабайта памяти, чтобы std:set работал быстрее нашего Set.

0

Сообщение от AnyOne697 Собственно, мы просто применили этот инструмент неправильно. Вот и всё.

ну да, вот от сюда и проблемы. а например какие проблемы от std::string? ведь это же typedef басикстринга. или у буста в optonal? shared_ptr - очень удобно... наследование от шаблона ОЧЕНЬ сильно замедляет компиляцию. а вот юзанье шаблона типа shared_ptr почти не замедляет, глюков никаких..

0

отето вы Пацаны розвели

0

Сообщение от _stealth_ наследование от шаблона ОЧЕНЬ сильно замедляет компиляцию

Спасибо, КО. Я про то и говорю. К слову, generics почти не замедляют компиляцию. А может даже ускоряют =)

Сообщение от kamre Загнали в жесткие рамки, где все наследуется от Object, нет user-defined value types (aka structs), где кривые generics (из-за чего приходится или copy-paste кода делать или боксить примитивные типы). Это называется "качественная объектная модель"?

И?.. user-defined value types? Вы
смеётесь. Класс - да, он похож на user-defined value types. А структура - банальный агрегатор данных. Впрочем, в Си++ что-то странное сотворили со структурами от чего они стали... Запутанными.

Сообщение от _stealth_ например какие проблемы от std::string? ведь это же typedef басикстринга

А какие проблемы от std::string? Почти никаких. Мы лишь отнаследовали String от std::string и Object. Ну почти "лишь", но суть была в этом.
Вообще, беспредметный разговор. Лично я понимаю, что инструмент мощный. Но. Опасный и неудобный. Это как сравнивать острозаточенный нож без ручки (templates) с новенькой электробритвой (generics). Первым хоть и можно овощей нарезать, да и побриться, но вторым бриться удобнее и практичней.

0

Сообщение от AnyOne697 Вообще, беспредметный разговор. Лично я понимаю, что инструмент мощный. Но. Опасный и неудобный.

ну да надо только применять там, где надо применять, тогда и проблем не будет. ИМХО перед тем как наследоваться от шаблона нужно очень хорошо подумать. а в остальном, как сказал страуступ, они выражают общность там, где её нельзя выразить другими средствами (ну как-то так она сказал).

0

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

0

Сообщение от AnyOne697 И?.. user-defined value types? Вы смеётесь. Класс - да, он похож на user-defined value types. А структура - банальный агрегатор данных. Впрочем, в Си++ что-то странное сотворили со структурами от чего они стали... Запутанными.

Вот именно что нет в Java "банального агрегатора данных". Ключевое отличие value types от reference types знаете? Попробуйте на Java реализовать эффективный тип данных для комплексных чисел с возможностью выбора базового типа хотя бы из float/double. Эффективный тип данных - это такой, при использовании которого не будет потерь производительности по сравнению с вручную написанным кодом под специальные случаи.

0

Сообщение от AnyOne697 Общность можно выразить не только за счёт шаблонов. Но и за счёт наследования.

такая общность весьма разная. наследование (public) - Х есть (is) У. включения экземпляра другого класса в класс - X имеет (has) Y (вот не надо сейчас эту тему развивать ). а шаблон такие-то классы обрабатываются по одному и тому же шаблону (при этом они не is и не has).

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

0

Намазал мыслию по древу..
А можно не писать эти талмуды а просто в 5 строках пояснить что имелось в виду в 12-м посте в ответ на вопрос Убежденного ?

0