Question about sharing code between 2 projects

[TecHNooB]

Assuming you're developing on visual studio, how do you normally share code between 2 projects (while only maintaining 1 version of the original code)?

I'm getting a linker error but I'm trying to understand it. Maybe I just forgot a setting in VS. Let's say you have 2 projects. Each has 1 header file and 1 cpp file to implement the functions in their respective headers. Now, you try to use the functions from 1 project in the other. You include the header file that you want and you add the directory to your project. Compile... LNK2019. VS seems to not know where the (.obj) file is for the other project whose function you are trying to use.

Now, where I used to work, every project became a (.dll) and in that sense, it's easy to use code from other projects because VS explicitly asks you where things like the DLL are located. VS doesn't seem to ask where the (.obj) files are located. I also recall there being entire implementations stored in header files (instead of the usual header-cpp pairing), which probably enables you to avoid the LNK2019 problem as well. But VS does this annoying thing where if you implement everything in a header file and 2 cpp files include that header file, the linker will yell at you for having 2 obj files that try to implement the same function.

Anyways, what am I missing? What's the usual procedure for doing this?

 

[Merad]

Break out the shared code into a third project that compiles to either a static library (.lib) or dynamic library (.dll). Then add the include directories to your other projects in the compiler settings, and add the library file/path to the linker settings.

But VS does this annoying thing where if you implement everything in a header file and 2 cpp files include that header file, the linker will yell at you for having 2 obj files that try to implement the same function.

Well, yeah. The linker by default has no way to tell if a multiple definition happened because of a function being in a header, or because there are actually two separate functions with the same signature.

You can tell the compiler to ignore multiple definitions of a function by tagging it with the inline specifier. But you really don't want to stick a lot of code in header files unless you have no choice, such as with templates (which are inline by default, btw).

 

[TecHNooB]

1 other question.

I've used libraries where all you have to do is include a header file in order to use their functionality. No compilation needed. Just include a reference to where you got the header file and include the header file in your project. How do these libraries work?

 

[Merad]

They're either composed entirely of templates or they're using inlined functions.

 

[Markbnj]

They're either composed entirely of templates or they're using inlined functions.

Or its already compiled and you're just linking a .lib or .dll statically.

Edit: eh, can't tell if OP is excluding adding a library reference to the project. If it literally is just a header file, then yeah, what Merad said.

 

[TecHNooB]

o i see. thanks for the replies I didn't know COM would come back to haunt me so quickly.

Does anyone know a smart way to write tests for your C++ code without throwing everything into a DLL? Cuz you're immediately faced with COM or a billion load library calls when that happens. That and the rest of your program basically needs to be thrown into dlls for the test to get the components you originally wanted to run. it gets so messy i dont even want to do it.

I just want to do something simple. Create a few objects. Make them spit out some data. Compare to reference data. It's turning out to be a linker nightmare (in VS)

 

[Merad]

Boost has a library with unit testing framework. What I've done before is set up the normal release/debug build targets to create the normal program exe, but have another build target which compiles a separate main function and runs the unit tests. IMO the boost testing stuff isn't quite as nice as what you get with C#, Java, etc, but it's pretty decent.

Edit: For that matter if you want extremely basic tests you could just make another build target with a separate main function to run whatever for testing.

 

[TecHNooB]

Boost has a library with unit testing framework. What I've done before is set up the normal release/debug build targets to create the normal program exe, but have another build target which compiles a separate main function and runs the unit tests. IMO the boost testing stuff isn't quite as nice as what you get with C#, Java, etc, but it's pretty decent.

Edit: For that matter if you want extremely basic tests you could just make another build target with a separate main function to run whatever for testing.

both suggestions sound good. I'll look into it, thanks