Почему компоновщик не может видеть мои (определенно определенные) внешние элементы?

У меня есть класс с заголовком и файлом .cpp. Я объявляю свои функции в заголовке и определяю их в файле .cpp, как и вы.

Заголовок:

#pragma once

// my #includes 

class CDNAGenerator
{
private:
    // stuff 
public:
    CDNAGenerator(int, int);
    ~CDNAGenerator();

    void FilterMeasurementsForOutliers(std::vector<double>& measurement_values);

    // plenty more things

};

Цена за конверсию:

CDNAGenerator::CDNAGenerator( int genes, int chromosomes )
{
    // constructor code
}

void CDNAGenerator::FilterMeasurementsForOutliers(std::vector<double>& measurement_values)
{
    // function code
}

Затем из отдельного проекта в том же решении я ссылаюсь на файл .h (но не на .cpp, что, похоже, приводит к множественным ошибкам определения):

#include "..\CalibrationTool\DNAGenerator.h"

И вызовите эти функции:

CDNAGenerator* dnaGenerator = new CDNAGenerator(30, 0);
dnaGenerator->FilterMeasurementsForOutliers(values);

Но я получаю неразрешенные внешние ошибки для CDNAGenerator::CDNAGenerator(int, int) и для CDNAGenerator::FilterMeasurementsForOutliers(class std::vector > &)

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


c++ linker-errors unresolved-external
person technorabble    schedule 18.09.2013    source источник
comment
Вы добавили исходный файл в проект? Или встроенный с ним, если вы делаете это вручную?   -  person Some programmer dude    schedule 18.09.2013
comment
@joachim-pileborg да, это определенно в проекте (при условии, что вы имеете в виду проект, в котором живет его файл .h?)   -  person technorabble    schedule 18.09.2013
comment
Отдельный проект, это ключ. Если вы хотите, чтобы код в проекте A использовал код в проекте B, то проект B должен создать библиотеку, с которой может связываться проект A. Этого не происходит только потому, что оба проекта являются частью одного и того же решения. Или вы можете просто добавить исходный файл в оба проекта.   -  person john    schedule 18.09.2013
comment
@john, это может произойти, но вы должны настроить проекты как сборки-зависимости и убедиться, что зависимый проект имеет установленные библиотеки зависимых проектов (простите меня, если я не получите правильную точную формулировку; прямо сейчас передо мной не работает devstudio). Установка области действия решения A-references-B в глобальной конфигурации решения настроит большую часть этого за вас, хотя это гораздо больше похоже на C#, чем на C++.   -  person WhozCraig    schedule 18.09.2013
comment
@technorabble Вы установили зависимость сборки между двумя проектами? (полагаю, что нет). Перейдите в меню «Проект», выберите «Создать зависимости...» и убедитесь, что ваша цепочка «Это зависит от того» правильно настроена (должен быть установлен только один флажок, если он настроен так, как вы описываете). Я считаю, что по умолчанию библиотека-ссылка-зависимость включена, так что это должно очень приблизить вас к тому, что вы хотите, как только зависимость будет установлена.   -  person WhozCraig    schedule 18.09.2013

Ответы (2)


arrow_upward
0
arrow_downward

Добавьте файл CPP в проект

person Matt    schedule 18.09.2013
comment
Могу подтвердить, что файл DNAGenerator.cpp всегда был частью проекта CalibrationTool. Вы предлагаете мне добавить его в вызывающий проект? - person technorabble; 18.09.2013
comment
Да, в противном случае вам нужно экспортировать этот класс и связать файл lib - person Matt; 18.09.2013
comment
к сожалению, это перетаскивает все зависимости файла DNAGenerator.cpp, заполняя мой список ошибок неразрешенными внешними факторами. Ожидается ли это? Если мне в конечном итоге придется тянуть все, что противоречит цели. Такое ощущение, что должен быть более чистый способ... - person technorabble; 18.09.2013
comment
Затем вы должны экспортировать этот класс в другую DLL и связать файл lib. Проверьте это: stackoverflow.com/questions/27998 / - person Matt; 18.09.2013

arrow_upward
0
arrow_downward

Какой компилятор вы используете? Gcc (mingw) не поддерживает #pragma once Используйте защиту кода, чтобы избежать «множественных определений».

#ifndef MYCLASS_H
#define MYCLASS_H
class MyClass {
...
}
#endif
person mugiseyebrows    schedule 18.09.2013
comment
VS2012, поэтому он достаточно безопасен, хотя и не зависит от компилятора. - person technorabble; 18.09.2013