Здравствуйте. Программирую я, значит, кое какой графический интерфейс, и использую VCL. После того, как я фактически реализовал то, что мне нужно, линкер отказывается связывать все в бинарник, мотивируя это тем, что, мол, не находит определения функции. Среда программирования - BCB 6. В проект включен файл, в котором определена эта функция. Помогите, в чем проблема? Вот код разных файлов. Если этого будет недостаточно, могу выложить несколько файлов целиком. А пока...

Код

/* Файл FrameManager.h */ template < class T > struct DeleteAndNil {     static void Delete ( T &obj )     { delete obj; obj = NULL; } }; template < class T > struct NoDelete {     static void Delete ( T obj )     { return; } }; //**************************************************************************** class FindFrameVariant {}; /* Пока только один тип фреймов... */ //**************************************************************************** template < template <class> class DeletePolicy > class FrameManager : public DeletePolicy<TFrame*> {     public :         virtual TFrame* Make( Classes::TComponent* Owner, TWinControl *Parent );         virtual void Remove ( void ) = 0;         // Make-функция. Её определения не видит линкер. А оно есть, см. дальше.         static FrameManager<DeletePolicy>* MakeFrameManager( FindFrameVariant ); };

Код

/* Файл FrameManager.cpp */ template < template <class> class DeletePolicy > class FindFrameManager : public DeletePolicy<TFindFrame*> {     private :         static TFindFrame *frame;     public :         virtual TFrame* Make( Classes::TComponent* Owner, TWinControl *Parent )         {             TFindFrame* CurFrame = (frame) ? frame : new TFindFrame(Owner);             frame = CurFrame;             CurFrame->Parent = Parent;             CurFrame->Show();             CurFrame->ImgClose->OnClick = WantToClose;         };         virtual void Remove( void )             { CurFrame->Hide(); CurFrame->Parent = NULL; Delete(frame); }         // ... Пропущено несколько деталей без потери смысла }; template <template <class> class DeletePolicy > TFindFrame* FindFrameManager<DeletePolicy>::frame = NULL; //**************************************************************************** /* На остуствие этой функции ругается линкер */ template <template <class> class DeletePolicy> FrameManager<DeletePolicy>* FrameManager<DeletePolicy>::MakeFrameManager( FindFrameVariant ) {     return new SearchFrameManager<DeletePolicy>(); };

Код

/* Файл FrameFactory.h */ template < template <class> class DeletePolicy > class FrameFactory {     public :         // Тут всякие функции... Они сейчас нам не интересны, кроме одной:         // Добавляем пару : Имя - представитель фрейма.         void AddFrameManager( AnsiString Name, FrameManager<DeletePolicy>* FM );         // Её реализация в файле FrameFactory.cpp };

Код

/* Файл MainFormUnit */ __fastcall TMainForm::TMainForm(TComponent* Owner)     : TForm(Owner), FFactory(this, SidePanel) {     // ...     FFactory.AddFrameManager( "SearchFrame",         FrameManager<DeleteAndNil>::MakeFrameManager(FindFrameVariant()) );     // ... }

В чем же тут дело, коллеги ?

Вот блин, как всегда, руки до книг доходят в последнюю очередь, уже после того, как всю штукатурку со стен головой облупишь. Оказывается, параметризованные функции могут быть использованы только в том же модуле трансляции, где они объявлены. А у меня специфика кода как раз подразумевала использование их в другом месте. Кто нибудь знает, как можно решить такую проблемку - у меня имеется несколько классов, наследуемых от TFrame. И мне нужно, чтобы их можно было создавать по имени. Я сделал что-то вроде гомоморфного интерфейса классов, которые рулят этими Frame-ами, и определил make-функцию (производящую функцию в другой терминологии). Что я не учел, так это то, что определение make-функций нельзя поместить в другом .cpp файле. Есть какие нибудь идеи, как оставить всю гибкость классов, которые создают мои фреймы, и их гомоморфный интерфейс, и при этом оставить их параметризованными?

Говоря простым русским языком, можно ли придумать альтернативу статическим функциям шаблонных классов?

Это сообщение отредактировал(а) Chaos A.D. - 6.6.2005, 15:49

Вынеси реализацию шаблонных фукнций в заголовочный файл.

Дело в том, что в заголовочном файле определен только общий интерфейс в виде виртуального класса. Все настоящие дела творятся в файле .cpp.

Это ограничение шаблонов - их реализация должны быть в той же единице трансляции, что и их использование. Обычно с этом мирятся и выносят реализацию шаблонов в заголовочные файлы - посмотри, например, исходники библиотек шаблонов типа STL, ATL или WTL. Экспортируемые шаблоны, которые позволили бы избежать такое ограничение, Борладном не поддерживаются.

Юмор, да и только... Только что наткнулся в настройках борланда на опцию - "External Templates" . Жаль, что не уживаетяс с STL.

>Экспортируемые шаблоны, которые позволили бы избежать такое ограничение, Борладном не поддерживаются
А они хоть кем-нибудь поддерживаются? GCC с ними тоже не дружит.

Цитата

А они хоть кем-нибудь поддерживаются?

Comeau поддерживает. Борланд, Вижуал, GCC - нет. OpenWatcom назвать компилятором Си++ трудно, там какой-то древнегреческий диалект. Про остальные компиляторы - не знаю.

Любопытно как это они делают
Наверняка без потери скорости не обходится, а на кой такое надо.

> а на кой такое надо.
ну ясно на кой - чтобы конкуренты не увидели сурсов темплейтных определений.

Цитата(ManiaK @ 7.6.2005, 16:54)

Любопытно как это они делают smile

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

Цитата(ManiaK @ 7.6.2005, 16:54)

Наверняка без потери скорости не обходится, а на кой такое надо.

Дело не в потере скорости (которой, имхо, нет). Дело в том, что существующая реализация export templates - это полумера, потому что раздельной компиляции шаблонов как не было, так и нет. Просто мы избавляемся от необходимости определять шаблонный метод/класс в каждой единице трансляции.

Цитата(versus @ 7.6.2005, 19:56)

ну ясно на кой - чтобы конкуренты не увидели сурсов темплейтных определений.

Цитата

The sources containing the exported template definitions must therefore be made available at the time of instantiation (usually, when prelinking is done). [...] Note that the export facility is not a mechanism for avoiding the publication of template definitions in source form.

http://www.comeaucomputing.com/4.0/docs/userman/export.html
Да даже если б можно было - толку, если всего один компилятор поддерживает эту возможность.

Void проще говоря, это все лишь бутафория, а не экспорт?

Цитата(ManiaK @ 9.6.2005, 13:53)

Void проще говоря, это все лишь бутафория, а не экспорт?

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

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

Это сообщение отредактировал(а) Chaos A.D. - 11.6.2005, 23:06

Цитата(Chaos @ 11.6.2005, 20:04)

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

Да, в стандарт включена. Но возможно не надолго. Ибо реализация поддержки экспортируемых шаблонов в компиляторе ОЧЕНЬ трудоемка, а сама возможность экспортировать шаблоны не дает того, что от нее ожидается.