_FRED_,

Извиняюсь, что посреди большой философии с такими частностями. Тем не менее...

> Читал, что экспорт шаблонов ещё не сделан.

Сделан в EDG. Сравнительно давно доступен в Comeau.

> Нужен? "Необходим!" ответят, я думаю, многие.

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

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

Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Извиняюсь, что посреди большой философии с такими частностями. Тем не менее...
Очень жду

>> Читал, что экспорт шаблонов ещё не сделан.
ПК>Сделан в EDG. Сравнительно давно доступен в Comeau.

>> Нужен? "Необходим!" ответят, я думаю, многие.
ПК>Уверяю, не необходим. Кой-какая польза от него есть, но не принципиальная. Заключается в том, что при наличии экспорта шаблонов можно перекомпилировать не все файлы, зависящие от определения изменившегося шаблона, а только один из них. Имхо, намного полезнее введение модулей, чему, впрочем, экспорт шаблонов, вроде, не мешает.

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

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

Спасибо, с этим я понял. Куда ещё можно "углубить" С++? вот что мне интересно. Когда увидел книжки про колдовство с шаблонами стало ясно что их ещё изучать и изучать (не только мне но и "Говорителям Об") — но, мне кажется, это всё-таки "вширь", а "вглубь" — это новое, а не изучение имеющегося.

Здравствуйте, _FRED_, Вы писали:

_FR>Здравствуйте, Павел Кузнецов, Вы писали:
ПК>>Извиняюсь, что посреди большой философии с такими частностями. Тем не менее...
_FR>Очень жду

Эх! смайликом обшибся. На сомом-то деле я
_FR> Очень жду

Здравствуйте, _FRED_, Вы писали:

_FR>Эх, а я думал можно будет их в библиотеки вставлять и отдавать только хидер...

C++ные шаблоны нельзя скомпилировать принципиально. Для компиляции нужно нечто вроде нетовских дженериков.

AndrewVK,

> _FR> Эх, а я думал можно будет их в библиотеки вставлять и отдавать только хидер...

> C++ные шаблоны нельзя скомпилировать принципиально. Для компиляции нужно нечто вроде нетовских дженериков.

Это не так. Скомпилировать шаблоны до уровня распространения в виде статических библиотек вполне возможно. Естественно, это не будут "обыкновенные" .obj-файлы, но и сборки .Net ими тоже не являются. В общем, относительно компиляции шаблонов в промежуточный код, вопрос в том, настолько ли это нужно, чтобы этим заниматься, т.к. хранение шаблонов в промежуточном виде требует серьезных дополнительных усилий по сравнению с хранением шаблонов в их первичной, текстовой форме.

Здравствуйте, Павел Кузнецов, Вы писали:
>> _FR> Эх, а я думал можно будет их в библиотеки вставлять и отдавать только хидер...
>> C++ные шаблоны нельзя скомпилировать принципиально. Для компиляции нужно нечто вроде нетовских дженериков.
ПК>Это не так. Скомпилировать шаблоны до уровня распространения в виде статических библиотек вполне возможно. Естественно, это не будут "обыкновенные" .obj-файлы, но и сборки .Net ими тоже не являются. В общем, относительно компиляции шаблонов в промежуточный код, вопрос в том, настолько ли это нужно, чтобы этим заниматься, т.к. хранение шаблонов в промежуточном виде требует серьезных дополнительных усилий по сравнению с хранением шаблонов в их первичной, текстовой форме.

Спасибо, об этой возможности я даже не слышал. Позавчера просто вечером тоска навалилась и принялся дочитывать журнал. Между явой а дельфи попал на эту статью Шаблоны и модули

Автор(ы): Валерий Лаптев
Дата: 30.10.2004
В этой статье рассказывается о методах отделения реализации шаблона от его интерфейсной части и о том, как можно заставить это работать на популярных компиляторах наподобие MS Visual C++.

