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

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

Если вы не включаете исходный файл (и, следовательно, реализацию) для класса 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

У меня была ошибка, когда мой проект был составлен как x64. и я использовал библиотека это было скомпилировано как 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 существует атрибут под названием "Treat 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 файл в проекте, но что-то еще полностью строится.

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

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

#include "ClassB" 

class ClassB; // this solved the problem

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

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

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

:/

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

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

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

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

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

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

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

у меня был огромный файл Foo.cpp без ФОО.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 файл ... вместо заголовка. Да, такое случается.

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