Support boost::multiprecision::cpp_int as IntermediateType

[mdragon159]

Currently I'm using a fixed_32_32 via using int64_t as base type with boost::multiprecision::int128_t as the intermediate type. The one blocker to doing this is the following:

fpm/include/fpm/fixed.hpp

Line 26 in 8b488e3

static_assert(std::is_signed<IntermediateType>::value == std::is_signed<BaseType>::value, "IntermediateType must have same signedness as BaseType");

To my understanding, this static assert fails as the boost multiprecision library uses uint8_ts under the hood (for some reason). If I comment out the static assert and run my unit tests, all my current unit tests pass.

Thus, a light assumption I'm making at the moment is that boost::multiprecision types do work as intermediate types with standard signed ints, but they are (likely) needlessly failing fpm static asserts.

Opening this issue to request some sort of workaround to support these types as an intermediate type (eg, disable signed check specifically for boost::multiprecision types or perhaps do more direct static asserts),

[mdragon159]

As a side note, this isn't a big deal/high priority for me at all as I just need to comment out the relevant static_assert (and very carefully test). Unfortunately this does prevent me from using this library directly as a git submodule, but that's not a significant concern at all.

On a different note, thank you very very much for making this library. It's much easier to use than CNL as well has the trig functionality I needed, plus the various documentation with library comparisons incl. regarding performance made me very comfortable starting to use this library. This is overall saving me a ton of time in making a cross-platform deterministic game with fixed points under the hood. Ty again ^_^

[MikeLankamp]

I've noticed that issue as well. I think the is_integral assertion also fails for boost::multiprecision.

Edit: I see you're asking about IntermediateType, not BaseType. Yes, then the is_signed check is all that matters. My comment is basically #8.

I've tried to think of better alternatives, but there's really no good way to verify that a type acts like an integer. I don't think even C++20's concepts allow you to test that e.g. T{0} / 2 == T{0} (a property usually true for integers). In other words, C++ has no static "duck-typing" checks.

There may be no option than removing those checks, adding proper documentation and hoping people only use integer-like types. If you (or anyone) has other alternatives, I'm all ears.

And I'm glad to hear you find this library useful! The trigonometry stuff might be improvable in accuracy or performance, but that requires a level of knowledge of math I don't posses :)