On 03/04/2011 09:51 AM, Joel Falcou wrote:
On 04/03/11 16:20, Marsh Ray wrote:
If the interface really does prescribe the implementation with a great deal of specificity, then in my view it should not be adopted as a library.
I disagree. People also see boost as a repository of staet of the art way of implementing things. Library like XInt comes with an a priori expectations of performances, whcih, currently, it does not deliver.
Fair enough.
Is that not prescribing an implementation?
It is. Now, i dont see why I should not express opinion on how to do something if said specifications actually helps the overall quality of the library. It is as prescribing as askign to use the n.log(n).log(n) algorithm instead of the trivial one for operator*
Firstly, I believe in you expressing your opinion and value it. 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. Is it a requirement for Boost that every new library be state-of-the-art in its use of compile time polymorphism?
A bigint facility that strained the limits of my compiler and pushed compile times through the roof is not useful to me.
Are you compiling with MSVC6 or g++-2.95.2 ?
MSVC 8.0 GCC 4.4
Sarcasm aside, compile time is a problem for compiler vendor.
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.
Expression enabled code is not something you add on top of another design like this. It is a concrete component of the design from the start.
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::. - Marsh