. В статье сказано, в частности, "Таким образом, большинство современных компиляторов C++ не позволяет "делить" шаблоны на части и транслировать отдельно.", в чём мне повезло задолго до прочтения убедиться. И на слово "практически" в самом последнем примечании я если и обратил внимание, то сегодня уже не вспомнил. В контексте статьи я и сделал смелый и неправильный вывод. Учту.
Скорость компиляции меня давно уже не беспокоит (в контексте топика позвольте умилиться запуску VS 6.0 на 486 с 15 Мб памяти и 20 на диске ).

Кстати о скорости. Начал замечать за собой такую неприятную ( ) особенность — вместо того чтоб десятый раз пробежаться глазами по строкам, руки тянутся нажать Build и сразу получить все (ну конечно же не все, но...) ответы. Не те ли это синдромы, от которых предостерегает SchweinDeBurg? А?

Здравствуйте, Павел Кузнецов, Вы писали:

>> C++ные шаблоны нельзя скомпилировать принципиально. Для компиляции нужно нечто вроде нетовских дженериков.

ПК>Это не так. Скомпилировать шаблоны до уровня распространения в виде статических библиотек вполне возможно. Естественно, это не будут "обыкновенные" .obj-файлы, но и сборки .Net ими тоже не являются.

Естественно в такой постановке возможно. Можно например исходники запаковать .
На самом деле вопрос в том что такое компиляция. Плюсовые шаблоны нельзя обработать дальше AST и при экспорте максимум что можно сделать это сохранить его в бинарном виде. Все равно компилятору (именно компилятору, а не линкеру) потом придется с этими шаблонами работать. А вот в дотнете дженерики именно скомпилированы, там нормальный IL-код внутри. Это примерно как если бы в С++ шаблон можно было бы запихать в dll, да так чтобы при смене этой dll поведение программы изменилось без перекомпиляции использующего кода. Для плюсов это невозможно, поскольку невозможно до развертывания шаблона определить токен используемых методов (адрес статического метода, номер слота виртуального и т.п.).
Какие от этого бенефиты? Вобщем то вполне очевидные:
1) Нормальная работа в компонентной среде, возможность создания дженерик-компонентов.
2) Быстрая компиляция. Наличие в проекте дженериков практически не влияет на скорость компиляции.
3) Нормальная работа Intellisence, рефакторинга. Нормальная диагностика ошибок.
4) Отсутствие дублирования кода в скомпилированных модулях.
5) В условиях managed-языков — меньше нагрузка на JIT.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>AndrewVK,

>> _FR> Эх, а я думал можно будет их в библиотеки вставлять и отдавать только хидер...

>> C++ные шаблоны нельзя скомпилировать принципиально. Для компиляции нужно нечто вроде нетовских дженериков.

ПК>Это не так. Скомпилировать шаблоны до уровня распространения в виде статических библиотек вполне возможно. Естественно, это не будут "обыкновенные" .obj-файлы, но и сборки .Net ими тоже не являются. В общем, относительно компиляции шаблонов в промежуточный код, вопрос в том, настолько ли это нужно, чтобы этим заниматься, т.к. хранение шаблонов в промежуточном виде требует серьезных дополнительных усилий по сравнению с хранением шаблонов в их первичной, текстовой форме.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, AndrewVK, Вы писали:

AVK>Здравствуйте, Павел Кузнецов, Вы писали:

>>> C++ные шаблоны нельзя скомпилировать принципиально. Для компиляции нужно нечто вроде нетовских дженериков.

ПК>>Это не так. Скомпилировать шаблоны до уровня распространения в виде статических библиотек вполне возможно. Естественно, это не будут "обыкновенные" .obj-файлы, но и сборки .Net ими тоже не являются.

AVK>Естественно в такой постановке возможно. Можно например исходники запаковать .
AVK>На самом деле вопрос в том что такое компиляция. Плюсовые шаблоны нельзя обработать дальше AST и при экспорте максимум что можно сделать это сохранить его в бинарном виде. Все равно компилятору (именно компилятору, а не линкеру) потом придется с этими шаблонами работать. А вот в дотнете дженерики именно скомпилированы, там нормальный IL-код внутри. Это примерно как если бы в С++ шаблон можно было бы запихать в dll, да так чтобы при смене этой dll поведение программы изменилось без перекомпиляции использующего кода.

