Ошибка lnk1120 неразрешенных внешних элементов 1

#include<iostream>
#include<string>
using namespace std;
struct Train
{
    string final_destination;
    int number_train;
    int t_hour;
    int t_minute;
};
template<typename T>
class Tmain
{
protected:
    T*mas;
    int n;
public:
    Tmain()
    {
        mas = NULL;
        n = 0;
    }
    Tmain(int n)
    {
        this->n = n;
        mas = NULL;
    }
    Tmain(const Tmain& obj)
    {
        if (this == &obj)return;
        n = obj.n;
        for (int i = 0; i < n; i++)
            mas[i] = obj.mas[i];
    }
    virtual ~Tmain()
    {
        if (mas) delete[]mas;
        mas = NULL;
        n = 0;
    }
    virtual void set() = 0;
    virtual void get() = 0;
};
istream&operator>>(istream& in, Train& train);
ostream&operator<<(ostream& out, const Train& train)
{
    out << "Final destination: " << train.final_destination << endl;
    out << "Number of train: " << train.number_train << endl;
    out << "Time: " << train.t_hour << ":" << train.t_minute << endl;
    return out;
}
class TTrain :public Tmain<Train>
{
public:
    TTrain() :Tmain<Train>(){};
    TTrain(int n) :Tmain<Train>(n){};
    TTrain(const TTrain& obj) :Tmain<Train>(obj){};
    void set() override
    {
        cout << "Input info for " << n << " trains" << endl;
        for (int i = 0; i < n; i++)
            cin >> mas[i];
    }
    void get() override
    {
        for (int i = 0; i < n; i++)
        {
            cout << "Train #" << i << endl;
            cout << mas[i];
        }
    }
    void addTrain(string final_destination, int number_train, int t_hour, int t_minute)
    {
        Train *arr = new Train[n + 1];
        for (int i = 0; i < n; i++)
            arr[i] = mas[i];
        arr[n].final_destination = final_destination;
        arr[n].number_train = number_train;
        arr[n].t_hour = t_hour;
        arr[n].t_minute = t_minute;
        delete[]mas;
        mas = arr;
        n++;
    }
    void getTrains(int t_hour, int t_minute)
    {
        for (int i = 0; i < n; i++)
        {
            if (mas[i].t_hour > t_hour || (mas[i].t_hour == t_hour && mas[i].t_minute>t_minute))
            {
                cout << "Train #" << i << endl;
                cout << mas[i];
            }
            else cout << "Not found!" << endl;
        }
    }
    void getTrains()
    {
        int t_hour, t_minute;
        cout << "Enter time: " << endl;
        cin >> t_hour;
        cin >> t_minute;
        for (int i = 0; i < n; i++)
        {
            if (mas[i].t_hour > t_hour || (mas[i].t_hour == t_hour && mas[i].t_minute>t_minute))
            {
                cout << "Train #" << i << endl;
                cout << mas[i];
            }
            else cout << "Not found!" << endl;
        }
    }
};
istream&operator>>(istream& in, TTrain& train)
{
    string final_destination, number_train, t_hour, t_minute;
    cout << "Enter final destination: " << endl;
    getline(in, final_destination);
    cout << "Enter number of train: " << endl;
    getline(in, number_train);
    cout << "Enter time: " << endl;
    getline(in, t_hour);
    getline(in, t_minute);
    train.addTrain(final_destination, atoi(number_train.c_str()), atoi(t_hour.c_str()), atoi(t_hour.c_str()));
    return in;
}
int main()
{
    int n;
    cout << "Enter quentity trains: " << endl;
    cin >> n;
    TTrain train(n);
    train.set();
    train.get();
    train.getTrains();
    train.getTrains(15, 45);
    system("pause");
    return 0;
}

Помогите с ошибками LNK2019 LNK1120

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

