On 04/03/11 22:17, Marsh Ray wrote:
Firstly, I believe in you expressing your opinion and value it.
Thanks :)
But it'd still be nice to have a standard bigint facility in C++ or Boost. But C++ seems like one of the last high-level languages without basic bigints at this point. We have regexes now for heaven's sake, integers were only conceived a few thousand years before!
I'm concerned that perfect is the enemy of good enough here.
and I agree. Now, can we consider the proposal fits in the "good enough" ?
Is it a requirement for Boost that every new library be state-of-the-art in its use of compile time polymorphism?
Maybe, maybe not. Now, I remind you that Phoenix have been delayed as being accepted into boost the first time, consensus being it has to use proto to be accepted.
MSVC 8.0 GCC 4.4
Well, at when do you start feeling "it compiles for too long" ? Template heavy coe is liek other code, it has to be well written to be fast, and here, fast to compile.
It's a problem for me, the poor developer, when I have to use the thing. Or not if I don't use it. But if no developers use it, the vendors don't make it a priority. Lots of numeric code is still written in C and Fortran. Whether that's because of the compiler or the mind, the abstraction penalty is real.
It is real when said abstraction is sued willy-nilly.
OK. Maybe expression templates aren't a big issue, I think I'm using them happily with GMP's C++ interface. But I'd much rather be using something in boost:: or std::trX::.
Well, if XInt actually provided range based interface and an extension mechanism for external big int representation, we could have a good start.