c++ LNK2019: unresolved symbol in std::vector [duplicate] - c++

I have tried this code in a totally separate project, and it works fine (the only difference being that the project that is not working is being exported as a DLL). Here is the code:
RTATMATHLIB.CPP
#include "stdafx.h"
#include "RTATMATHLIB.h"
#include <math.h>
#include <vector>
#include <algorithm>
#include <stdexcept>
using namespace std;
double someFunc(double** Y, int length)
{
vector<double> myVector;
for(int i = 0; i < length; i++)
{
double value = (*Y)[i];
vector<double>::iterator it = find(myVector.begin(), myVector.end(), value);
if(it != myVector.end())
{
continue;
}
else
{
myVector.push_back(value);
}
}
return 0;
}
RTATMATHLIB.H
__declspec(dllexport) double someFunc(double** Y, int length);
ERRORS
Error 1 error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in function "public: __thiscall std::_Vector_const_iterator<double,class std::allocator<double> >::_Vector_const_iterator<double,class std::allocator<double> >(double *,class std::_Container_base_secure const *)" (??0?$_Vector_const_iterator#NV?$allocator#N#std###std##QAE#PANPBV_Container_base_secure#1##Z) RTATMATHLIB.obj RTATMATHLIB
Error 2 fatal error LNK1120: 1 unresolved externals
And that's it. I am not sure why it works in the other project and not this one...

I found another forum post, where somebody seems to have reported the same exact problem that you are having. Please check to see if you have
_DEBUG
defined either in your project settings (under C/C++ -- Preprocessor) or somewhere in your code (or include files).
It looks as if std::vector thinks you are building a debug build, when you are in fact creating a release build.
I hope this helps.

The problem in my case was a Debug configuration with Runtime Library set to Multi-threaded DLL. The fix was to change it to Multi-threaded Debug DLL. The error is gone. Removing _DEBUG macro was also a kind of workaround, by I guess it's not a good idea because you end up with debug build linked to non-debug standard library.

The problem was I had _DEBUG defined in C/C++->Preprocessor. Changing it to NDEBUG solved the problem.

Worked for me with :
The problem in my case was a Debug configuration with Runtime Library set to Multi-threaded DLL. The fix was to change it to Multi-threaded Debug DLL

Related

C++ Unit Test in Visual Studio 2019

I am having a problem with Visual Studio 2019 CPPUnitTestFramework. I follow the instructions, but every time I get an error. I have looked for tutorials, but anything I get is for Visual Studio 2017 and it does not solve my problem.
I am writing a program that uses OOP in C++ and I want to make unit tests, since it is going to be a considerably long project. The problem that I am having is that the program is not compiling in the test module.
Consider that I have the code such that I have the header file:
//A.h
#pragma once
class A
{
private:
// One parameter.
int a;
public:
// Add function.
int add(int, int);
// Subtract function.
int subtract(int, int);
A();
};
with the proper source file:
// A.cpp
#include "A.h"
int a;
int A::add(int alpha, int beta)
{
return alpha + beta;
}
int A::subtract(int alpha, int beta)
{
return alpha - beta;
}
A::A()
{
a = 4;
}
The structure of the program looks something like this:
To make my Unit Test, I right click on the "Solution 'TestTestUnit'" label and choose new project, look for the unit test, add the unit test and attach the reference, such that I get a file structure such as the one below:
To perform the unit test I write the code:
// TestUnitForTestTestUnit.cpp
#include "pch.h"
#include "CppUnitTest.h"
#include "../TestTestUnit/A.h"
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
namespace TestUnitForTestTestUnit
{
TEST_CLASS(TestUnitForTestTestUnit)
{
public:
TEST_METHOD(TestMethod1)
{
A first;
Assert::AreEqual(first.add(3, 2), 5);
}
};
}
When I try to run a test, the Test Explorer does nothing and throws the message: Aborting test run due to build failures. Please see the build for more details.
I cannot find the mistake here. The program runs perfect, but when instantiating a new "A" object the test fails. I am stuck here, are there any suggestions? What am I doing wrong (besides developing in Windows)?
UPDATE:
I have followed the suggestion to remove the namespace, as suggested by #ChrisMM, so that the test file now reads:
// TestUnitForTestTestUnit.cpp
#include "pch.h"
#include "CppUnitTest.h"
#include "../TestTestUnit/A.h"
using namespace Microsoft::VisualStudio::CppUnitTestFramework;
TEST_CLASS(TestUnitForTestTestUnit)
{
public:
TEST_METHOD(TestMethod1)
{
A first;
Assert::AreEqual(first.add(3, 2), 5);
}
};
such that when I run the Test Explorer gives the same message:
with error message:
1>------ Build started: Project: TestUnitForTestTestUnit, Configuration: Debug Win32 ------
1> Creating library C:\Users\<user>\Desktop\CPlusPlus\TestTestUnit\Debug\TestUnitForTestTestUnit.lib and object C:\Users\<user>\Desktop\CPlusPlus\TestTestUnit\Debug\TestUnitForTestTestUnit.exp
1>TestUnitForTestTestUnit.obj : error LNK2019: unresolved external symbol "public: int __thiscall A::add(int,int)" (?add#A##QAEHHH#Z) referenced in function "public: void __thiscall TestUnitForTestTestUnit::TestMethod1(void)" (?TestMethod1#TestUnitForTestTestUnit##QAEXXZ)
1>TestUnitForTestTestUnit.obj : error LNK2019: unresolved external symbol "public: __thiscall A::A(void)" (??0A##QAE#XZ) referenced in function "public: void __thiscall TestUnitForTestTestUnit::TestMethod1(void)" (?TestMethod1#TestUnitForTestTestUnit##QAEXXZ)
1>C:\Users\<user>\Desktop\CPlusPlus\TestTestUnit\Debug\TestUnitForTestTestUnit.dll : fatal error LNK1120: 2 unresolved externals
1>Done building project "TestUnitForTestTestUnit.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
Help would be appreciated.
You cannot put a test class inside a namespace. From the documentation
TEST_CLASS must be declared at namespace scope.
I suggest you to check if TestUnitForTestTestUnit has added Additional Dependencies. When I didn’t add it, the same problem as you occurred. After I added it, the program worked fine.
Right click TestUnitForTestTestUnit->Properties->C/C++->Linker->Input->Additional Dependencies-> add ..\TestTestUnit\Debug\*.obj

Errors LNK 2019 and LNK2028 for one function in a class, other works fine

I normally work in c# and am out of my wits for this one . I used Walkthrough: Creating and Using a Dynamic Link Library (C++) to create a Dynamic Link Library.
I have defined two methods as shown below
DeveloperConsoleManager.h
#pragma once
#include "atlstr.h"
#ifdef DEVCONSOLEMANAGER_EXPORTS
#define DEVCONSOLEMANAGER_API __declspec(dllexport)
#else
#define DEVCONSOLEMANAGER_API __declspec(dllimport)
#endif
namespace DeveloperConsoleManager
{
class DeveloperConsoleLogic
{
public:
// Returns a + b
static DEVCONSOLEMANAGER_API double Add(double a, double b);
static DEVCONSOLEMANAGER_API bool CheckforValidFile(CString fileName);
};
}
DeveloperConsoleManager.cpp
// DeveloperConsoleManager.cpp : Defines the exported functions for the DLL application.
//
#include "stdafx.h"
#include "DeveloperConsoleManager.h"
namespace DeveloperConsoleManager
{
double DeveloperConsoleLogic::Add(double a, double b)
{
return a + b;
}
bool DeveloperConsoleLogic :: CheckforValidFile(CString fileName)
{
return false;
}
}
I use these methods in a .cpp file in a different project (type: Application (.exe)). When I Build the solution, there are following linker errors
Warning 1 warning C4273: 'DeveloperConsoleManager::DeveloperConsoleLogic::Add' : inconsistent dll linkage e:\md_69\developerconsolemanager\developerconsolemanager.cpp 10
Warning 2 warning C4273: 'DeveloperConsoleManager::DeveloperConsoleLogic::CheckforValidFile' : inconsistent dll linkage e:\md_69\developerconsolemanager\developerconsolemanager.cpp 16
Error 3 error LNK2028: unresolved token (0A0004F1) "public: static bool __cdecl DeveloperConsoleManager::DeveloperConsoleLogic::CheckforValidFile(class ATL::CStringT > >)" (?CheckforValidFile#DeveloperConsoleLogic#DeveloperConsoleManager##$$FSA_NV?$CStringT#_WV?$StrTraitMFC_DLL#_WV?$ChTraitsCRT#_W#ATL#####ATL###Z) referenced in function "public: void __thiscall CSaSsiConsoleUi::UploadSsiCheck(void)" (?UploadSsiCheck#CSaSsiConsoleUi##$$FQAEXXZ) E:\MD_69\DeveloperConsoleUI\SaSsiConsoleUI.obj
Error 4 error LNK2019: unresolved external symbol "public: static bool __cdecl DeveloperConsoleManager::DeveloperConsoleLogic::CheckforValidFile(class ATL::CStringT > >)" (?CheckforValidFile#DeveloperConsoleLogic#DeveloperConsoleManager##$$FSA_NV?$CStringT#_WV?$StrTraitMFC_DLL#_WV?$ChTraitsCRT#_W#ATL#####ATL###Z) referenced in function "public: void __thiscall CSaSsiConsoleUi::UploadSsiCheck(void)" (?UploadSsiCheck#CSaSsiConsoleUi##$$FQAEXXZ) E:\MD_69\DeveloperConsoleUI\SaSsiConsoleUI.obj
Error 5 error LNK1120: 2 unresolved externals E:\MD_69\Debug\DeveloperConsoleUi.exe
There is no linker error for the "Add" method.
I have already included "DeveloperConsoleManager.lib" in Linker -> Input -> Additional Dependencies. Please help me find out what exactly am I doing wrong.
I would be glad to add any additional information needed.
Thanks to #Igor Tandetnik and the awesome thing that is internet, I figured it out. I am adding it as an answer so that some one else might benefit.
The problem was with CString. The project in which the function was defined was a dynamic link library (dll) and the call was being made from an MFC application. Now, the issue was that, MFC uses for CString while the non-MFC dll uses .
CString in is defined as:
typedef ATL::CStringT< TCHAR, StrTraitMFC_DLL< TCHAR > > CString;
while in is defined as:
typedef CStringT< TCHAR, StrTraitATL< TCHAR > > CString;
This, as you can clearly see is different. The workaround I used was using CAtlString instead of CString . However, please feel free to suggest any better way if you come across.

C++ DLL: unresolved external symbol

I seem to have some issues with creating new files for my project.
The issue is that in my sk_error.h file it seems to complain about unresolved external symbols (full error report below). When I place my OutOfRange class in my sk_interface.h file no one complains but when I put the class in the errors file it has issues with it.
If I was to comment out OutOfRange it works perfectly fine so I dont think that it is an issue with the DLL setup.
sk_error.h
#include <sk_platform.h>
#include <sk_interface.h>
namespace sky {
class SK_API OutOfRange : IError {
public:
OutOfRange() {
m_message = " Out Of Range";
m_value = (0 << 1);
}
std::string getMessage() override {
return m_message;
}
};
}
sk_platform.h
#if defined (SK_NONCLIENT_BUILD)
#ifndef SK_API
#define SK_API __declspec(dllexport)
#endif
#else
#ifndef SK_API
#define SK_API __declspec(dllimport)
#endif
#endif
sk_interface.h
#include <sk_platform.h>
#include <string>
namespace sky {
...
class SK_API IError {
public:
virtual std::string getMessage() = 0;
protected:
uint32_t m_value = 0;
std::string m_message = "Error not initialized";
};
}
The Client Project using the DLL
#include <sk_logmanager.h>
#include <sk_error.h>
#include <iostream>
int main() {
sky::g_LogManager.startup();
sky::OutOfRange err;
std::cout << err.getMessage() << "\n";
sky::g_LogManager.shutdown();
while (1) {}
}
Error Output
1>------ Build started: Project: SkyTest, Configuration: Debug Win32 ------
1>main.cpp
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall sky::OutOfRange::OutOfRange(void)" (__imp_??0OutOfRange#sky##QAE#XZ) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: virtual class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > __thiscall sky::OutOfRange::getMessage(void)" (__imp_?getMessage#OutOfRange#sky##UAE?AV?$basic_string#DU?$char_traits#D#std##V?$allocator#D#2##std##XZ) referenced in function _main
1>main.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall sky::OutOfRange::~OutOfRange(void)" (__imp_??1OutOfRange#sky##QAE#XZ) referenced in function _main
1>C:\Users\Matt\Documents\Game Development\DevEnv\SkyTest\Debug\SkyTest.exe : fatal error LNK1120: 3 unresolved externals
1>Done building project "SkyTest.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
Edit:
I am using Visual Studio 2017 (could be the source of the error). The Client Project is using the .lib file.
An unresolved external is always a link error. It even has it in its name: LNK2019.
It is telling you it cannot find the implementation for sky::OutOfRange::OutOfRange()
You have it in a header somewhere and you've called it, but you have not linked to the library that implements it.
We have no way of telling you what library implements it or where it lives on your hard drive. You will have to consult the documentation for OutOfRange, the author of it, or yourself.
I can tell you that you will want to check:
right click the executable project->
properties->linker->general->additional library directories
properties->linker->input->additional dependencies
and make sure the path to the library that defines OutOfRange is in the former and the library name is in the latter.
EDIT: If the library itself has a header that imports it, as it appears from the code you posted, you just need to set up the additional directories part.
In the end, you have to consult the documentation for whatever library you are using or hit up their forums.
I am not sure but this may be related to your solution configuration and solution platform. It wasn't working for me, when I set my solution configuration to "Debug" and platform to "x64"; it started working after setting it to Release - x86

Random accessing a vector of shared pointers [duplicate]

I have tried this code in a totally separate project, and it works fine (the only difference being that the project that is not working is being exported as a DLL). Here is the code:
RTATMATHLIB.CPP
#include "stdafx.h"
#include "RTATMATHLIB.h"
#include <math.h>
#include <vector>
#include <algorithm>
#include <stdexcept>
using namespace std;
double someFunc(double** Y, int length)
{
vector<double> myVector;
for(int i = 0; i < length; i++)
{
double value = (*Y)[i];
vector<double>::iterator it = find(myVector.begin(), myVector.end(), value);
if(it != myVector.end())
{
continue;
}
else
{
myVector.push_back(value);
}
}
return 0;
}
RTATMATHLIB.H
__declspec(dllexport) double someFunc(double** Y, int length);
ERRORS
Error 1 error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in function "public: __thiscall std::_Vector_const_iterator<double,class std::allocator<double> >::_Vector_const_iterator<double,class std::allocator<double> >(double *,class std::_Container_base_secure const *)" (??0?$_Vector_const_iterator#NV?$allocator#N#std###std##QAE#PANPBV_Container_base_secure#1##Z) RTATMATHLIB.obj RTATMATHLIB
Error 2 fatal error LNK1120: 1 unresolved externals
And that's it. I am not sure why it works in the other project and not this one...
I found another forum post, where somebody seems to have reported the same exact problem that you are having. Please check to see if you have
_DEBUG
defined either in your project settings (under C/C++ -- Preprocessor) or somewhere in your code (or include files).
It looks as if std::vector thinks you are building a debug build, when you are in fact creating a release build.
I hope this helps.
The problem in my case was a Debug configuration with Runtime Library set to Multi-threaded DLL. The fix was to change it to Multi-threaded Debug DLL. The error is gone. Removing _DEBUG macro was also a kind of workaround, by I guess it's not a good idea because you end up with debug build linked to non-debug standard library.
The problem was I had _DEBUG defined in C/C++->Preprocessor. Changing it to NDEBUG solved the problem.
Worked for me with :
The problem in my case was a Debug configuration with Runtime Library set to Multi-threaded DLL. The fix was to change it to Multi-threaded Debug DLL

Unresolved externals in C++ when using vectors and find

I have tried this code in a totally separate project, and it works fine (the only difference being that the project that is not working is being exported as a DLL). Here is the code:
RTATMATHLIB.CPP
#include "stdafx.h"
#include "RTATMATHLIB.h"
#include <math.h>
#include <vector>
#include <algorithm>
#include <stdexcept>
using namespace std;
double someFunc(double** Y, int length)
{
vector<double> myVector;
for(int i = 0; i < length; i++)
{
double value = (*Y)[i];
vector<double>::iterator it = find(myVector.begin(), myVector.end(), value);
if(it != myVector.end())
{
continue;
}
else
{
myVector.push_back(value);
}
}
return 0;
}
RTATMATHLIB.H
__declspec(dllexport) double someFunc(double** Y, int length);
ERRORS
Error 1 error LNK2019: unresolved external symbol __imp___CrtDbgReportW referenced in function "public: __thiscall std::_Vector_const_iterator<double,class std::allocator<double> >::_Vector_const_iterator<double,class std::allocator<double> >(double *,class std::_Container_base_secure const *)" (??0?$_Vector_const_iterator#NV?$allocator#N#std###std##QAE#PANPBV_Container_base_secure#1##Z) RTATMATHLIB.obj RTATMATHLIB
Error 2 fatal error LNK1120: 1 unresolved externals
And that's it. I am not sure why it works in the other project and not this one...
I found another forum post, where somebody seems to have reported the same exact problem that you are having. Please check to see if you have
_DEBUG
defined either in your project settings (under C/C++ -- Preprocessor) or somewhere in your code (or include files).
It looks as if std::vector thinks you are building a debug build, when you are in fact creating a release build.
I hope this helps.
The problem in my case was a Debug configuration with Runtime Library set to Multi-threaded DLL. The fix was to change it to Multi-threaded Debug DLL. The error is gone. Removing _DEBUG macro was also a kind of workaround, by I guess it's not a good idea because you end up with debug build linked to non-debug standard library.
The problem was I had _DEBUG defined in C/C++->Preprocessor. Changing it to NDEBUG solved the problem.
Worked for me with :
The problem in my case was a Debug configuration with Runtime Library set to Multi-threaded DLL. The fix was to change it to Multi-threaded Debug DLL