Generic Wrapper Class for Big Number Libraries

Question

The project that I'm working on could benefit from having the possibility to easily swap between different big number libraries: GMP, OpenSSL, etc. My current implementation defines a template abstract base class in which I implement all the required operators (just to have some syntactic sugar) and I define the required pure virtual functions.

For each library, I have a derived class like this: class BigNumberGmp : public BigNumberBase<BigNumberGmp>. I know it kinda' breaks OOP, but the C++ covariance functionality is too restrictive and it does not allow me to return BigNumberBase objects from methods, only references, which is quite undesirable...

The problem is that I want the code that uses my custom wrappers to be able to work with any such wrapper: BigNumberGmp, BigNumberOpenSsl, etc. In order to achieve this, I defined typedef BigNumberGmp BigNumber and put it inside some conditional macros, like so:

#if defined(_LIB_GMP)
    typedef BigNumberGmp BigNumber;
#endif

Also, I include the appropriate headers in a similar fashion. This implementation requires that I define the _LIB_GMP symbol in the compiler options.

As you can see, this is a rather hackish technique, that I'm not really proud of. Also, it does not hide in any way the specialized classes (BigNumberGmp, BigNumberOpenSsl, etc). I could also define the BigNumber class multiple times, wrapped in _LIB_XXX conditional macros or I could implement the required methods inside the BigNumber class multiple times, for each library, also wrapped in the _LIB_XXX conditional macros. These two latter ideas seem even worse than the typedef implementation and they will surely mess up the doxygen output, since it will not be able to figure out why I have multiple items with the same name. I want to avoid using the doxygen preprocessor, since I still depend on the _LIB_XXX defines...

Is there an elegant design pattern that I could use instead? How would you approach such a problem?

Answer 1

The way I would do it is with the help of the pimpl idiom. I would first define a wrapper class:

class BigNumber {
private:
    class BigNumber_impl {
        virtual void do_something() = 0;
    }
    BigNumber_impl * impl;
public:
    void do_something() {
        impl->do_something();
    }
};

And then I would have BigNumberGMP, etc. inherit from BigNumber::BigNumber_impl. Then, you can return objects of BigNumbers but still have polymorphism under the hood.

This doesn't solve the issue of creating BigNumbers, and you also have to worry about how to add BigNumbers with different BigNumber_impl types. So your original solution may be good for your purposes. You will, at some point, have to rely on some preprocessor magic.

Answer 2

It looks like you're going to recompile each time you switch libraries in which case you can use template specialisation instead of inheritance.

Choosing which to use would be pretty much as you have it (something #if based), but you'd save the virtual members which means the compiler can still inline which means it could be significantly faster for some cases.

First of all, take structs that describe each of the implementations. In here you can put the basic API names that work in the same sort of way across all of the libraries. For example, if they all support an add operation that takes pointers to two big nums and returns a pointer to a new big num that contains the result you can do something like this:

(Note that I've not run this through a compiler, and I don't know what the actual APIs look like, but it should be enough to give a general idea of the approach)

struct GMP {
    GMP_ptr* add(GMP_ptr *l, GMP_ptr*r) {
        return GMPadd(l, r);
    }
};
struct OpenSSL {
    OpenSSL_ptr* add(OpenSSL_ptr*, OpenSSL_ptr*) {
        OpenSSL_ptr ret = NULL;
        OpenSSLadd(l, r, &ret);
        return ret;
    }
};

Now we can define a common super class that contains the use of these easy to map APIs:

template< typename B, typename R >
class common {
public:
    // Assume that all types have the same API
    R operator + (const common &r) {
        return R(B::add(l.ptr, r.ptr));
    }
};

The type B is the struct that defines the big number API, and the type R is the real implementation sub-class. By passing in R like this we solve the co-variant return problem.

For the real implementation we define a template that will do the work for us:

template< typename B >
class big_num;

Now we can specialise this for the implementations:

template<>
class big_num<OpenSSL> : common< OpenSSL, big_num<OpenSSL> > {
    OpenSSL_ptr *ptr;
public:
    big_num(OpenSSL_ptr*p)
    : ptr(p) {
    }
    big_num(const char *s)
    : ptr(OpenSSLBigNumFromString(s)) {
    }
    ~big_num() {
        OpenSSLBigNumFree(ptr)
    }
};

The operator + will come from the super class, and you can now use them like this:

void foo() {
    big_num< GMP > gmp1("123233423"), gmp2("234");
    big_num< GMP > gmp3 = gmp1 + gmp2;
    big_num< OpenSSL > ossl1("1233434123"), ossl2("234");
    big_num< OpenSSL > ossl3 = ossl1 + ossl2;
}

The advantage here is that there is minimum code duplication between specialisations due to the use of the structs to adapt between similar API features and a common implementation in one template. The specifics for a given API are now in the template specialisations, but there are no virtuals and there is no common super class. This means that the compiler can inline pretty much everything in your wrappers which will make them essentially as fast as they can be.

Due to the specialisation you also potentially have access to all of the implementations which may make your unit tests much easier to write/manage (you should be able to write templated versions of those too).

If you only want one of them to be visible then something like this:

#if BIGNUM=="GMP"
    typedef big_num<GMP> used_big_num;
#elif BIGNUM=="OpenSSL"
     typedef big_num<OpenSSL> used_big_num;
#endif

You may also need to put guards around the specialisations too if the headers aren't always available in which case you'll want a set of HAVE_GMP_BIGNUM and HAVE_OPENSSL_BIGNUM macros too.