2

This is a follow up to a previous question.

I'm developing a library for which clients will need to provide complex types like matrices and quaternions. Internally, I'll be using Eigen to manipulate these types and, based on the discussion in the linked question, I'll probably put a thin wrapper around Eigen's types and ask that clients provide those types to my library, essentially hiding Eigen as an internal implementation detail.

Since some of my clients may, in fact, already be using Eigen so a suggestion was made for me to provide some sort of to/from Eigen functions in my wrapped versions of Eigen's types.

That all sounds fine, but I'm concerned about what might happen if my library uses a different version of Eigen internally than that my clients are using. If the two versions are ABI compatiable, then I don't see any problem. However, if they are not, then I can imagine some "bad" things happening. I'm especially concerned since Eigen is a header-only library and I can't assume that, for example, my library and my clients will all link against the same compiled version of the third-party library.

If I provide my users with source code and have them compile against Eigen themselves, then I won't have to worry too much. However, I'm mostly concerned about the case where I compile and install a DSO/DLL for my users.

So, I guess my question is: would I have to limit my clients to using an ABI-compatible version of the library? I could provide the necessary headers for Eigen, but then user's already using Eigen would have problems.

I guess I could leave it to my clients to do the necessary conversion to my wrapper types, but I'd like to provide the convenience functions.

Please note that although I'm talking about Eigen in particular, this question could apply to any third-party library that provides types.

Thanks!

Community
  • 1
  • 1
plasma
  • 848
  • 5
  • 9

1 Answers1

2

Providing your own types is definitely the most universal approach, and ensure that people can use your library with OR without a third-party library (i.e Eigen). Since you can never hope to cover all possible third party libraries which your client might use, I'd suggest leaving the conversion functions to your end-users/implementers.

If providing the conversion/convenience functions is extremely important, then just implement them in a separate source file and provide it to your clients directly; a little bit of sugar coating to show them you care.

As an aside, I think you always want to use "standard" structures where available. I know STL does not have a "Matrix" or "Quaternion" data type, but Boost does, and Boost is about as close as you can get to the standard without actually being in the standard. So that provides yet one more possibility for you.

BTownTKD
  • 7,911
  • 2
  • 31
  • 47