static метод из другого проекта
Проект в VS2003 включает в себя ещё несколько проектов (все на С++). В одном из них реализован шаблон "одиночка". В классе есть статический метод
static CSingletone* GetInstance();
Пытаюсь добраться до класса из другого проекта. h-ник проинклюдил. В релизе всё собирается нормально. При попытке собрать в дебаге выдается:
Compiler error LNK2019: unresolved external symbol "public: static class CSingletone * __cdecl СSingletone::GetInstance(void)" (?GetInstance@CSingletone@@SAAAV1@XZ) referenced in function _main
Подскажите пожалуйста, в чом косяк.
static CSingletone* GetInstance();
Пытаюсь добраться до класса из другого проекта. h-ник проинклюдил. В релизе всё собирается нормально. При попытке собрать в дебаге выдается:
Compiler error LNK2019: unresolved external symbol "public: static class CSingletone * __cdecl СSingletone::GetInstance(void)" (?GetInstance@CSingletone@@SAAAV1@XZ) referenced in function _main
Подскажите пожалуйста, в чом косяк.
Ну первое что в голову приходит - реализация в .cpp файле который не добавлен в проект. не знаю почему в релизе собирается - но причин пожет быть много - тупо исключенно ifdef-ами хотябы.
Ну или как вариант - релизной конфигурации в настройках проекта прописанны пути до *.h файлов с реализацией, а в дебажной нет.
Вобщем без проекта не разберешся. )
Ну или как вариант - релизной конфигурации в настройках проекта прописанны пути до *.h файлов с реализацией, а в дебажной нет.
Вобщем без проекта не разберешся. )
Нашёл: в свойствах проекта: С/C++ -> Advanced -> Calling Convention было включено "__cdecl (/Gd)". Если включить "__stdcall (/Gz)" то всё собирается.
Параметр был найден путём сравнения настроек дебага и релиза.
Объясните пожалуйста, что это за фигня и в чом отличия?
Параметр был найден путём сравнения настроек дебага и релиза.
Объясните пожалуйста, что это за фигня и в чом отличия?
А... есть такая фишка.
Если способ вызова функции не прописывать явно [TResult __fastcall Function (TParams Params)], то при дальнейшем использовании данной функции в другом проекте обязательно будет указан иной способ вызова "по-умолчанию"
Линковщик пытался искать в ранее скомпилированной библиотеке (пакете) функцию с порядком параметров __cdecl, но там была только функция со "стандартным" порядком (__stdcall). Естественно, процесс сборки программы обламывался ошибкой "отсутсвует код функции"
Отсюда вывод - всегда указывать способ вызова функций.
Если способ вызова функции не прописывать явно [TResult __fastcall Function (TParams Params)], то при дальнейшем использовании данной функции в другом проекте обязательно будет указан иной способ вызова "по-умолчанию"
Линковщик пытался искать в ранее скомпилированной библиотеке (пакете) функцию с порядком параметров __cdecl, но там была только функция со "стандартным" порядком (__stdcall). Естественно, процесс сборки программы обламывался ошибкой "отсутсвует код функции"
Отсюда вывод - всегда указывать способ вызова функций.
Цитата: el scorpio
Отсюда вывод - всегда указывать способ вызова функций.
И жертвовать переносимостью и универсальностью кода? )
Цитата: aks
И жертвовать переносимостью и универсальностью кода? )
#define MYAPI __stdcall
int MYAPI SomeProc();
Нормальный ход действий при разработке библиотек. Где жертвы?
Цитата: HarryAxe
Где жертвы?
Здесь нет если есть возможность при пересборках легко менять этот макрос и если обязательно нужна эти модификаторы.
Если же писать перед каждой функций эти способы вызова - жертвы самые реальные )
Ясно. Спасибо за ответ.