1>DXUTcamera.obj : error LNK2019: ссылка на неразрешенный внешний символ «long __stdcall DXUTCreateArrowMeshFromInternalArray(struct IDirect3DDevice9 *,struct ID3DXMesh * *)» (?DXUTCreateArrowMeshFromInternalArray@@YGJPAUIDirect3DDevice9@@PAPAUID3DXMesh@@@Z) в функции «public: static long __stdcall CDXUTDirectionWidget::StaticOnD3D9CreateDevice(struct IDirect3DDevice9 *)» (?StaticOnD3D9CreateDevice@CDXUTDirectionWidget@@SGJPAUIDirect3DDevice9@@@Z)
1>DebugEmptyProject10.exe : fatal error LNK1120: 1 неразрешенных внешних элементов

msdn прочитал, все что понял что вызываю функцию которая «не разрешена» что это значит? как ее разрешитЬ? я все проинклюдил, причем в том что проинклюдил эта функция есть.

ExcIuZive
> я все проинклюдил, причем в том что проинклюдил эта функция есть.
А cpp файлы или lib где есть описание этих функций подсоеденил?
> msdn прочитал, все что понял что вызываю функцию которая «не разрешена» что это значит?
Эта ошибка означает что функция объявлена, но линковщик не может отыскать ее описание

cpp и h файлы добавил в прокет (VS2010)
проинклудил h файл
а библиотеки.. ну только которые изначально d3d10.lib и d3dx10.lib. То есть все компилилось, начал прикручивать камеру через DXUT и вылезла вот эта ошибка.

Источник

LNK1120: 1 неразрешенный внешний вид и LNK2019: неразрешенный внешний символ

Я получаю эти две ошибки, и я не могу найти решение, которое работает.

LNK1120: 1 неразрешенное внешнее

Ошибка 1 ошибка LNK2019: неразрешенный внешний символ «public: __thiscall Vector3D :: Vector3D (класс Vector3D const &) «(?? 0Vector3D @@ QAE @ ABV0 @@ Z) ссылка на функцию» public: класс Vector3D __thiscall Vertex :: GetPosition (void) «(? GetPosition @ Vertex @@ QAE? AVVector3D @@ XZ)

Я думаю, что это связано с моим оператором Matrix и конструктором в моем классе Vector 3d
Любая помощь будет высоко ценится, так как я новичок в C ++

Решение

Это говорит о том, что компоновщик не может найти реализацию Vector3D(const Vector3D& rhs); , Этот конструктор объявлен в вашем векторном классе, но не определен.

У вас есть реализация конструктора где-то в .cpp файл, а этот файл известен вашему компилятору?

Компиляция C / C ++ работает так: сначала у вас есть несколько так называемых «модулей компиляции» — обычно каждый .cpp -file является одним из таких модулей компиляции. Ваша программа состоит из всех этих отдельных модулей, связанных друг с другом (процесс «связывания» происходит после компиляции). Каждая функция, которая вызывается где-то, должна быть определена ровно один раз в некотором модуле компиляции, если он не определен встроенным (как другие методы вашего класса). Если метод объявлен, но не определен, компилятор не будет жаловаться — только компоновщик. Представьте себе блоки компиляции, имеющие «розетки» и «соединители», которые соответствуют соответствующим «розеткам» других блоков. Процесс компиляции просто создает эти модули, принимая определенную форму «сокета» (как указано в объявлениях), тогда как компоновщик фактически пытается соединить каждый «сокет» с его «соединителем». Итак, вы видите, как процесс компиляции может быть успешным, но ссылки нет.

Ошибки компоновщика могут быть сложно решить, особенно если вы еще не так опытны. Там может быть много причин для них:

• Отсутствует реализация / определение
• Определение существует, но почему-то не компилируется (потому что файл не передается компилятору и т. Д.)
• Различные версии библиотек и т. Д.

И многое другое ..

Редактировать: Кроме того, вы должны передать вектор по константной ссылке и создать newVector, вызвав его конструктор, вместо создания объекта по умолчанию и последующего присвоения. И окончательное строительство в return statement тоже не нужен. Улучшенный код:

