adding header and cpp files from different folder in VS project

Pages: 12
I had a visual studio project which was working perfectly. As far as the project contained many headers and it was sometime confusing to navigate through, I decided to sort them out based on their functionality. I made different folders (including basic, domain, solver, problem, output) and added the header and cpp files from those folders into my project. Also I added the path in the additional include directory ($(ProjectDir)..\..\basic ,...). Now I am getting some error which I don't understand what is the problem. Thanks in advance for your help.

I am working with VS 2022.

Severity Code Description Project File Line Column Suppression State
Error LNK2019 unresolved external symbol "public: double * __cdecl Node::get_pos(void)" (?get_pos@Node@@QEAAPEANXZ) referenced in function "public: __cdecl Element::Element(class std::vector<int,class std::allocator<int> > *,class std::vector<class Node,class std::allocator<class Node> > &,class std::vector<int,class std::allocator<int> > &)" (??0Element@@QEAA@PEAV?$vector@HV?$allocator@H@std@@@std@@AEAV?$vector@VNode@@V?$allocator@VNode@@@std@@@2@AEAV12@@Z) SLPFEM D:\SLPFEM\vc2019\SLPFEM\element.obj 1 1
Error LNK2019 unresolved external symbol "public: double __cdecl Utilities::det(class std::vector<class std::vector<double,class std::allocator<double> >,class std::allocator<class std::vector<double,class std::allocator<double> > > >)" (?det@Utilities@@QEAANV?$vector@V?$vector@NV?$allocator@N@std@@@std@@V?$allocator@V?$vector@NV?$allocator@N@std@@@std@@@2@@std@@@Z) referenced in function "public: void __cdecl Element::Calculate_DN_(void)" (?Calculate_DN_@Element@@QEAAXXZ) SLPFEM D:\SLPFEM\vc2019\SLPFEM\element.obj 1 1
Last edited on
It's a linker error. It's telling you that, after all the source code has been compiled into object code, the linker can find something trying to call public: double * __cdecl Node::get_pos(void), but cannot find the definition of that entity anywhere in the object code.

You need to:

- find where that definition is
- ensure that that definition is being compiled by your project into object code
- modify your linker settings so that that object code (*) is being linked into the final build target

(*) and, indeed, that all of your source code is being compiled to object code
The definitions are inside the header file. instead of adding through existing file, I added new header and cpp files through project-->ad new .h and.cpp and compiled the code. I was expecting the error will be gone but I was wrong.
Really, C/C++ does not care about the name or directory of a source/header file.

...as long as all header files you are trying to #include are found in one of the the "include" directories.

But you have to keep in mind that a header file usually only contains the function declaration, not the actual implementation! So you will get a linker error, as above, if the implementation was not linked properly! If the implementation is in a source file (.cpp), then you must compile that source file and link the resulting object code (.obj) file. And if the implementation is in a library, then you must link that library (.lib) file.

Note that Visual Studio automatically compiles and links all source code files that you add to your project. So that should be a no-brainer. If you use additional libraries, you have to set them up properly, though!

(Also, the declarations in your header files must match exactly the actual implementation in the corresponding source file or the corresponding library. Otherwise, you are going to run into trouble!)
Last edited on
Thanks for the answer. I think I understand what is the problem now. The code works well until all header files are function declaration. but when I added a header file containing the definition of a class or some implementation then the problem starts.

if the implementation was not linked properly! If the implementation is in a source file (.cpp),
then you must compile that source file and link the resulting object code (.obj) file. And if the
implementation is in a library, then you must link that library (.lib) file.


in this case then the modification and debugging won't be a problem?
Last edited on
but when I added a header file containing the definition of a class or some implementation then the problem starts

Again: Normally, your header file (.h) will contain only the function or class declaration, not its implementation. The implementation should be in the corresponding source code file (.cpp).

But, then, just #include'ing the header file, where you want to use the function or class, will not be enough. The source code file containing the function's or class' implementation must be compiled and linked too!

An exemplary project setup would look like this:
1
2
3
4
5
6
/* MyClass.h */
class MyClass
{
public:
    int some_function(void);
};

1
2
3
4
5
6
7
/* MyClass.cpp */
#include "MyClass.h"

int MyClass::some_function(void)
{
    return 42;
}

1
2
3
4
5
6
7
8
9
/* main.cpp */
#include "MyClass.h"

int main(void)
{
    MyClass instance;
    printf("%d\n", instance.some_function());
    return 0;
}
Last edited on
Thanks for the answer. I compiled all the cpp files but link them?
As said before, in your Visual Studio project, if you set the item type to "C/C++ Compiler", which is the default for .cpp files, then Visual Studio will compile that file and link its output (.obj) into the target (e.g. EXE).

