Finding different ways to share C++ functions with different C++ applications

Question

I'm trying to find different ways to reuse my C++ functions in different applications. Say for example I have the following functions:

      Function A(){} // this will do a complex math operation

      Function B(){} // this will load a complex shape file 

      Function C(){} // Print the results.

I need to use the above 3 functions in 3 different C++ programs. They are completely independent and I'm trying to see what the best way is to use them in all of my applications rather than writing same code 3 times.

I am thinking about the following options:

      Option A: Writing static library 
      Option B: Writing dynamic library 
      Option C: Windows Services 
      Option D: Same code and compile everywhere

Are there any other options? Or what would be the best option?

The only possible answer could be: It depends! And the things it depends on are numerous, to start with it depends very much on your use-cases, which for us are unknown. It also depends on if you want the "functions" to be utility-like functions, if you can predict all their future use (which generally you can't), if unknown applications are going to use the functions, and how the future unknown applications might want to use your functions, allowing the functions to be "called" remotely (i.e. over a network), and many many other things. So unfortunately your question is at the moment to broad — Some programmer dude, May 15 '15 at 21:54
Just do a static library and then if you need to you can turn it into a dynamic library later. Window Services doesn't really make much sense for a library since a Window Service typically offers a complete service rather than just a piece of functionality and you have to have some kind of interprocess interface such as pipes, shared memory, shared data files, or sockets. — Richard Chambers, May 15 '15 at 23:39
A C++ header file that is fully inlined to call C APIs that you build as a dynamic library. — jxh, May 15 '15 at 23:41

Jeremy Friesner · Answer 1 · 2015-05-16T05:09:35.767

If the functions are only going to be called "in-house" by yourself and/or your co-workers (i.e. they aren't going to be exposed to people who don't have access to your source code repository) then option (D) is sufficient. Just keep the the .cpp and .h files in a single well-known sub-directory of your source code repository and have each application's project file reference them as necessary. This is simple to implement and gives you maximum flexibility (since each project can compile the shared .cpp files with different compiler-flags that best suit its own needs, if necessary -- with a library you'd have to figure out a single set of compiler flags that would work for all applications that want to link to the library, which isn't always convenient).

If you're writing an API for public consumption, OTOH, things get a little more complex, since after you release the code to the public you will no longer be in full control of which versions are getting used and where. In that case you will have to make a decision based on who your users are and what you think they would be most comfortable with.

Option C can probably be tossed out since it's overkill for this sort of thing, and carries the penalty of tying your code to a particular OS with no compensatory advantage.

score 1 · Answer 2 · edited May 23 '17 at 12:21

It's option D (compile everywhere) all the way -- with the only exceptions being stand-alone libraries that are shared with many, many other people (or closed-source).

This makes it a lot easier to manage releases, because there really aren't any -- each copy of the library can be updated independently -- whenever is convenient.
This makes it easy for each project to debug into the library, with the particular version of the library that is in use.
This gives you the option of customizing the library for each project -- but use this capability judiciously to minimize merging complexity.

This choice is independent of whether or not you build the library it into a separate binary package as part of your build process.

I would recommend using something like git-submodules to manage the code -- except that the git-submodules feature is kind of half-baked.

Finding different ways to share C++ functions with different C++ applications

2 Answers2