Другие решения

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

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

Вы реализовали Vector3D конструктор по умолчанию, конструктор копирования и деструктор? Вы показали свои заголовки, но не файлы реализации. Линкер жалуется на отсутствие определения Vector3D::Vector3D(Vector3D const&) ,

Источник

Ошибка средств компоновщика LNK2001

Скомпилированный код создает ссылку или вызов символа. Символ не определен ни в одной из библиотек или объектных файлов, поиск которого осуществляется компоновщиком.

Это сообщение об ошибке после неустранимой ошибки LNK1120. Чтобы устранить ошибку LNK1120, сначала исправьте все ошибки LNK2001 и LNK2019.

Существует множество способов получения ошибок LNK2001. Все они используют ссылку на функцию или переменную, которую компоновщик не может Разрешить, или найти определение для. Компилятор может определить, когда код не объявляет символ, но не в том случае, если он не определен . Это связано с тем, что определение может находиться в другом исходном файле или библиотеке. Если код ссылается на символ, но он никогда не определен, компоновщик создает ошибку.

Что такое неразрешенный внешний символ?

Символ — это внутреннее имя функции или глобальной переменной. Это форма имени, используемая или определенная в скомпилированном объектном файле или библиотеке. Глобальная переменная определяется в объектном файле, где для него выделяется хранилище. Функция определена в объектном файле, где размещается скомпилированный код для тела функции. Внешний символ является ссылкой в одном файле объекта, но определен в другой библиотеке или объектном файле. Экспортированный символ — это открытый объект, который становится общедоступным для файлового файла или библиотеки, определяющей его.

Для создания приложения или библиотеки DLL в каждом используемом символе должно быть определено определение. Компоновщик должен Разрешитьили найти определение сопоставления для каждого внешнего символа, на который ссылается каждый файл объекта. Компоновщик создает ошибку, если не удается разрешить внешний символ. Это означает, что компоновщику не удалось найти соответствующее определение экспортированного символа в любом из связанных файлов.

Проблемы компиляции и компоновки

Эта ошибка может возникать:

Если в проекте отсутствует ссылка на библиотеку (. LIB) или Object (. OBJ-файл). Чтобы устранить эту проблему, добавьте в проект ссылку на требуемую библиотеку или файл объекта. Дополнительные сведения см. в разделе lib files as input компоновщика.

Если проект содержит ссылку на библиотеку (. LIB) или Object (. OBJ), который, в свою очередь, требуются символы из другой библиотеки. Это может произойти даже в том случае, если не вызываются функции, вызывающие зависимость. Чтобы устранить эту проблему, добавьте в проект ссылку на другую библиотеку. Дополнительные сведения см. в разделе понимание классической модели для связывания: использование символов в качестве пути.

При использовании параметров /NODEFAULTLIB или /Zl . При указании этих параметров библиотеки, содержащие требуемый код, не будут связаны с проектом, если они не включены явным образом. Чтобы устранить эту проблему, явно включите все библиотеки, используемые в командной строке компоновки. Если при использовании этих параметров отображается множество отсутствующих имен функций CRT или стандартной библиотеки, явно включите библиотеки CRT и библиотеки стандартных библиотек или файлы библиотеки в ссылку.

При компиляции с параметром /CLR . Возможно, отсутствует ссылка на .cctor . Дополнительные сведения об устранении этой проблемы см. в разделе Инициализация смешанных сборок.

Если при построении отладочной версии приложения вы связываетесь с библиотеками в режиме выпуска. Аналогично, если вы используете параметры /MTD или /MDD или определяете _DEBUG , а затем связываетесь с библиотеками выпусков, то во многих других случаях следует рассчитывать на множество потенциальных неразрешенных внешних значений. Связывание сборки в режиме выпуска с отладочными библиотеками также вызывает аналогичные проблемы. Чтобы устранить эту проблему, убедитесь, что вы используете отладочные библиотеки в отладочных сборках и розничных библиотеках в ваших розничных сборках.

