Re:

> С точностью наоборот, если бы не совместимость с С, язык был бы более понятен и очевиден

Хехе. Если бы в Си++ небыло подержки Си, то этот язык назывался бы, например, Object Pascal. Тем не менее называется он Си++.

> Можно хоть одно подтверждение.

Типичный пример кривокостыльности шаблонов - идея разделения интерфейса и реализации на уровне компилируемого модуля. Хорошая понятная идея, которой бог знает сколько лет. В Си и даже в нешаблонном Си++ поддерживается "на ура". Как только дело доходит до шаблонов, идея сдыхает "на корню" Ну трудно сделать норамльные extern template-ы, турдно! Приходится изобретать всякие precompiled header-ы и прочее велосипедство.

Другой пример - ключевое слово typename которое вообще один большой костыль, предназначенный только для того чтобы просто интегрировать механизм шаблонов в обычный Си++.

ну и т.д. Если вспомнить - таких "ляпов" найдется дофига.

Re:

Ну и разумеется мое любимое ">>" и "> >" - вообще забавно

Re:

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

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

>лючевое слово typename которое вообще один большой костыль,

В чем заключается?

>предназначенный только для того чтобы просто интегрировать механизм
>шаблонов в обычный Си++.

Непонятен смысл этой фразы, поясни что это за обычный С++

Re:

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

Re:

ключевые слова typename и template(это которое obj.template func<param>(), а не то что вы подумали) введены в язык, чтобы ваш бедненький процессор не перегревался при компиляции простейщего кода - раз. и еще две магических фразы остаются для самостоятельного изучения: export + two phase lookup

Re:

> ключевые слова typename и template(это которое obj.template func(), а не то что вы подумали) введены в язык, чтобы ваш бедненький процессор не перегревался при компиляции простейщего кода -раз.

Первое - мне насрать зачем были введены эти ключевые слова. Если та или иная конструкция языка не решает никакой полезной задачи, а служит только для того чтобы говорить кривому компилятору как правильно парсить мой код, то фтопку такие конгструкции. Язык содержащий такие конструкции как обязательные составляющие следует немедленно признать убогим и кривым. Ч.т.д.

Второе - я конечно видел более или менее нормальные реализации export template-ов, но отнюдь не везде. А gcc это уже поддерживает, и с какой версии ? А visual с++ ? A borland C++ ?

Как я уже говорил эффективно сделать export template реально сложно. Максимум - костыли вроде промежуточного дампа AST на первом проходе компилятора (считай те же precompiled heades), на втором - пытаться разобраться куда какой шаблон следует цеплять, а это отнюдь не просто ибо в Си++ еще есть такая штука как препроцессор. Кстати если ты даже сдампил шаблонное AST, то тебе надо постоянно следить за макроопределениями ибо твое сдампленное AST может быть просто неактуальным при следующей компиляции.

И не надо мне балакать что это есть правильный язык. Си++ это костыль на костыле уже бог знает в каком поколении.

Двухпроходный анализ (если такое уже сделано) тоже не во всех случаях спасет ибо тут на сцене появляется его величество препроцессор. В одном один и тот же

Re:

Почти всегда можно будет обойтись без экспортирования шаблонов.

Re:

> Почти всегда можно будет обойтись без экспортирования шаблонов.

Ну прально. Долой нормальное разделение интерфейса и реализации! Каменный век рулит!

Re:

>Первое - мне насрать зачем были введены эти ключевые слова. >Если та или иная конструкция языка не решает никакой полезной задачи

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

two phase lookup, первая phase - точка определения(definition) шаблона - резолвятся все non-dependent names, вторая phase - точка воплощения(instaniation) - резолвятся все dependent names, т.к. уже известны реальные параметры шаблона.

зачем это нужно: 1. некоторые ошибки можно словить еще при просмотре определения шаблона, в первой фазе. 2. компилятор должен как-то распарсить определение шаблона и понять что же это за штука такая T::type, и если вы не скажете ему, что это есть имя типа (type name), то как компилятор это парсить буддет вообще? 3. вышесказанное особенно важно при наличии export, т.к. у нас нету даже исходника шаблона, то компилятор никак не может определить что же от него хотят, и даже не может сделать AST, потому что не знает чем является какое-то имя.

