Неразрешенный внешний символ в объектных файлах

во время кодирования в Visual Studio я получил неразрешенную ошибку внешнего символа и я понятия не имею, что делать. Я не знаю, что случилось. Не могли бы вы расшифровать мне? Где я должен искать, какие ошибки?

1>Form.obj : error LNK2019: unresolved external symbol "public: class Field * __thiscall Field::addField(class Field *)" (?addField@Field@@QAEPAV1@PAV1@@Z) referenced in function "public: void __thiscall Form::parse(class std::basic_stringstream<char,struct std::char_traits<char>,class std::allocator<char> > &)" (?parse@Form@@QAEXAAV?$basic_stringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
1>Form.obj : error LNK2019: unresolved external symbol "public: virtual void __thiscall Field::parse(class std::basic_stringstream<char,struct std::char_traits<char>,class std::allocator<char> > &)" (?parse@Field@@UAEXAAV?$basic_stringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z) referenced in function "public: __thiscall InputField::InputField(class std::basic_stringstream<char,struct std::char_traits<char>,class std::allocator<char> > &)" (??0InputField@@QAE@AAV?$basic_stringstream@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@@Z)
1>Form.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Field::prompt(void)" (?prompt@Field@@UAEXXZ)
1>Form.obj : error LNK2001: unresolved external symbol "public: virtual class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall Field::getName(void)" (?getName@Field@@UAE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)
1>Form.obj : error LNK2001: unresolved external symbol "public: virtual class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall Field::getType(void)" (?getType@Field@@UAE?AV?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@XZ)
1>Form.obj : error LNK2001: unresolved external symbol "public: virtual void __thiscall Field::describe(void)" (?describe@Field@@UAEXXZ)
1>C:UserstomyDocumentsVisual Studio 2010Projectszapoctovkac++Debugzapoctovkac++.exe : fatal error LNK1120: 6 unresolved externals

23 ответов


эта ошибка часто означает, что некоторая функция имеет объявление, но не определение.

пример:

// A.hpp
class A
{
public:
  void myFunc(); // Function declaration
};

// A.cpp

// Function definition
void A::myFunc()
{
  // do stuff
}

в вашем случае, определение не может быть найден. проблема может быть в том, что вы включаете файл заголовка, который приносит некоторые объявления функций, но вы либо:

  1. не определяйте функции в файле cpp (если вы сами написали этот код)
  2. не включать файл lib / dll, который содержит определения

распространенной ошибкой является то, что вы определяете функцию как автономную и забываете селектор классов, например A:: в своем .cpp:

неправильно: void myFunc() { /* do stuff */ }
правильно: void A::myFunc() { /* do stuff */ }


проверьте, что вы включаете все исходные файлы в своем решении, на которые ссылаетесь.

Если вы не включаете исходный файл (и, следовательно, реализацию) для класса Field в вашем проекте он не будет построен, и вы не сможете связать во время компиляции.

кроме того, возможно, вы используете статическую или динамическую библиотеку и забыли сообщить компоновщику о .libs?


похоже, что отсутствует библиотека или include, вы можете попытаться выяснить, какой класс вашей библиотеки имеет getName ,getType и т. д... и поместите это в файл заголовка или с помощью #include.

также, если они происходят из внешней библиотеки, убедитесь, что вы ссылаетесь на них в файле проекта. Например, если этот класс принадлежит abc.lib тогда в вашей Visual Studio

  1. нажмите на "свойства проекта".
  2. перейти к конфигурации Свойства, C / C++, Создайте, убедитесь, что вы указываете на abc.расположение lib под дополнительным Включить Каталоги. В разделе Компоновщик, ввод, убедитесь, что у вас есть азбука.lib в дополнительных зависимостях.

Я только что видел проблему, которую я не могу вызвать функцию из main in .cpp файл, правильно объявленный В.H файл и определен в .файл c. Обнаружена ошибка компоновщика. Между тем я могу вызвать функцию из обычного.файл c. Возможно, это зависит от соглашения о вызове. Решение состояло в том, чтобы добавить следующие строки preproc в каждом .H-файл:

#ifdef __cplusplus
extern "C"
{
#endif

и в конце

#ifdef __cplusplus
}
#endif

У меня была ошибка, когда мой проект был составлен как х64. и я использовал библиотека это было скомпилировано как x86.

Я перекомпилировал библиотеку как x64, и она решила ее.


У меня были те же ошибки ссылки, но из тестового проекта, который ссылался на другую dll. Узнал, что после добавления _declspec(dllexport) перед каждой функцией, которая была указана в сообщении об ошибке, ссылка работала хорошо.


в дополнение к отличному ответу Криса Морриса выше, я нашел очень интересный способ получить эту же ошибку, если вы вызываете виртуальный метод, который не был установлен в pure, но не имеет собственной реализации. Это та же самая причина (компилятор не может найти реализацию метода и, следовательно, мошенников), но моя IDE не поймала эту ошибку ни в малейшей степени.

например, следующий код получит ошибку компиляции с той же ошибкой сообщение:

//code testing an interface
class test
{
   void myFunc(); 
}

//define an interface
class IamInterface
{
    virtual void myFunc();
}

//implementation of the interface
class IamConcreteImpl
{
    void myFunc()
    {
       1+1=2;
    }
}

однако изменение iaminterface myFunc () на чистый виртуальный метод (метод, который "должен" быть реализован, чем виртуальный метод, который является методом, который "может" быть переопределен) устранит ошибку компиляции.

//define an interface
class IamInterface
{
    virtual void myFunc() = 0;
}

надеется, что это поможет следующему человеку StackOverFlow пройти через код!


убедитесь, что вы украшаете файлы заголовков с

#ifndef YOUR_HEADER_H
#define YOUR_HEADER_H

// your header code here

#endif

плохие вещи-включая это-могут произойти, если вы не


Я считаю, что большинство вопросов, касающихся причин и средств правовой защиты, были охвачены всеми участниками этой темы. Я просто хочу указать на мою "неразрешенную внешнюю" проблему, она была вызвана типом данных, определенным как макрос, который подставляется иначе, чем ожидалось, что приводит к тому, что этот неправильный тип предоставляется рассматриваемой функции, и поскольку функция с типом никогда не определена, она не могла быть решена. В частности, в разделе C / C++ -> Language есть атрибут под названием "обрабатывать wchar_t как встроенный тип, который должен был быть определен как" No (/Zc:wchar_t -)", но не в моем случае.


иногда, если добавлен новый файл заголовка, и эта ошибка начинает приходить из-за этого, вам нужно добавить библиотеку, а также избавиться от unresolved external symbol.

например:

#include WtsApi32.h

понадобится:

#pragma comment(lib, "Wtsapi32.lib") 

Мне просто было трудно с этим. Все было логично устроено. Я объявил конструктор, но не определил его

class SomeClass
{
   SomeClass();  // needs the SomeClass::SomeClass(){} function defined somewhere, even here
}

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


Я делаю некоторые C++ впервые за долгое время, и я получаю эту ошибку, когда я забываю добавить префикс ClassName:: для определения функции, так как это немного уникально для C++. Так что не забудьте проверить это!


посмотреть ошибка инструментов компоновщика LNK2019 в MSDN у него есть подробный список общих проблем, которые вызывают LNK2019.


одной из возможных причин этой ошибки компоновщика также может быть inline функции, которые объявлены, но не определены в заголовочном файле, который включается где-то еще. Встроенные функции должны быть определены в каждой единице перевода, в котором они используются.


указатели

У меня была эта проблема и я решил ее с помощью указателя. Я вижу, что это не ваша проблема, но я решил упомянуть его, потому что если бы он был здесь, когда я видел это час назад. Моя проблема заключалась в объявлении статической переменной-члена без ее определения (определение, необходимое после некоторых других настроек), и, конечно, указатель не нуждается в определении. Столь же элементарная ошибка: P


моей проблемой был sconscript, у которого не было cpp файл, определенный в нем. Это может быть очень запутанным, потому что Visual Studio имеет cpp файл в проекте, но что-то еще полностью строится.


моя проблема была: я должен был сделать вперед декларации класса, чей ctor был "неразрешенным внешним".

в файле, где я получил ошибку, я должен был положить что-то вроде этого:

#include "ClassB" 

class ClassB; // this solved the problem

class ClassA{
    void foo(){
        ClassB* tmp = new ClassB();
        // ...
    }
};

конечно, мой проект намного сложнее,и это всего лишь пример фрагмента. Также при использовании пространств имен, объявите их также.


просто потратил пару часов, чтобы найти, что проблема была в моем основном файле с расширением .c вместо .cpp

:/


проверьте, что ваша целевая платформа VS project соответствует загруженным двоичным файлам.

например: Платформа:для Win32 ---- VS2013 32 бита 6.3(статический)


еще одна возможность проверить, это была моя проблема на этот раз.

Я добавил функцию в библиотеку и включил выходную папку библиотеки в путь поиска.

но у меня также была папка со старой версией библиотеки, указанной ранее, поэтому VS использовал старую библиотеку и, конечно, не нашел новую функцию.


убедитесь, что вы не пытаетесь перегрузить операторы вставки или извлечения как встроенные функции. У меня была эта проблема, и она исчезла только тогда, когда я удалил это ключевое слово.


что вызвало это в моем случае:

у меня был огромный файл Foo.cpp без Foo.h. Foo.cpp начиналось так:

// ... 100 LOC here ...
namespace NS {
// ... 100 more LOC here ...
static int var;

Я удалил ключевое слово "static" и добавил Foo.h С этого:

extern int var;

вы видите ошибку?

Я полностью пропустил, что VAR был первоначально определен в пространстве имен, потому что объявление пространства имен было похоронено в другом коде. Исправление заключается в изменении внешнего вида:

namespace NS {
     extern int var;
}

еще одна возможная проблема (о которой я просто почесал голову в течение некоторого времени):

Если вы определяете свои функции как inline, Они-конечно!-должны быть определены в заголовок (или inline file), а не cpp.
В моем случае они были во встроенном файле, но только потому, что они были реализацией платформы и cpp включил эту тегом inl file ... вместо заголовка. Да, Е**Т происходит.

Я думал, что оставлю это здесь, возможно, кто-то еще столкнется с той же проблемой и найдет ее здесь.