Если код ссылается на символ из одной версии библиотеки, но вы связываете другую версию библиотеки. Как правило, нельзя смешивать объектные файлы или библиотеки, созданные для разных версий компилятора. Библиотеки, поставляемые в одной версии, могут содержать символы, которые не могут быть найдены в библиотеках, включенных в другие версии. Чтобы устранить эту проблему, создайте все объектные файлы и библиотеки с одной и той же версией компилятора, прежде чем связывать их друг с другом. дополнительные сведения см. в разделе совместимость двоичных данных C++ между версиями Visual Studio.

Если пути к библиотекам устарели. диалоговое окно сервис > параметры > проекты > VC++ каталоги в области выбор файлов библиотеки позволяет изменить порядок поиска в библиотеке. Папка Компоновщик в диалоговом окне страницы свойств проекта может также содержать неактуальные пути.

при установке нового Windows SDK (возможно, в другое расположение). Необходимо обновить порядок поиска библиотеки, чтобы он указывал на новое расположение. Как правило, путь следует поместить в новый каталог include и lib для пакета SDK перед расположением Visual C++ по умолчанию. Кроме того, проект, содержащий внедренные пути, может по-прежнему указывать на старые пути, которые являются допустимыми, но устарели. Обновите пути для новых функций, добавленных новой версией, которая установлена в другое расположение.

При построении в командной строке и создании собственных переменных среды. Убедитесь, что пути к инструментам, библиотекам и файлам заголовков имеют одинаковую версию. Дополнительные сведения см. в статье Использование набора инструментов MSVC из командной строки.

Проблемы кодирования

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

Несовпадение регистра в исходном коде или файле определения модуля (DEF). Например, если вы назначите переменную var1 в одном исходном файле C++ и попытаетесь получить к ней доступ, как VAR1 в другой, возникает эта ошибка. Чтобы устранить эту проблему, используйте согласованное написание имен и имена регистров.

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

Вызов функции C из программы на языке C++ без использования extern «C» объявления для функции C. Компилятор использует разные внутренние соглашения об именовании символов для кода C и C++. Внутреннее имя символа — это то, что ищет компоновщик при разрешении символов. Чтобы устранить эту проблему, используйте extern «C» обертку для всех объявлений функций C, используемых в коде C++, в результате чего компилятор должен использовать внутреннее соглашение об именовании языка c для этих символов. Параметры компилятора /TP и /TC заставляют компилятор компилировать файлы как C++ или C соответственно, независимо от расширения имени файла. Эти параметры могут привести к тому, что имена внутренних функций отличаются от предполагаемых.

Попытка сослаться на функции или данные, у которых нет внешней компоновки. В C++ встроенные функции и const данные имеют внутреннюю компоновку, если явно не указано в качестве extern . Чтобы устранить эту проблему, используйте явные extern объявления для символов, которые ссылаются вне определяющего исходного файла.

Отсутствует тело функции или определение переменной . Эта ошибка часто возникает при объявлении, но не определении, переменных, функций или классов в коде. Компилятору требуется только прототип функции или extern объявление переменной, чтобы создать объектный файл без ошибок, но компоновщик не может разрешить вызов функции или ссылку на переменную, так как код функции или переменное пространство не зарезервированы. Чтобы устранить эту проблему, обязательно Определите каждую указанную функцию и переменную в исходном файле или библиотеке, на которую вы связываетесь.

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

Код C++, который вызывается при включении прототипа функции в определение класса, но не включает реализацию функции. Чтобы устранить эту проблему, обязательно предоставьте определение для всех членов класса, которые вы вызываете.

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

Попытка использовать переменную, объявленную в функции (Локальная переменная), за пределами области этой функции. Чтобы устранить эту проблему, удалите ссылку на переменную, которая не находится в области действия, или переместите переменную в область более высокого уровня.