Это достигается за счет очень серьёзных ограничений на возможности дженериков. Для шаблонов это неприемлимо.

AVK>Для плюсов это невозможно, поскольку невозможно до развертывания шаблона определить токен используемых методов (адрес статического метода, номер слота виртуального и т.п.).
AVK>Какие от этого бенефиты? Вобщем то вполне очевидные:

AVK>1) Нормальная работа в компонентной среде, возможность создания дженерик-компонентов.
AVK>2) Быстрая компиляция. Наличие в проекте дженериков практически не влияет на скорость компиляции.
AVK>3) Нормальная работа Intellisence, рефакторинга. Нормальная диагностика ошибок.

AVK>4) Отсутствие дублирования кода в скомпилированных модулях.

Нет никакого "дублирования кода" в шаблонах. Код, сгенерённый из шаблона для существенно разных параметров приципиально разный. Это не один и тот же код, повторенный несколько раз, это просто разный код. Возьми, например, какоё-нибудь алгоритм, типа for_each и примени его к итератору вектора и к итератору списка. Получишь существенно разный результирующий код. В этом и заключается главное свойство шаблонов -- они позволяют программировать абстрактно на очень высоком уровне абстракции, не теряя при этом в производительности.

Да, и кстати, кто-то тут любит повторять, что "память больше не ресурс"?

AVK>5) В условиях managed-языков — меньше нагрузка на JIT.

Это странный бенефит. Эачем пользователю JIT, если он купил и установил один раз приложение? На хрена ему каждый раз при загрузке его докомпилировать? Это полный идиотизм.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, AndrewVK, Вы писали:
>>> C++ные шаблоны нельзя скомпилировать принципиально. Для компиляции нужно нечто вроде нетовских дженериков.
[skipped]
AVK>Какие от этого бенефиты? Вобщем то вполне очевидные:
AVK>1) Нормальная работа в компонентной среде, возможность создания дженерик-компонентов.
Угу

Автор: _FRED_
Дата: 29.12.04

AVK>2) Быстрая компиляция. Наличие в проекте дженериков практически не влияет на скорость компиляции.
AVK>3) Нормальная работа Intellisence, рефакторинга. Нормальная диагностика ошибок.
Ага! Значит у всех в С++ шаблонах оно не работает И, к слову, сильно ещё сама среда не готова к дженерикам. Но мы надеемся, "Думаю, к релизу исправят"© VladD2
AVK>4) Отсутствие дублирования кода в скомпилированных модулях.
AVK>5) В условиях managed-языков — меньше нагрузка на JIT.

Да, но отсюда же и некоторые их недостатки? что есть отдельная тема

Шахтер,

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

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

Кто-то из EDG (по-моему, Вандевурд или Адамчик) где-то когда-то (*) писал, что их эксперименты показали, что особого ускорения замечено не было.

> Насчет дополнительных усилий. При разборе заголовка с шаблонами, компилятор всё равно переводит их в некоторое внутреннее представление, работа с которым, естественно, более эффективна, чем с исходных текстовым. Всё что нужно -- сериализовать это представление в бинарную форму. Это достаточно стандартная задача.

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

---

(*) кто-то ... где-то ... когда-то ... — согласен, неточностей многовато, но искать кто, где и когда конкретно, честно говоря, лень

Здравствуйте, Шахтер, Вы писали:

Ш>Это достигается за счет очень серьёзных ограничений на возможности дженериков. Для шаблонов это неприемлимо.

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

Ш>Нет никакого "дублирования кода" в шаблонах. Код, сгенерённый из шаблона для существенно разных параметров приципиально разный.

Да? А если мы возьмем обыкновенные контейнеры? Там именно что дублирование — разница только в адресах функций и размерах оперируемых данных.

Ш>Да, и кстати, кто-то тут любит повторять, что "память больше не ресурс"?

А при чем тут память? Речь о размерах файлов и скорости работы линкера.

