Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, _nn_, Вы писали:
КЛ>>Сообственно вопрос состоит в том зачем это надо?
__>Чтобы отделить объявление от определения. __>Когда все в заголовочных файлах появляется проблема рекурсивного включения файлов
__>А так ее не будет. __>Но это нужнен класс где мы знаем специализации, например basic_string.
Разве ее так нужно разруливать?
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, _nn_, Вы писали:
__>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>Здравствуйте, _nn_, Вы писали:
КЛ>>>Сообственно вопрос состоит в том зачем это надо?
__>>Чтобы отделить объявление от определения. __>>Когда все в заголовочных файлах появляется проблема рекурсивного включения файлов
__>>А так ее не будет. __>>Но это нужнен класс где мы знаем специализации, например basic_string. КЛ>Разве ее так нужно разруливать?
А как вы предлагаете ?
Я хочу реализацию только в .cpp файле.
export помог бы, но поддержка компиляторами нужна
Здравствуйте, _nn_, Вы писали:
__>Здравствуйте, Константин Л., Вы писали:
КЛ>>Здравствуйте, _nn_, Вы писали:
__>>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>Здравствуйте, _nn_, Вы писали:
КЛ>>>>Сообственно вопрос состоит в том зачем это надо?
__>>>Чтобы отделить объявление от определения. __>>>Когда все в заголовочных файлах появляется проблема рекурсивного включения файлов
__>>>А так ее не будет. __>>>Но это нужнен класс где мы знаем специализации, например basic_string. КЛ>>Разве ее так нужно разруливать?
__>А как вы предлагаете ? __>Я хочу реализацию только в .cpp файле. __>export помог бы, но поддержка компиляторами нужна
ИМХО, шаблоны нужны для написания мексимально абстрактного интерфейса -> минимум используемых типов. Может надо без шаблонов писать?
Опиши проблему, может я невпопад
"_nn_" <16901@users.rsdn.ru> wrote in message news:1876823@news.rsdn.ru... > Допустим есть шаблонный класс и известно количество специализаций. > Можно эти специализации реализовать в .cpp через шаблонный класс: >
> > В main.cpp используется шаблонный класс, в a.cpp реализация самого шаблона и классы прослойки для перехода из a.h в a.cpp. > > Недостатки: > Нужно писать полное объявление специализированного класса. > Нужно писать реализацию методов класса. > > Сообственно вопрос состоит в том как недостатки убрать, например с помощью препроцессора
Может я не совсем понял задачу, но, по-моему, это все решается при помощи явных запросов на инстанцирование:
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, _nn_, Вы писали:
__>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>Здравствуйте, _nn_, Вы писали:
__>>>>Здравствуйте, Константин Л., Вы писали:
КЛ>>>>>Здравствуйте, _nn_, Вы писали:
КЛ>>>>>Сообственно вопрос состоит в том зачем это надо?
__>>>>Чтобы отделить объявление от определения. __>>>>Когда все в заголовочных файлах появляется проблема рекурсивного включения файлов
__>>>>А так ее не будет. __>>>>Но это нужнен класс где мы знаем специализации, например basic_string. КЛ>>>Разве ее так нужно разруливать?
__>>А как вы предлагаете ? __>>Я хочу реализацию только в .cpp файле. __>>export помог бы, но поддержка компиляторами нужна КЛ>ИМХО, шаблоны нужны для написания мексимально абстрактного интерфейса -> минимум используемых типов. Может надо без шаблонов писать?
Может и без, но без них никак =) КЛ>Опиши проблему, может я невпопад
Классический пример это string.
Допустим есть:
Теперь string_traits он разный для char и wchar_t, т.е. это два разных класса под одним названием, лучше в .cpp их ).
Если можно string в .cpp засунуть, почему не сделать это ?
Так при изменении внутреннего кода не нужно будет перекаомпилировать все
Конкретно еще одна проблема это рекурсивные include-ы:
Что тут делать ?
Вы ответите предварительное объявление и будете правы, но когда include происходит для 20 файлов, получается длинная цепочка, которую нужно разорвать как-то..
И где-то посередине получается, что string это неполный тип, который использовать нельзя, а что делать если нужно ?
Придется использовать указатель или умный указатель, который поддерживает неполные типы.
__>Что тут делать ? __>Вы ответите предварительное объявление и будете правы, но когда include происходит для 20 файлов, получается длинная цепочка, которую нужно разорвать как-то.. __>И где-то посередине получается, что string это неполный тип, который использовать нельзя, а что делать если нужно ? __>Придется использовать указатель или умный указатель, который поддерживает неполные типы.
если #include <string.hpp> выкинуть, то это должно решить проблему?
Здравствуйте, Константин Л., Вы писали:
КЛ>Здравствуйте, _nn_, Вы писали:
КЛ>[]
КЛ>согласен
__>>Конкретно еще одна проблема это рекурсивные include-ы: __>>
__>>Что тут делать ? __>>Вы ответите предварительное объявление и будете правы, но когда include происходит для 20 файлов, получается длинная цепочка, которую нужно разорвать как-то.. __>>И где-то посередине получается, что string это неполный тип, который использовать нельзя, а что делать если нужно ? __>>Придется использовать указатель или умный указатель, который поддерживает неполные типы.
КЛ>если #include <string.hpp> выкинуть, то это должно решить проблему?
Решает если использовать:
Но все равно не решает проблемы перекомпиляции.
Вот при изменении string_traits все кто используют string.hpp должны перекомпилироваться, вопрос зачем, если достаточно только тех, кто страдает прямой зависимостью от string_traits.
"_nn_" <16901@users.rsdn.ru> wrote in message news:1876992@news.rsdn.ru... > Здравствуйте, rg45, Вы писали: > > <skip> > > R>Может я не совсем понял задачу, но, по-моему, это все решается при помощи явных запросов на инстанцирование: > > R>
> > А где определение aint::f и along:;f ? > Ведь они замещают ax<T>::f, и следовательно должны быть определенны. > Или я не прав ?
Ну если реализация нужна именно такая как ты показывал в примере — простое делегирование вызова базовой функции — то все в порядке. А вот если реализация, данная основным шаблоном, не годится по каким то причинам, и прийдется по-разному реализовывать различные специализации, то этот подход не прокатит (Я имею ввиду VC 7.1-8.0, по стандарту то вообще все легко и просто )
Posted via RSDN NNTP Server 2.0
--
Не можешь достичь желаемого — пожелай достигнутого.
R>"_nn_" <16901@users.rsdn.ru> wrote in message news:1876992@news.rsdn.ru... >> Здравствуйте, rg45, Вы писали: >> >> <skip> >> >> R>Может я не совсем понял задачу, но, по-моему, это все решается при помощи явных запросов на инстанцирование: >> >> R>
>> >> А где определение aint::f и along:;f ? >> Ведь они замещают ax<T>::f, и следовательно должны быть определенны. >> Или я не прав ?
R>Ну если реализация нужна именно такая как ты показывал в примере — простое делегирование вызова базовой функции — то все в порядке. А вот если реализация, данная основным шаблоном, не годится по каким то причинам, и прийдется по-разному реализовывать различные специализации, то этот подход не прокатит (Я имею ввиду VC 7.1-8.0, по стандарту то вообще все легко и просто )
Как раз и прокатит хорошо..
Нет ведь обязательства делегирования.
Например если есть char_traits<T>, то можно делегировать только для истинно шаблонных функций, а для нешаблонных своя реализация без делегации
"_nn_" <16901@users.rsdn.ru> wrote in message news:1877010@news.rsdn.ru...
> R>Ну если реализация нужна именно такая как ты показывал в примере — простое делегирование вызова базовой функции — то все в порядке. А вот если реализация, данная основным шаблоном, не годится по каким то причинам, и прийдется по-разному реализовывать различные специализации, то этот подход не прокатит (Я имею ввиду VC 7.1-8.0, по стандарту то вообще все легко и просто ) > Как раз и прокатит хорошо.. > Нет ведь обязательства делегирования. > Например если есть char_traits<T>, то можно делегировать только для истинно шаблонных функций, а для нешаблонных своя реализация без делегации
Нет, я имел ввиду, что компиляторы 7.1-8.0 не потянут — ругнутся, что явное инстанцирование для специализации шаблонного класса не поддерживается.
Posted via RSDN NNTP Server 2.0
--
Не можешь достичь желаемого — пожелай достигнутого.
R>"_nn_" <16901@users.rsdn.ru> wrote in message news:1877010@news.rsdn.ru...
>> R>Ну если реализация нужна именно такая как ты показывал в примере — простое делегирование вызова базовой функции — то все в порядке. А вот если реализация, данная основным шаблоном, не годится по каким то причинам, и прийдется по-разному реализовывать различные специализации, то этот подход не прокатит (Я имею ввиду VC 7.1-8.0, по стандарту то вообще все легко и просто ) >> Как раз и прокатит хорошо.. >> Нет ведь обязательства делегирования. >> Например если есть char_traits<T>, то можно делегировать только для истинно шаблонных функций, а для нешаблонных своя реализация без делегации
R>Нет, я имел ввиду, что компиляторы 7.1-8.0 не потянут — ругнутся, что явное инстанцирование для специализации шаблонного класса не поддерживается.
Ясно
Как обойти ?
"_nn_" <16901@users.rsdn.ru> wrote in message news:1877018@news.rsdn.ru... > Здравствуйте, rg45, Вы писали: > > > R>"_nn_" <16901@users.rsdn.ru> wrote in message news:1877010@news.rsdn.ru... > >>> R>Ну если реализация нужна именно такая как ты показывал в примере — простое делегирование вызова базовой функции — то все в порядке. А вот если реализация, данная основным шаблоном, не годится по каким то причинам, и прийдется по-разному реализовывать различные специализации, то этот подход не прокатит (Я имею ввиду VC 7.1-8.0, по стандарту то вообще все легко и просто ) >>> Как раз и прокатит хорошо.. >>> Нет ведь обязательства делегирования. >>> Например если есть char_traits<T>, то можно делегировать только для истинно шаблонных функций, а для нешаблонных своя реализация без делегации > > R>Нет, я имел ввиду, что компиляторы 7.1-8.0 не потянут — ругнутся, что явное инстанцирование для специализации шаблонного класса не поддерживается. > Ясно > Как обойти ?
Ждать компилятора с поддержкой export для шаблонов, ну а пока делать что то типа того, что делаешь ты.
Posted via RSDN NNTP Server 2.0
--
Не можешь достичь желаемого — пожелай достигнутого.
R>"_nn_" <16901@users.rsdn.ru> wrote in message news:1877018@news.rsdn.ru... >> Здравствуйте, rg45, Вы писали: >> >> >> R>"_nn_" <16901@users.rsdn.ru> wrote in message news:1877010@news.rsdn.ru... >> >>>> R>Ну если реализация нужна именно такая как ты показывал в примере — простое делегирование вызова базовой функции — то все в порядке. А вот если реализация, данная основным шаблоном, не годится по каким то причинам, и прийдется по-разному реализовывать различные специализации, то этот подход не прокатит (Я имею ввиду VC 7.1-8.0, по стандарту то вообще все легко и просто ) >>>> Как раз и прокатит хорошо.. >>>> Нет ведь обязательства делегирования. >>>> Например если есть char_traits<T>, то можно делегировать только для истинно шаблонных функций, а для нешаблонных своя реализация без делегации >> >> R>Нет, я имел ввиду, что компиляторы 7.1-8.0 не потянут — ругнутся, что явное инстанцирование для специализации шаблонного класса не поддерживается. >> Ясно >> Как обойти ?
R>Ждать компилятора с поддержкой export для шаблонов, ну а пока делать что то типа того, что делаешь ты.
Плохо..
Посему и вопрос как можно улучшить, допустим через препроцессор, генерацию кода в моем подходе
"_nn_" <16901@users.rsdn.ru> wrote in message news:1877038@news.rsdn.ru...
>>> R>Нет, я имел ввиду, что компиляторы 7.1-8.0 не потянут — ругнутся, что явное инстанцирование для специализации шаблонного класса не поддерживается. >>> Ясно >>> Как обойти ? > > R>Ждать компилятора с поддержкой export для шаблонов, ну а пока делать что то типа того, что делаешь ты. > Плохо.. > Посему и вопрос как можно улучшить, допустим через препроцессор, генерацию кода в моем подходе
Предлагаю такой вариант, как мне кажется, убиты все зайцы:
//a.h
//Класс для контроля типов, с которыми инстанцируется шаблон класса объекта
//Дается только лишь предварительное объявление.
//Полные объявления даются только для разрешенных специализацийtemplate<typename T> class selector;
//Шаблон класса объектаtemplate<typename T>
struct a : selector<T>
{
void f(T t);
};
//Разрешенные типы для инстанцирования (можно одеть в макрос)template<> class selector<int>{};
template<> class selector<long>{};
template<> class selector<double>{};
//a.cpp#include"a.h"//основной шаблонtemplate<typename T>
void a<T>::f(T t)
{
std::cout << t << std::endl;
};
//специализация для doublevoid a<double>::f(double t)
{
std::cout << "double: " << t << std::endl;
}
//Явное инстанцирование классов, порождаемых основным шаблономtemplate struct a<int>;
template struct a<long>;
Проблема в следущем коде, в том, что получаются несколько определений шаблона в разных файлах.
На что линкер ругается, что ему и положенно.
Можно указать ингнорировать второе определение, но это решение для слабых
P.S.
Если обойти эту проблему, то можно почти свободно реализовать шаблоны в .cpp
Здравствуйте, _nn_, Вы писали:
__>А как вы предлагаете ? __>Я хочу реализацию только в .cpp файле. __>export помог бы, но поддержка компиляторами нужна