https://i.imgur.com/sFc8tOs.png

(Also be sure that the "Exclude from build" option is not set)

_________________

Note: If you work with additional libraries, then these must be set up in your project. If the library is built as a part of your VS solution, then you can simply add a reference to the "library" project to your "main" project; if you use a pre-built library, then it must be added to "Additional Dependencies" in the Linker settings.
Last edited on
The problem with header and cpp files solved but I have problem with external dependencies.

Severity Code Description Project File Line Column Suppression State
Error LNK2019 unresolved external symbol __imp_atof referenced in function Parser_dhReadDouble SLPFEM D:\SLPFEM\vc2019\SLPFEM\HYPRE.lib(Parser_dh.obj) 1 1

Severity Code Description Project File Line Column Suppression State
Error LNK2019 unresolved external symbol __imp_clock referenced in function time_getWallclockSeconds SLPFEM D:\SLPFEM\vc2019\SLPFEM\HYPRE.lib(timer.obj) 1 1

Severity Code Description Project File Line Column Suppression State
Error LNK2001 unresolved external symbol __imp_feof SLPFEM D:\SLPFEM\vc2019\SLPFEM\HYPRE.lib(Vec_dh.obj) 1 1

There are few errors like this. Actually every single external dependencies has this issue.
Where do those "external" dependencies come from? A third-party library?

(Also see the remark about libraries in my previous post)

______________

Furthermore, be aware that the library, which you are linking into your project, may have its own dependencies! Those "transitive" dependencies you will to have to satisfy too...

______________

The library that you are trying to link should be built with the same C-Runtime (CRT) as your own project! Mixing code that was built with /MT (static CRT) and code that was built with /MD (shared CRT) is a bad idea...
Last edited on
The libraries are third party like mpi, metis, hypre.
Last edited on
Okay. Be sure you add the required third-party libraries and their dependencies to "Additional Dependencies" in the Linker settings of your project. Also, as pointed out before, make sure that the C-Runtime (/MT vs. /MD) used by those libraries matches with that of your "main" project, or there will be problems!

Note: If you work with static libraries, then all libraries as well as the "main" project should be built with /MT. If, instead, you use shared libraries, then all libraries as well as the "main" project should be built with /MD.
Last edited on
There is a command-line tool that makes integrating 3rd party library packages into VS much easier, vcpkg.
https://vcpkg.io/en/index.html

Just search the available libraries, and if there is one available just run vcpkg and let it download, configure and setup all the path dependencies for you.
@Kigar64551 I appreciate your help. Them problem is what you said. I build the project /MT. when I compile the project with including external library I get the following error

Severity Code Description Project File Line Column Suppression State
Error LNK2019 unresolved external symbol __imp_clock referenced in function gk_CPUSeconds SLPFEM D:\SLPFEM\SLPFEM\SLPFEM\metis.lib(timers.obj) 1 1

which I found "__imp_ prefix in unresolved external runtime library symbol from the linked library means the library was built with DLL runtime (/MD in C++ -> Code Generation -> Runtime Library)." I tried to build the library in /MT mood but I couldn't find that item when I was trying to set that when compiling the library. I just changed the MT to MD and it worked. is this a good idea?
Last edited on
@George P thanks thanks for the help.
What are the names of the libraries you are trying to install? If they are available in vcpkg integrating them into VS is much easier and less error-prone.
mpi,metis,eigen,hypre,clapack,trilinos
Trilinos is the only library package not available with vcpkg. The rest are, some in differing "flavors."

Maybe a different library that is available in vcpkg? All that depends on what you are using Trilinos for.

I just changed the MT to MD and it worked. is this a good idea?

You need to be aware of the consequences, when deploying your application!

If you build with /MD, then your binary (EXE file) will have runtime dependencies on the C-Runtime DLLs:
https://i.imgur.com/brDuZdq.png

For comparison, the same program built with static (/MT) C-Runtime:
https://i.imgur.com/hlzkFWc.png


Note: If you want to build with option /MT, then all of the libraries you link in (except Win32 system libraries) should be static libraries and they should be compiled with /MT option too. As soon as you want to link against shared libraries (DLL files), then option /MD needs to be used – otherwise the "main" EXE and each DLL file would contain its own separate copy of the "static" C-Runtime, which is asking for trouble!
Last edited on
To close the barn door of using the particular 3rd party libraries you currently are trying to get VS to recognize might be a "the horse has left" situation.

The effort of getting the packages you want to stuff into VS and working is a good teaching moment. I remember the PITA I constantly experienced before I tried vcpkg.

It was "Found the Holy Grail" for me. :Þ
Last edited on
Pages: 12