AVK>>5) В условиях managed-языков — меньше нагрузка на JIT.

Ш>Это странный бенефит.

Чем?

Ш> Эачем пользователю JIT, если он купил и установил один раз приложение?

JIT нужен для работы managed-языков. Некоторые вещи — вроде CAS, без управляемого кода практически нереализуемы.

Ш>Все эти бенефиты не стоят тех ограничений на использование, которые приходится накладывать на дженерики.

Спорный вопрос.

Здравствуйте, _FRED_, Вы писали:

_FR>Ага! Значит у всех в С++ шаблонах оно не работает

Нет, нормально не работает. А ты не знал?

_FR> И, к слову, сильно ещё сама среда не готова к дженерикам.

Какая среда?

AVK>>5) В условиях managed-языков — меньше нагрузка на JIT.

_FR>Да, но отсюда же и некоторые их недостатки?

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

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Кто-то из EDG (по-моему, Вандевурд или Адамчик) где-то когда-то (*) писал, что их эксперименты показали, что особого ускорения замечено не было.

Вполне предсказуемо. Парсинг исходников далеко не самая медленная операция, на ней много не съэкономишь.

Здравствуйте, Шахтер, Вы писали:

Ш>Думаю, что это было бы полезно, поскольку это помогло бы ускорить процесс инстантинации шаблонов. Насчет дополнительных усилий. При разборе заголовка с шаблонами, компилятор всё равно переводит их в некоторое внутреннее представление, работа с которым, естественно, более эффективна, чем с исходных текстовым. Всё что нужно -- сериализовать это представление в бинарную форму. Это достаточно стандартная задача.

Щас я такое выдам...
На самом деле, форма хранения не важна. Проблема C++ в том, что все стараются придерживаться замшелой парадигмы о раздельной компиляции. Это работает для C и Фортрана, но C++ раздельную компиляцию давным-давно перерос — отсюда все проблемы с экспортом шаблонов. Как верно заметил AndrewVK, можно было бы просто сохранять функции шаблонов в Obj-файлах в исходном виде. Но при этом линкер должен будет вызывать компилятор снова и до-компилировать инстанциируемые шаблоны. А это будет противоречить идее о раздельной компиляции. Раздельная компиляция в современном C++ — это лишь замшелая традиция и ничего более. В конце концов, если посмотреть на командную строку практически любого современного компилятора, то при помощи него можно и компилировать и собирать бинарник. Понятно, что внутри он вызывает ld, но снаружи это выглядит так, как будто я создаю исполняемый бинарник при помощи одной единственной команды — "g++". Если бы не было этого параноидального разделения на компилятор и линкер (другими словами, чтобы линкер тоже мог компилировать), все было бы куда как проще. Больше всего меня поразило, как разрешается конфликт множественных инстансов на сановском C++ workshop. Это в натуре — "шедевр". Там одинаковые инстансы из разных библиотек просто замещают .o файлы с одинаковыми именами. Имена файлов получаются при помощи некой хеш-функции из имени шаблона с параметрами. Что произойдет в случае конфликта (collision) хэш-функции — я так и не знаю.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Шахтер,

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

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

ПК>Кто-то из EDG (по-моему, Вандевурд или Адамчик) где-то когда-то (*) писал, что их эксперименты показали, что особого ускорения замечено не было.

Ну, еджиссонам виднее.

>> Насчет дополнительных усилий. При разборе заголовка с шаблонами, компилятор всё равно переводит их в некоторое внутреннее представление, работа с которым, естественно, более эффективна, чем с исходных текстовым. Всё что нужно -- сериализовать это представление в бинарную форму. Это достаточно стандартная задача.

ПК>Кроме этого шага есть еще, например, выдача диагностики, которую во многих реализациях намного легче осуществлять, имея в распоряжении исходный код.

ПК>

---

ПК>(*) кто-то ... где-то ... когда-то ... — согласен, неточностей многовато, но искать кто, где и когда конкретно, честно говоря, лень

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, AndrewVK, Вы писали:

