I had to do bignum calculations in a C++ Windows environment a while ago and was surprised how few prepared solutions there are out there. In the end I settled for the MPIR library, a GMP fork. Had to compile the binaries, but the documentation was friendly enough. https://mpir.org/
Just to be clear, GMP also supports C++ interface and even C++11 custom literals (`123_mpz` etc.). Unfortunately many Windows builds of GMP seem to omit libgmpxx-*.dll required for the C++ interface.
This library is showing its age, for sure. Every time I've had to use it has been one headache or another. Not enough for me to drop it entirely but... close.
I'm curious about the issues you faced. Could you share some of them?
I have used it only lightly, but I always liked its simplistic API.
Also, I thought the performance was unbeatable at what it does (of course not comparable with native integers). And I am very impressed by the algorithms implemented (all the different multiplications at various integer widths, for example).
I've also only used it lightly, but like you I don't remember having much trouble with the API, seemed like a pretty regular C library to me.
I wanted some example programs to see how the API looked in use, and the manual said they were in the demos/ folder of the repository. So I clicked the link to the repository, and got this: [1] ("Internal Server Error"), which is honestly pretty concerning... There's a GitHub mirror though, and the API looks perfectly usable to me [2].
A bitch to use on just about every language in existence. The issue is having code that links to this breaks cross platform support -- especially in interpreted languages. Just a few days ago I had to try find a library for Rust that did fixed precision calculations with integers and most of them linked to GMP instead of implementing code in Rust. It meant I had to use another library because third-party deps breaks the complex build process for my teams software. In special software like cryptography I've also seen GMP avoided for speed reasons.
You can't blame this on GMP. People are free to interface with it in better ways from the languages you mention.
As for speed, I'm sure some very specialized applications can do better if they have constraints that allow for specific optimization, but as far as a general library goes I haven't seen better performance than GMP personally.
GMP doesn't do well in prime fields with a small, fixed number of limbs. Poly1305 and elliptic curves are both good examples. Its general routines aren't as fast as custom routines, and it doesn't execute in constant time.
MPFQ exists for short finite field work, but it hasn't achieved the popularity of GNU MP.
That would be nontrivial (although probably not impossible). At least that was Meson's experience in trying to support Rust: https://lwn.net/Articles/820836/
cargo is not a compiler, it's a build system. The difference between build systems and compilers is that compilers implement language specs, and build systems do whatever they want.
That's the problem with having multiple build systems. The fact that there is so much heterogeneity in C/C++ land means I spend way too much time trying to build things. When things are standardized, I don't have to think much about builds. They just work.
If build systems were made to interoperate (e.g. by having a common spec, or by implementing the same behavior), then we could have competing build systems without the fragmentation.
Rust has multiple compilers, but only a couple of them get actually used. If you're wondering what changed, it's probably 40 years of being forced to draw a 3-way Venn diagram between Clang, LLVM and GCC every time you want to build your software. The added conventions of Rust in conjunction with it's package specification means that most compilers are just going to be boring.
I have used it only lightly, but I always liked its simplistic API.
Also, I thought the performance was unbeatable at what it does (of course not comparable with native integers). And I am very impressed by the algorithms implemented (all the different multiplications at various integer widths, for example).
I wanted some example programs to see how the API looked in use, and the manual said they were in the demos/ folder of the repository. So I clicked the link to the repository, and got this: [1] ("Internal Server Error"), which is honestly pretty concerning... There's a GitHub mirror though, and the API looks perfectly usable to me [2].
[1]: https://gmplib.org/repo/
[2]: https://github.com/ryepdx/gmp/blob/master/demos/primes.c
As for speed, I'm sure some very specialized applications can do better if they have constraints that allow for specific optimization, but as far as a general library goes I haven't seen better performance than GMP personally.
MPFQ exists for short finite field work, but it hasn't achieved the popularity of GNU MP.
https://gitlab.inria.fr/mpfq/mpfq
this is what software such as CMake was created to solve. I guess the solution is to extend CMake to support Rust :)
That's the problem with having multiple build systems. The fact that there is so much heterogeneity in C/C++ land means I spend way too much time trying to build things. When things are standardized, I don't have to think much about builds. They just work.
If build systems were made to interoperate (e.g. by having a common spec, or by implementing the same behavior), then we could have competing build systems without the fragmentation.