Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Marsh Ray (marsh_at_[hidden])
Date: 2011-03-04 16:17:19

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