Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > Шаблон: ошибка линкера

Автор: nerezus 25.6.2008, 14:44

Код Error    1    error LNK2019: unresolved external symbol "class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __cdecl toString<int>(int)" (??$toString@H@@YA?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@H@Z) referenced in function "public: __thiscall Actor::Actor(float,float,unsigned long)" (??0Actor@@QAE@MMK@Z)    Actor.obj    HgeArkanoid У меня используется в коде: Код toString(width) Оно описано в common.h Код template <typename T> string toString(T val); и реализовано в common.cpp Код template <typename T> string toString(T val) {     ostringstream o;     static string s;     if (!(o << val))         throw "Cannot convert to string";     s = o.str();     return s; } В чем ошибка?

Автор: Fazil6 25.6.2008, 14:48

Цитата(nerezus @  25.6.2008,  14:44 ) В чем ошибка?  в том, что описано и реализовано в разных файлах.

Автор: nerezus 25.6.2008, 14:51

Fazil6, а как надо? Откуда такое требование и как его обойти? Естественно я его из разных файлов вызываю, поэтому заголовок и выделил в отдельный, чтобы ошибки не было, что одинаковые ф-ии объявлены.

Автор: georain 25.6.2008, 14:52

Вот на следующей странице этого раздела (используем поиск): http://forum.vingrad.ru/forum/topic-214819.html

Автор: nerezus 25.6.2008, 14:58

круто) fixed, but... Если не ошибаюсь, это одна из ошибок именно компилятора, а не прописанная в стандарте фича?

Автор: Fazil6 25.6.2008, 15:01

Цитата(nerezus @  25.6.2008,  14:58 ) Если не ошибаюсь, это одна из ошибок именно компилятора, а не прописанная в стандарте фича?  ошибаешься

Автор: bsa 25.6.2008, 15:06

Цитата(nerezus @ 25.6.2008,  14:58) Если не ошибаюсь, это одна из ошибок именно компилятора, а не прописанная в стандарте фича? Именно что прописанная. Чтобы можно было разделять объявление и реализацию шаблонов был придуман механизм extern template. Но большинство компиляторов его не поддерживают. Хотя, в любом случае, твой код без изменений компилироваться бы не стал.

Автор: nerezus 25.6.2008, 16:22

bsa, а как его заюзать? ) VS, моследняя версия. Так сказать мейнстрим под винду.

Автор: bsa 25.6.2008, 17:54

Цитата(nerezus @ 25.6.2008,  16:22) bsa, а как его заюзать? ) VS, моследняя версия. Так сказать мейнстрим под винду. То что мейнстрим, еще ничего не значит. Она даже стандарт C99 не поддерживает. Кто-то сказал, что данную возможность поддерживает компилятор от Sun.

Автор: JackYF 25.6.2008, 21:48

Данную возможность поддерживает Comeau

Автор: bsa 25.6.2008, 22:05

Цитата(JackYF @ 25.6.2008,  21:48) Данную возможность поддерживает Comeau  Очень хорошо. И цена хорошая. Вот только есть одна проблема - платить никто ее не захочет. А бесплатно попробовать нельзя (online неполноценнен, так как тот же буст даже не собрать).

Автор: comcon1 26.6.2008, 06:59

Да нафиг это нужно? Если бы у тебя был какой-нить мегапроект на миллион строк... Уж как-то люди обходятся и даже по этому поводу не парятся и нормальные кроскомпилерные библотеки пишут. Конечную реализацию можно отделять в отдельный файл, но не всегда можно так код выстроить. В том примере, что ты привёл, вообще смешно про это говорить. А чтобы ошибки не было, достаточно весь хедер занести в #ifndef #endif -блок.

Автор: JackYF 26.6.2008, 15:56

bsa, не спорю  Цитата(comcon1 @  26.6.2008,  05:59 ) Да нафиг это нужно? Не скажи... Я вот очень был бы рад.

Автор: bsa 26.6.2008, 16:21

Цитата(comcon1 @ 26.6.2008,  06:59) Да нафиг это нужно? Если бы у тебя был какой-нить мегапроект на миллион строк... Уж как-то люди обходятся и даже по этому поводу не парятся и нормальные кроскомпилерные библотеки пишут. Это, думаю, сильно ускорит компиляцию. Когда у тебя, допустим, STL и тот же boost активно используются в программе, то скорость компиляции одного файла довольно низкая. Ситуацию спасает прекомпиляция заголовочных файлов, но ее еще надо настраивать в проекте, причем automake, например, на данный момент этого сделать легко не позволяет.

