Эта функция в пространстве имен myns1, класс Class1 точно есть. Сигнатура совпадает.
И еще же сотни функций, которые видны и с ними проблем нет. Однако это и еще с два десятка которые почему-то не видны линкеру, хотя вроде с ними все в порядке.
И вызывается из С++ не из C, думал в этом проблема. В проекте разные расширения файлов — и cc и cpp — вроде не должно быть проблемой?
В общем — из-за чего такое может быть? Может ли быть, если нарушен порядок сборки? Если может быть из-за нарушения порядка сборки — то хотелось бы мин. пример.
Еще думаю — может ли быть, если в проекте вперемешку с и с++ -файлы?
S>Эта функция в пространстве имен myns1, класс Class1 точно есть. Сигнатура совпадает.
Вы уверены, может она где-то в ns2::ns3::myns1 попала, после неудачных инклюдов?
Re: Почему может быть unresolved external, если функция есть?
Здравствуйте, Shmj, Вы писали:
S>error LNK2001: unresolved external symbol "public: double __cdecl myns1::Class1::Function1(void)const " (?Function1@Class1@myns1@@QEBANXZ)
S>Эта функция в пространстве имен myns1, класс Class1 точно есть. Сигнатура совпадает.
S>И еще же сотни функций, которые видны и с ними проблем нет. Однако это и еще с два десятка которые почему-то не видны линкеру, хотя вроде с ними все в порядке.
"Вроде"?
Найди чем под виндой делается показ экспортированных имён в объектнике или библиотеке и посмотри, что именно экспортируется.
The God is real, unless declared integer.
Re: Почему может быть unresolved external, если функция есть?
1. Внимательно посмотри на вызов линкера, убедись, что там объектный файл с этой функцией включается в линковку.
2. Через nm (если не путаю) посмотри, что в этом объектном файле эта функция действительно есть с нужными атрибутами.
3. Убедившись, что её там нет, найти переключатель в своём компляторе, который вместо компиляции выплёвывает текст после препроцессора. В gcc это -E. "Перекомпилируй" проект с этим переключателем и у тебя в .o файлах будет код на C++ после препроцессора. Скорей всего тут всё станет уже окончательно понятно.
Я бы так действовал.
Re: Почему может быть unresolved external, если функция есть?
S>Эта функция в пространстве имен myns1, класс Class1 точно есть. Сигнатура совпадает. S>И еще же сотни функций, которые видны и с ними проблем нет. Однако это и еще с два десятка которые почему-то не видны линкеру, хотя вроде с ними все в порядке. S>И вызывается из С++ не из C, думал в этом проблема. В проекте разные расширения файлов — и cc и cpp — вроде не должно быть проблемой? S>В общем — из-за чего такое может быть? Может ли быть, если нарушен порядок сборки? Если может быть из-за нарушения порядка сборки — то хотелось бы мин. пример.
Заочно определить проблему трудно, конечно. Но я бы посоветовал в первую очередь проверить настройки проектов. Декорирование имен чувствтительно к настройками проекта и, если в библиотеке и в приложении настройки разные, то это может быть причиной того, что линковщик не находит имена. И, если ты работаешь в Visual Studio, то имеет смысл собирать все настройки в специальных файлах, имеющих расширение "vsprops'. Один такой файл может подключаться сразу к нескольким проектам, тем самым синхронизируя все настройки. Кроме того эти файлы могут сслаться друг на друга, образуя иерархии, что позволяет разбивать настройки на группы и применять их на разных уровнях.
S>Еще думаю — может ли быть, если в проекте вперемешку с и с++ -файлы?
Запросто. По умолчанию c и c++ файлы обрабатываются разными компиляторами.
--
Re[2]: Почему может быть unresolved external, если функция есть?
В хедере определи эту функцию double Function1(void)const; -> double Function1(void)const { throw; }
Если оно не будет ругаться на реализацию, значит она не компилируется и смотри define-ы
Re: Почему может быть unresolved external, если функция есть?
Здравствуйте, Shmj, Вы писали:
S>— Пальцем покажи.
Код покажи!
S>error LNK2001: unresolved external symbol "public: double __cdecl myns1::Class1::Function1(void)const " (?Function1@Class1@myns1@@QEBANXZ)
Это значит, функция объявлена, но не определена.
Покажи объявление и покажи определение.
И покажи, что написано в файле проекта (если, конечно, это не лютая портянка конфига Visual Studio).
S>И вызывается из С++ не из C, думал в этом проблема. В проекте разные расширения файлов — и cc и cpp — вроде не должно быть проблемой?
Смотря какая система сборки.
Например, если это makefile, в котором есть суффиксные правила
.c.o
,
.cpp.o
, и один из используемых суффиксов (например, .cc) забыли прописать, — проблемы будут.
S>В общем — из-за чего такое может быть? Может ли быть, если нарушен порядок сборки? Если может быть из-за нарушения порядка сборки — то хотелось бы мин. пример.
От порядка это не зависит, а вот от разбиения проекта на библиотеки очень даже может зависеть.
Например, у тебя есть файлы с говорящими именами:
— class1.h — объявление класса Class1 (и всех его функций-членов, естественно)
— class1_function1.cpp — определение Class1::Function1
— class1_function234.cpp — определение других членов
— client.cpp — клиентский код, использующий класс
И ты раскидал по подпроектам
— lib234 = class1.h, class1_function234.cpp
— lib1 = class1_function1.cpp, зависит от lib234
— exe = client.cpp, зависит от lib234
и вот пожалуйста, exe не видит определения Class1::Function1.
S>Еще думаю — может ли быть, если в проекте вперемешку с и с++ -файлы?
Надо полагать, эта перемешка распихана по разным подпроектам?
В противном случае, непонятно, зачем писать на голых сях, если можно писать сразу на плюсях.
А если есть подпроекты, то есть и шанс облажаться — засунуть какой-нибудь файл не в тот подпроект (или вообще не засунуть), и см.выше.
Перекуём баги на фичи!
Re: Почему может быть unresolved external, если функция есть?
Перекуём баги на фичи!
