0

I am developing a library component which can be used as a template-heavy header-only library. The library has its own namespace for all the functions it exports.

My problem is that the library makes use of other header-only libraries, with their own namespaces. If a user wants to include my header-only library, he will import my library's namespace and also the third party library namespaces. What this means is if the user happens to import both my library and one of my library's dependencies at the same time, there may be a conflict of versions and/or namespaces.

To make another thing clear, I bundle a certain version of the third-party libraries along with my own, and am required to use that specific version. There is no way to offload the third-party functionality to a .cpp file instead of the header.

I would like to know what is the best method to deal with this issue, or is it even worth dealing with. So far, I know only of two solutions, and both of them seem like bad practice to me:

  1. Including the dependencies under my library's namespace (tends to break things).
  2. Renaming every instance of ext_namespace:: to my_namespace::ext_namespace in the third-party library headers.
daedsidog
  • 1,732
  • 2
  • 17
  • 36
  • 1
    renaming the namespace is probably the only option, many libraries have a macro to make this easier for you – Alan Birtles May 11 '23 at 13:53
  • @AlanBirtles I see. It's not that renaming them is difficult, it is just that I was under the impression that there was a more acceptable way of going about this. Thank you. – daedsidog May 11 '23 at 13:55
  • There is no best solution for this problem. My project enforces the policy of the entire project compiled at the same time, with a single set of libraries. Without trying to have mix-and-match versions, say if one component "needed" Boost 1.60 and another "needed" Boost 1.82 ... we'd task hammering all the components to use the same version of Boost. – Eljay May 11 '23 at 14:09
  • 1
    If you protect your headers with `#IFNDEF` and use `namespace` properly (without adding `using namespace`. I never found this to be a problem. – Adrian Maire May 11 '23 at 14:34
  • 1
    If you were using modules you could hide the dependency on other libraries completely. – ALX23z May 11 '23 at 14:41
  • 1
    The other option is to not bundle the third-party library, state in your documentation that it's a dependency, and then rely on the application developer to include that dependency in their build. That way there's no issue of multiple copies or conflicting versions. – Miles Budnek May 11 '23 at 14:52
  • Rather than renaming the 3rd party's namespace, why not simply wrap it inside a new namespace when `#include`'ing it inside of your library? `namespace my_ns { #include }` – Remy Lebeau May 11 '23 at 18:01
  • @RemyLebeau Would be ideal, but unfortunately doesn't work for big libraries that have includes in them (for example, libraries that use `cmath` suddenly won't be able to find the math functions. There are other threads where people have done this and it ended up bad for them. – daedsidog May 11 '23 at 18:14

0 Answers0