Код

#include "stdafx.h" #define T_cl template<class T> using namespace std; T_cl class Tren{ public:     Tren(T var);     T get_val();     void put_val(T var); private:     T variable; }; T_cl T Tren<T>::get_val(){     return variable; } T_cl void Tren<T>::put_val(T var){     variable = var; } T_cl Tren<T>::Tren(T var): variable(var){} void main(){     Tren<int> qw(100);     qw.put_val(500);     cout << qw.get_val() << endl; }

Вот вопрос, почему перед каждым определением члена-функции класса-шаблона надо употреблять оператор template<class T> ? Ведь это неудобно, крайне.
Я уже задефайнел эту строку, но все же может я не так понял, может можно каким-то образом обьявить класс-шаблон, чтобы при определении его чл.функций можно было опускать template<class T> ?

Не выноси определение членов за пределы класса, тогда не надо будет часто писать template<class T>.

Цитата(En_t_end @ 12.4.2005, 14:17)

Вот вопрос, почему перед каждым определением члена-функции класса-шаблона надо употреблять оператор template<class T> ?

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

Цитата

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

Ну разрешилы бы создатели делать следующее, использовать template подобно namespace, то есть применять определение шаблона локально для некого блока, допустим:

Код

using namespace std; { template<class T> class Tren{ public:     Tren(T var);     T get_val();     void put_val(T var); private:     T variable; }; T Tren<T>::get_val(){     return variable; } void Tren<T>::put_val(T var){     variable = var; } Tren<T>::Tren(T var): variable(var){} }

Добавлено @ 07:54

Цитата

Не выноси определение членов за пределы класса, тогда не надо будет часто писать template<class T>.

Тогда я нарушу главный принцип абстракции данных.
И вобще мне бы хотелось реализацию отделять от интерфейса. СУВ

Это сообщение отредактировал(а) En_t_end - 12.4.2005, 07:50

Цитата

Вот вопрос, почему перед каждым определением члена-функции класса-шаблона надо употреблять оператор template<class T> ? Ведь это неудобно, крайне.

, удобно не удобно, но с твоими #define нами текст ваще не читается... так что, я хочу сказать что , что это вода в ступе... ну попрограммируй на delphi, там ваще нет template....

Цитата(En_t_end @ 12.4.2005, 07:45)

Тогда я нарушу главный принцип абстракции данных. И вобще мне бы хотелось реализацию отделять от интерфейса. СУВ

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

Существует способ отделения, но это добавляет лишний гемор, к программе.


The export keyword

This keyword was proposed as a way of separating the interface of templates from their implementation. However it adds its own complexity to the linking process, which can detract from any advantages in practice.


Exported templates

Under the exported model, you define a template in a .cpp file, compile it separately, declare it in an .h file as export, and then #include only the .h file in other translation units. For example:

Код

//func.h  export template void f(T t); // declaration  //func.cpp  template void f(T t) {//definition  //..  }  //main.cpp  #include "f.h"  int main()  {  f(7); //instantiate void func(7)  }

In reality, things aren't that simple. When a template is instantiated, dependent names (i.e., names that depend on the type of a template parameter such as t in the example above) are looked up in both the current context (i.e., where the instantiation occurs) and the context of the template's definition. The compiler cannot generate the code of a template instantiation--exported or not--without looking at its definition.

As if
This is a requirement in the C++ standard. The only way to satisfy this requirement in the case of an exported template is by an "as-if" rule: The compiler either inserts stubs into the object file, deferring code generation to a later stage, or it must somehow retrieve the template's definition by magic.

In either case, the sources containing the exported template definitions must be made available at the time of instantiation.


Вот ещё несколько страничек где можно об этом почитать.

http://asia.cnet.com/builder/program/java/...39194066,00.htm
http://www.eyt.ca/blog/item/89/
http://www.informit.com/guides/content.asp...2004-10-19&rl=1

Мда... с этим действительно гемора многа

Цитата

ну попрограммируй на delphi, там ваще нет template....

ЕКЛМН... блин, меня сразу скрючело от этой мысли
ЗЫ ладно уж придется на 10% больше строк писать

pablo, в VC7.1 эта штука не работает.

chipset Эта штука, работает только в некоторых компиляторах, например Intel C++, вот не помну в какой именно версии или 7.0 или 8.0, 8.1, и Comeau C/C++TM 4.3.3.
Если еще где, то скажите.

Цитата(En_t_end @ 12.4.2005, 07:45)

И вобще мне бы хотелось реализацию отделять от интерфейса

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

Цитата(pablo @ 12.4.2005, 05:00)

chipset Эта штука, работает только в некоторых компиляторах, например Intel C++, вот не помну в какой именно версии или 7.0 или 8.0, 8.1, и Comeau C/C++TM 4.3.3.

Насколько я помню стандарт - это включено в него.
Поэтому ещё наверное в gcc будет работать..
Шаблоны и модули почитай..

Цитата(chipset @ 13.4.2005, 04:44)

Насколько я помню стандарт - это включено в него. Поэтому ещё наверное в gcc будет работать..

В стандарт-то включено, но до сих пор, кроме Comeau (и возможно ICC, т.к. они на одном фронтэнде EDG) это нигде не реализовано. В т.ч. и в GCC: http://gcc.gnu.org/bugs.html#missing

Цитата(chipset @ 12.4.2005, 23:44)

Насколько я помню стандарт - это включено в него. Поэтому ещё наверное в gcc будет работать..

Читал я статью разработчиков по поводу реализации экспортных шаблонов.

А... вот нашел. Называется "Why We Can’t Afford Export".

Выдержка оттуда по поводу дороговизны реализации экспортных шаблонов:

Цитата

EDG, who are widely acknowledged to be among (or “the”) world’s best C++ compiler writers, report the following data from the world’s only existing implementation of export. Steve Adamczyk notes: “We don’t believe the effort is unique to our implementation; other implementers will have to do similar things.” • EDG’s effort:     • Design: 1.5 years (elapsed) to come up with a design they believed they could implement.     • Development: 3 person-years (3 people × >1 year each)         (Note: By comparison, implementing the complete Java language from scratch took the         same team 2 person-years.)   • Plus QA/testing primarily for the front end, plus their licensees’ QA/testing for complete    implementations. EDG estimates elapsed time for other implementers approx. 2½-3 years, start to finish.

И там где-то ихнея реккомендация разработчикам компиляторов по поводу реализации export templates:

Цитата

Don't do it.

Это сообщение отредактировал(а) Fantasist - 13.4.2005, 23:36

Fantasist, интересно..
Хотя я думаю что лучше было бы следовать стандарту, гораздо лучше.. Моё скромное мнение, тссазать...

Цитата(chipset @ 13.4.2005, 21:19)

Хотя я думаю что лучше было бы следовать стандарту, гораздо лучше.

Ошибки бывают и у разработчиков стандартов. На мой взгляд довольно очевидно, что это одна из таких промашек. Преимуществ ожидаемых exported templates не дает, а реализовать его очень дорого. В этом документе предлагается исключить exported templates из стандарта.