[c++] undefined reference
потому что шаблоны надо описывать в h-файле полностью. «Есть» export, но это лишь самообман.
Определения шаблонных функций нужно держать в заголовочных файлах.
> «Есть» export, но это лишь самообман.
А оно, кстати, есть где-нибудь работающее, или компиляторописатели забили?
А оно, кстати, есть где-нибудь работающее, или компиляторописатели забили?
Где-то есть, в каком-то экзотическом компиляторе.
Саттер обсиранию export две главы посвятил, поэтому можно сказать, что они не пассивно «забили член», а активно так заколотили гвоздей в эту возможность. Вроде как оно в стандарте для кошерности =)
Саттер обсиранию export две главы посвятил, поэтому можно сказать, что они не пассивно «забили член», а активно так заколотили гвоздей в эту возможность. Вроде как оно в стандарте для кошерности =)
То есть для шаблонного класса я должен в хидере описывать весь класс?
Да.
То есть для шаблонного класса я должен в хидере описывать весь класс?Это вполне логично. Из чего-то компилятор ведь должен компилировать конкретизацию шаблонного класса. Может прикажешь компилятору угадать, с какими типами будет использоваться твой шаблон, или заставишь компилировать линкер?
Из чего-то компилятор ведь должен компилировать конкретизацию шаблонного класса.Вот для этого в паскале и придумали модули. Шаблоны там храняться в скомпилированном виде. По крайней мере в free pascal - как работает Delphi 2009 я не знаю.
Вот для этого в паскале и придумали модули. Шаблоны там храняться в скомпилированном виде. По крайней мере в free pascal - как работает Delphi 2009 я не знаю.в паскале нет шаблонов (тех, которые есть в C++ в паскале есть лишь generics
а с выносом generics в библиотеку особых проблем нет, в отличие от выноса шаблонов.
ps
но это все не отменяет того факта, что в C/C++ очень убогая реализация повторного использования кода (даже по сравнению с паскалем)
а с выносом generics в библиотеку особых проблем нет, в отличие от выноса шаблонов.ну хз-хз. Там точно в этом модуле не байткод? Очень сомневаюсь.
ну хз-хз. Там точно в этом модуле не байткод? Очень сомневаюсь.во-первых, может быть и байткод. не вижу в этом никаких минусов, только плюсы
во-вторых, если generics используется только для reference-типов, то можно обойтись и без байткода
во-первых, может быть и байткод. не вижу в этом никаких минусов, только плюсыну фишка как бы в том, что байткод — аналог исходника, так что принципиально проблема неразрешима, на что указали выше в этом треде и Herb Sutter в своей книге «40 новых сложных задач по C++».
во-вторых, если generics используется только для reference-типов, то можно обойтись и без байткодада, мы это обсуждали.
что байткод — аналог исходникадля C++ - это совсем не так, особенно если вспомнить, что в C++ - есть еще текстовый препроцессор.
байткод - уже имеет ярко выраженную сформированную структуру, исходник никакой структуры не имеет.
в байткоде уже прорезолвенны все ссылки, которые могут, в текстовом исходнике такого нет.
это все условности. Восстановить и узнать внутренние детали реализация шаблона все равно не представляет труда.
это все условности. Восстановить и узнать внутренние детали реализация шаблона все равно не представляет труда.мы сейчас о чем вообще говорим? о теплом или о мягком?
если о теплом - сложность восстановления исходного замысла - то для решения этой задачи используется обфускация, а не компиляция (преобразование исходного текста в структурированные данные)
если же о мягком - насколько удобно повторно использовать сделанные более ранее разработки, то преобразование в байт-код как раз эту задачу успешно решает.
Ну похоже ты действительно не понял, о чем разговор. А разговор о том, что обычные функции и классы можно предоставлять из dll, скажем, скрывая реализацию (предоставив сигнатуру функции и описание класса а с шаблонными функциями и классами так не выйдет.
А разговор о том, что обычные функции и классы можно предоставлять из dll, скажем, скрывая реализацию (предоставив сигнатуру функции и описание класса а с шаблонными функциями и классами так не выйдет.почему не выйдет? давай в dll байткод запихаем? Разве это не скроет реализацию?
ps
я еще раз спрошу:
ты хочешь скрыть реализацию для удобства? да, для этого используется компиляция
или ты хочешь скрыть реализацию, чтобы никто не смог разобраться? нет, для этого компиляация не используется, для этого используется обфускация.
pps
кстати вторая задача (скрытие кода, чтобы никто не смог разобраться) и сейчас для C++-успешно решается.
часть C++- коммерческих либ (особенно кроссплатформенных) поставляется в виде h/c/cpp-листингов, но после обфускации
почему не выйдет? давай в dll байткод запихаем? Разве это не скроет реализацию?по твоим же рассуждениям не скроет: его можно декомпильнуть в куда более приближенный к исходному коду вариант.
Да, тут разговор именно о сокрытии для удобства, чтобы не полагаться на детали реализации и этим упростить дальнейшую поддержку: я же провел очень однозначную аналогию с обычными функциями и классами.
Оставить комментарий
doublemother
Есть два файла, реализующие соответствующие классы:Stem.h:
Hashtable.h:
Также есть файл parser.cpp, который инклюдит оба .h файла и в main вызывает
Компилируется соответственно в три разных объектника и при линковке получаю ошибку:
Если делаю в parser.cpp инклюд Hashtable.cpp и линкую соответственно только из двух объектных файлов, то всё собирается. Не могу понять, почему не может найти референс так?
Upd. Если конструктор хэш-таблицы определить в хидере - тоже всё линкуется. Но в чём же таки причина?