Автор: UnrealMan 26.6.2008, 16:33

Цитата(comcon1 @  26.6.2008,  06:59 ) Да нафиг это нужно? Поддерживаю. От export-а больше проблем, чем пользы. Добавлено @ 16:38 Цитата(bsa @  26.6.2008,  16:21 ) Это, думаю, сильно ускорит компиляцию. А возможно, что и, наоборот, затормозит её. Ведь исходные файлы с экспортируемыми шаблонами становятся зависимы друг от друга (а не только от заголовочных файлов).

Автор: JackYF 26.6.2008, 19:09

Цитата(UnrealMan @  26.6.2008,  15:33 ) От export-а больше проблем, чем пользы Имеешь опыт использования?

Автор: UnrealMan 26.6.2008, 20:40

Цитата(JackYF @  26.6.2008,  19:09 ) Имеешь опыт использования?  К счастью, нет.

Автор: bsa 26.6.2008, 21:12

Цитата(UnrealMan @ 26.6.2008,  20:40) К счастью, нет. Это ты зря, подобный опыт в любом случае бывает полезным.

Автор: UnrealMan 26.6.2008, 23:04

Цитата(bsa @  26.6.2008,  21:12 ) Это ты зря, подобный опыт в любом случае бывает полезным. Ну, это как посмотреть. Неудачные проектные решения однажды стоили мне работы из-за провала сроков, и полезного в этом я вижу мало. Из этого опыта я для себя сделал вывод: лучше не пытаться воспользоваться сомнительными методами - это может выйти боком. Экспорт шаблонов - весьма сомнительная штука (проблемы экспорта шаблонов затрагиваются в Новых сложных задачах Саттера), и я бы воздержался от его использования.

Автор: xvr 27.6.2008, 10:51

Цитата(UnrealMan @ 26.6.2008,  16:33) Цитата(comcon1 @  26.6.2008,  06:59 ) Да нафиг это нужно? Поддерживаю. От export-а больше проблем, чем пользы. Добавлено @ 16:38 Цитата(bsa @  26.6.2008,  16:21 ) Это, думаю, сильно ускорит компиляцию. А возможно, что и, наоборот, затормозит её. Ведь исходные файлы с экспортируемыми шаблонами становятся зависимы друг от друга (а не только от заголовочных файлов). Это точно   В уже упоминавшемся компиляторе от Sun'а был сделан проект (относительно небольшой, тысяч так на 10-20 строк) с использованием темплейтов. Это был интерпретатор, в котором было несколько десятков операций, каждая из которых была реализованна для штук 5 встроенных типов. Операции были реализованны в виде шаблонных классов, которые потом инстантировались для каждого типа. Вся эта байда компилировалась меньше минуты а линковалась минут 10   (Шаблоны инстантировались на этапе линковки). Потом SUN сменил систему инстантации темплейтов, они стали генерироваться прямо в процессе компилирования исходника, общее время компиляции увеличилось до 4-5 часов   (Все операции были собранны в паре файлов, так как тела классов были очень небольшие, и этот бедный файл компилировался целиком для каждой операции каждого типа) Пришлось прибегнуть к явной инстантации темплейтов, что бы отключить его 'умную' обработку темплейтов

Автор: bsa 27.6.2008, 15:07

Цитата(xvr @ 27.6.2008,  10:51) Вся эта байда компилировалась меньше минуты а линковалась минут 10   (Шаблоны инстантировались на этапе линковки). Потом SUN сменил систему инстантации темплейтов, они стали генерироваться прямо в процессе компилирования исходника, общее время компиляции увеличилось до 4-5 часов    О. Вот это уже хорошая и полезная информация.

Автор: Любитель 27.6.2008, 15:28

Раз уж так пошло - а почему интеловый компилер забыли. Тем более, что есть бесплатная редакция под линь. Он поддерживает экспорт. Серёзно не использовал (ибо терять совместимость и с гцц, и с msvc - не особо хочется) - особой статистики не дам. Хотя можно попробовать

Автор: nerezus 27.6.2008, 20:32

Хех, я когда возможно делаю это во время исполнения(ООП ибо.  Наследование от общего класса, (un)boxing), но просто приходится использовать стандартные классы/типы, у которых нет общего предка. Мне это жутко не нравится, но приходится самому делать шаблоны.

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)