Man555
Ещё не успел ознакомится с оным творением, но думаю проблема шаблонов там решается за счёт однокоренной иерархии наследования.

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

Плюс в Делфи очень расплывчатое понятие модификаторов доступа. Они вроде бы как есть, но и их вроде бы как нет. Попробуйте написать константный итератор и неконстантный в Делфи, и если у вас это получится - передайте константый итератор какой-нить функции, работающей с неконстантым итератором. Будет сюрприз...

В делфи нет вложенности типов. Т.е. я не могу описать тип внутри другого типа. В резульате итераторы для контейнеров вынуждены будут хранить указатель(хотя в делфи все перепутано, там полууказатели-полуссылки) на контейнер. В C++ в неассоциативных контейнерах итератор - это указатель.

Относительно алгоритмов STL их придется переписывать очень сильно, потому что они основаны на двух китах - ИТРАТОРЫ(в которых "скрыта" реализация контейнеров) и ПЕРЕГРУЖАЕМЫЕ ОПЕРАТОРЫ. Ни того ни другого нет в Делфи.

Traits template - я вообще не знаю как вы будете это делать в Делфи. Это все чистая статика, когда шаблон параметризуется отнсительно внутренних typedef типов аргументов. Или за счет статических функций.

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

Вобчем список можно продолжать долго. Я могу вам подкинуть парочку задач, которые решаются в шаблонах и в STL вчастности и попробуйте это написать в Делфи.

Man555
задачки:
- СТАТИЧЕСКАЯ проверка наследует ли одни тип другой.
- СТАТИЧЕСКАЯ проверка является ли итератор RANDOM-ACCESS итратором
- ЗАПРЕТИТЬ опять же в статике преобразования от одного типа к другому
- ЗАПРЕТИТЬ объект распологать в куче
- ЗАПРЕТИТЬ операцию присвоения для классов
- РАЗРЕШИТЬ для класса только ЯВНЫЕ преобразования от встроенных типов, например.
- СНЯТЬ у типа модификатор доступа
- СТАТИЧЕСКИ определить является ли тип классом
- реализовать STATIC_ASSERT

ну и хватит, пока.

теперь относительно итераторов. Я знаю, что итератор это паттерн проектирования. Но вся фишка, что в С++ большинство проверок можно делать в СТАТИКЕ, а не рантайм. Т.е. ошибки будут выявлятся на стадии компиляции, а не на стадии выполнения. Это сильно упрощает разработку и повышает качество ПО. Надо только уметь этим пользоваться. Т.е. это не значит что все программирующие на С++ этим пользуются.

Для примера, паттерн визитер реализованный на шаблоне списка типов делает все проверки на этапе компиляции, в то время как в Делфи тебе придется пологатся на оператор IS.

И только не надо преуменьшать пользу статической проверки.

какую озвученную? уводит все статические проверки в полимрофизм, т.е. в проверку рантайм? И это хорошо? дело вкуса. я уже сказал, чем хороша шаблонная реализация STL. А к реализации через полиморфизм отношусь как "лучше что-то, чем ничего". Но функциональности и удобства C++ STL в ней нету.

"нехватка STL" - очень расплывчатое понятие, чтобы его обсуждать. Кому-то может просто не хватать просто контейнеров, какого-то конткретного одного, или парочки. Такая "нехватка" выражается восновном алгоритмической или структурной(данные) необходимостью. Человек, который пишет на языке без шаблонов, естессно, не знает ни о каких приемах generic programming. Когда-то STL, да и некоторые другие билиотеки С++ я воспринимал именно так.

Однако, сейчас STL не воспринимается как кусочек. Поэтому если переходить на какую-то ООП билиотеку выражающую функциональность STL, то с точки зрения каких-то алгоритмов и классов можно найти параллель. Ноя уже привык использовать STL(или BOOST или LOKI), так чтобы ошибки выявлялись на этапе компиляции. Если вам это не нужно и вы не ощущает в этом необходимость - это не значит что эта концепция плоха. У меня другое мнение. Мне нравится, что ошибки использования той или иной библиотеки, выявляются на этапе компиляции, а не отладки.

приведу в пример программистов 1С. Они тоже не имеют понятия о некоторых приемах, например, ООП программирования. Я не имею ввиду ВСЕХ программистов 1С. Но они(этот избранный кружок любителей бух-бейсика) спокойно себе зарабатывают на жизнь. Они Иногда посмеиюваються над теми кто использует делфи или что-то еще. Типа зачем? когда можно сделать на 1С. Они сами глубоко уверены что нет ничего удобней среды 1С. И т.д. И что теперь? Бросать ООП или кричать на каждом форуме, что ООП плохо? Это что идеологическая война? Тогда я пас, я лучше делом займусь. На мой скромный взгляд всякий прием, если с него больше пользы, чем вреда имеет право на существование. И если кто-то его не использует или не умеет использовать - это их проблемы.

Так что уж всемилостивейше разрешите существовать шаблонам. 8-)

я вот жизненно ощущаю необходимость в тех приемах разработки, которые предоставляет generic programming. Но еще большую пользу они приносят в умелом сочетании ООП и Шаблонов.

Опять начинают меряться нескажу чем...
Ок - напиши приложение которое создает окно с сообщением и кнопкой ОК и чтобы EXE занимал 1 килобайт. Я буду рад. У меня есть проект, но могу приложить и EXE написанный на VC, который занимает 1 кило.

Только зачем это? Это что главный критерий?

lelikk
В результате получается очень чистое приложение, причем размером поменьше VC++.
не я начал этот беспредметный разговор. Имхо С++ удобней в плане композиции кода, чем асм. Хотя лично я ничего против него не имею. Лишь хочу сказать, что мерится размерами ЕХЕ модулей это как то по-детски. А делать выводы из этого, что один язык круче другого - это...

боюсь оскорбить.

Вобчем прежде, чем говорить о том, что С++ плох тем рождает пухлые ЕХЕ разберись сначала с опциями линковщика и компилятора. И ты увидишь, как много лжи в этом утверждении.

Сори если я неправильно понял твое первое высказывание.

согласен.

softwarerПоэтому - всемилостивейше разрешите существовать без шаблонов 8-)
я и не запрещал. я просто упомянул, по просьбе посетителя же форума, о некоторых особенностях generic programming. Без нападок в сторону других технологий. Просто, чтобы продемонстрировать разницу. Но за этим сразу же последовали нападки смысл, которых сводились к тому, что шаблоны гавно.

Вчера читал нитку форума rsdn по С++, посвященную указателям на функции. Очень показательное содержание тамошнего обсуждения. Без всяких аналогий. Кстати, желающим поднять себе настроение рекомендую почитать. 8-) Я вчера долго смеялся.

http://rsdn.ru/Forum/Message.aspx?mid=958534&only=1

там потом надо ткнуть верхную левую кнопку - "показать положение в теме"

восновном прекрасная половина садится за комп, чтобы писать, либо под 1С, либо под Делфи. грамотных С++ программисток я не встречал.

про них веселее, но будет оффтоп 8-)