При построении окончательной версии проекта ATL создается сообщение о том, что код запуска CRT является обязательным. Чтобы устранить эту проблему, выполните одно из следующих действий.

Удалите _ATL_MIN_CRT из списка определений препроцессора, чтобы разрешить включение кода запуска CRT. Дополнительные сведения см. в разделе Страница свойств General (Project).

Если это возможно, удалите вызовы функций CRT, требующих код запуска CRT. Вместо этого используйте эквиваленты Win32. Например, используйте lstrcmp вместо strcmp . Известными функциями, требующими код запуска CRT, являются некоторые функции строк и вычислений с плавающей запятой.

Проблемы согласованности

В настоящее время нет стандарта для декорирования имен C++ между поставщиками компиляторов или даже между разными версиями одного и того же компилятора. Объектные файлы, скомпилированные с разными компиляторами, могут не использовать одинаковую схему именования. Связывание их может вызвать ошибку LNK2001.

Смешивание встроенных и невстроенных параметров компиляции в разных модулях может вызвать ошибку LNK2001. Если библиотека C++ создается с включенной функцией встраивания функций (/Ob1 или /Ob2), но соответствующий заголовочный файл, описывающий функции, отключен (без inline ключевого слова), возникает эта ошибка. Чтобы устранить эту проблему, определите функции inline в файле заголовка, который включается в другие исходные файлы.

Если вы используете #pragma inline_depth директиву компилятора, убедитесь, что задано значение 2 или более, и убедитесь, что вы также используете параметр компилятора /Ob1 или /Ob2 .

Эта ошибка может возникать, если опустить параметр LINK/NOENTRY при создании библиотеки DLL только для ресурсов. Чтобы устранить эту проблему, добавьте параметр/NOENTRY в команду Link.

Эта ошибка может возникать, если в проекте используются неверные параметры/SUBSYSTEM или/ENTRY. Например, при написании консольного приложения и задании/SUBSYSTEM: WINDOWS создается неразрешенная внешняя ошибка для WinMain . Чтобы устранить эту проблему, убедитесь, что вы соответствуете параметрам типа проекта. Дополнительные сведения об этих параметрах и точках входа см. в разделе Параметры компоновщика /SUBSYSTEM и /entry .

Ошибки экспортированного файла DEF

Эта ошибка возникает, когда экспорт, указанный в DEF-файле, не найден. Это может быть вызвано тем, что экспорт не существует, написан неправильно или использует декорированные имена C++. DEF-файл не имеет декорированных имен. Чтобы устранить эту проблему, удалите ненужные экспорты и используйте extern «C» объявления для экспортированных символов.

Использовать декорированное имя для поиска ошибки

Компилятор и компоновщик C++ используют декорирование имен, также называемое искажением имени. Декорирование имен кодирует дополнительные сведения о типе переменной в ее имени символа. Имя символа для функции кодирует свой возвращаемый тип, типы параметров, область и соглашение о вызовах. Это декорированное имя — это имя символа, которое компоновщик ищет для разрешения внешних символов.

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

Чтобы помочь вам найти причину, в сообщении об ошибке отображаются две версии имени. В нем отображается «понятное имя», имя, используемое в исходном коде, и декорированное имя (в круглых скобках). Вам не нужно знать, как интерпретировать декорированное имя. Вы по-прежнему можете выполнять поиск и сравнивать его с другими декорированными именами. Программы командной строки могут помочь найти и сравнить ожидаемое имя символа и фактическое имя символа:

Параметры /EXPORTS и /SYMBOLS программы командной строки DUMPBIN полезны здесь. Они могут помочь определить, какие символы определены в .dll и файлах объектов или библиотек. Можно использовать список символов, чтобы убедиться, что экспортированные декорированные имена соответствуют декорированным именам, которые ищет компоновщик.

В некоторых случаях Компоновщик может сообщать только о декорированном имени символа. Для получения недекорированной формы декорированного имени можно использовать программу командной строки UNDNAME.

Источник