вот ссылочка еще если интересно: http://www.gotw.ca/gotw/035.htm

и еще маленький ликбез: перепроцессор работает ДО компилятора.

afaik никто не поддерживает template export кроме comeau

Re:

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

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

> 1. некоторые ошибки можно словить еще при просмотре определения шаблона, в первой фазе.

Ага, в основном синтаксические. Бооольшое достижение, ради которого программер вынужден везде писать тупое typename. Я бы сказал это следствие другого глюка - контекстно-зависимости грамматики

> и еще маленький ликбез: перепроцессор работает ДО компилятора.

Спасибо за ценную информацию

Re:

>>лючевое слово typename которое вообще один большой костыль,

> В чем заключается?

typename - способ разрулить контекстно-зависимость грамматики Си++ приментиельно к шаблонам. Фишка в том что компилятор невсегда на синтаксическом уровне может определить семантику некоторых конструкций. Например, а * b. Как это понимать ? а умножить на b или объявление переменной b которая явл указателем на a ? В обычном нешаблонном си++ разруливалось так же как и в Си. В таблице типов языковых сущностей смотрится что есть 'a', если 'a' - тип данных, то соотв. это декларация переменной, если 'a'- переменная, то все предложение есть выражение языка и т.д. Таких случаев несколько. Применительно к шаблонам так сделать нельзя ибо еще неизвестно что такое 'a'. Раз нельзя так сделать то нельзя и нормально распарсить шаблон, раз нельзя распарсить шаблон, то реализация шаблонов получается не сильно эффективнее макрогенератора. И соотв. ошибки в коде шаблонов выявляются по минимому.

Кстати, например gcc 3.х и borlad C++ builder (на остальных не проверял) вполне нормально хавают априори бредовый код:

template <typename A> class CLS {

int foo() { saldklaskdlasjdkasjfjsrhfjhsadjfhasjhsdjf;}

};

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

Re:

> afaik никто не поддерживает template export кроме comeau

Поддерживает EDG-шный фронтенд.

Re:

> template <typename A> class CLS {
> int foo() { saldklaskdlasjdkasjfjsrhfjhsadjfhasjhsdjf;}
> };

Так и супер, с точки зрения синтаксиса тут все нормально, проблемы
начнутся в момент инстанционирования, это можно использовать себе
же на руку.

Про typename все что ты сказал абсолютно справедливо, но давай
к этому относится не как к костылю, а как к особенности языка и
закончем флеймить на эту тему, ok?

Re:

> Так и супер, с точки зрения синтаксиса тут все нормально, проблемы начнутся в момент инстанционирования, это можно использовать себе же на руку.

Так тогда лучше использовать просто препроцессор. Зачем такие сложности ? Задача шаблонов - с одной стороны предоставить возможности статического полиморфизма и generic programming-а (или как там это пишется), а с другой - недопустить беспредела как при использовании препроцессора, если они хотябы одну из этих задач не решают - фтопку их. Кстати gcc 4 такой код уже не съест.

> Про typename все что ты сказал абсолютно справедливо, но давай к этому относится не как к костылю, а как к особенности языка и закончем флеймить на эту тему, ok?

Как к этой конструкции относится - вопрос болтологический. Я отношусь к ней как к костылю ибо я вижу те огрехи языкового дизайна которые привели к ее использованию. Никакой полезной семантики в этой конструкции нет. У языка программирования 2 основные задачи: 1) быть интерфейсом между человеком и компьютеров 2) быть интерфейсом между людьми. Излишняя сложность и большой набор чисто языковых условностей мешает выполнять как 1-ю так и 2-ю задачи. Смысл ?

Re:

> Так тогда лучше использовать просто препроцессор. Зачем такие
> сложности ?

Дык для generic'a и нужно, тупой но все же пример, в реальных
задачах все по другому:

--- [CUT_HERE] ---
template <class T>
struct fake_type {};

template <class T>
struct foo
{
void bar()
{
fake_type<T>::this_method_is_deprecated_use_foo_bar;
}
void foo_bar() {}
};

int main()
{
foo<int>().bar();
}
--- [CUT_HERE] ---