Ш>>Нет никакого "дублирования кода" в шаблонах. Код, сгенерённый из шаблона для существенно разных параметров приципиально разный.

AVK>Да? А если мы возьмем обыкновенные контейнеры? Там именно что дублирование — разница только в адресах функций и размерах оперируемых данных.

Да? А не освежить ли тебе память и не посмотреть ли на то, как устроен итератор по вектору и по списку?

/* Sum() */ 

template <class T,class Ptr>
void T Sum(Ptr ptr,Ptr lim)
 {
  T ret=T();
  
  for(; ptr!=lim ;++ptr) ret+=(*ptr);
  
  return ret;
 }
 
/* struct NodeList<T> */  

template <class T>
struct NodeList
 {
  NodeList<T> *next;
  T object;
 };
 
/* struct ListPtr<T> */  

template <class T>
struct ListPtr
 {
  NodeList<T> *ptr;
  
  void operator ++ () { ptr=ptr->next; }
  
  const T & operator * () const { return ptr->object; }
 };
 
/* main() */ 

int main()
 {
  ...
  
  int *ptr1=...,*lim1=...;
  
  Sum<int>(ptr1,lim1);
  
  ...
  
  ListPtr<int> ptr2=...,lim2=...;
  
  Sum<int>(ptr2,lim2);
  
  ...
 
  return 0;
 }

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Здравствуйте, AndrewVK, Вы писали:
_FR>>Ага! Значит у всех в С++ шаблонах оно не работает
AVK>Нет, нормально не работает. А ты не знал?
Наблюдал, но думал что я их как-то неправльно использую, что надо бы залезть куда-нить в AUTOEXP.DAT и там поковыряться.
По большому счёту кроме коллекций МФЦ ни с чем дела не имел, кинул взгляд на "Modern C++ Design" и стал мечтать посвятить отпуск этому Чуду.
Не потому что так хочется применять, но хочется знать, самому так научиться. Потому что удивительно.

_FR>> И, к слову, сильно ещё сама среда не готова к дженерикам.
AVK>Какая среда?
Извини, не ясно высказался. Среда разработки. Whidbey. Столкнулся с парой неприятных моментов, но, к стыду своему, пока не нашёл времени попросить помощи в подготовке репорта в feedback.

AVK>>>5) В условиях managed-языков — меньше нагрузка на JIT.
_FR>>Да, но отсюда же и некоторые их недостатки?
AVK>Разумеется. Но надо понимать главное — с синтаксическими шаблонами ни о какой компонентности речи уже не и дет. ИМХО для дотнета это смертельный недостаток, поскольку коллекции, которые нельзя передавать между компонентами резко теряют в своей привлекательности. А для метапрограммирования я думаю нужно что нибудь попривлекательнее шаблонов.
Да! Это другое. Ну почему, например, не позволить, сделать такие мелочи, как, например, отдельное именование ограничения/уточнения? Я, может, слишком рьяно за них взялся, но уже это становится актуальным, или позволить using (directive) внутри класса — ведь снаружи к защищённым вложенным типам не очень-то доберёшся, а в каждой указывать OrderedDioctionary<MyPrivateClassName> некошерно.
Но я почемуто из-за этого от них не отворачиваьсь и борюсь как могу (может всё-тки Александреску и Ко поситать )

Здравствуйте, McSeem2, Вы писали:

MS>Здравствуйте, Шахтер, Вы писали:

Ш>>Думаю, что это было бы полезно, поскольку это помогло бы ускорить процесс инстантинации шаблонов. Насчет дополнительных усилий. При разборе заголовка с шаблонами, компилятор всё равно переводит их в некоторое внутреннее представление, работа с которым, естественно, более эффективна, чем с исходных текстовым. Всё что нужно -- сериализовать это представление в бинарную форму. Это достаточно стандартная задача.

MS>Щас я такое выдам...
MS>На самом деле, форма хранения не важна. Проблема C++ в том, что все стараются придерживаться замшелой парадигмы о раздельной компиляции.

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

Копай Нео, копай -- летать научишься. © Matrix. Парадоксы

Шахтер,

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

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

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