Re: [boost] [Review] XInt Review

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

On 03/04/2011 03:22 PM, Joel Falcou wrote:
> On 04/03/11 22:17, Marsh Ray wrote:
>>
>> 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" ?

I see two dimensions there: interface and implementation. Obviously 
interface is the place to expend a project's limited capacity to endure 
perfectionism.

While implementations can improve beneath a stable interface, you seem 
to be saying that it's "verison 1.0 or never" for support of expression 
templates because they bundle the logic required for efficiency into the 
interface itself.

It's been "never" so far for any standard C++ bigint facility.

Perhaps two separate libraries are worth considering: one with 
old-fashioned objects and overloaded operators enhanced with rvalue 
references delivered soon, and another with all the compile-time magic 
it can stand to become available at some unspecified point in the future.

>> 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.

I promise to look at this Proto again soon.

>> 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.

I admit I'm not terribly patient.

I have some mature, stable projects that take several seconds per 
translation unit to compile. They crept up that way over time. But those 
projects are in maintenance mode and I don't have to add much creativity 
to them very often. I can handle it.

But if I sit down to experiment, starting with with a brand new hello 
world project, and then I #include header file that puts a noticeable 
pause in my modify-compile-run cycle, then I am really reluctant to use 
it. If it adds time to hello world, how can I predict what it will cost 
if that project grows large?

When the pauses creep over a few seconds, I start multitasking and task 
switching then imposes a disproportionate penalty.

Thus I tend to favor Lex/Yacc over Spirit and possibly would stick with 
GMP over a proto-based solution.

I do not pretend that that this is an objective criticism of a library's 
design, only that it's what works best for me. But I'm sure I'm not the 
only one who evaluates their libraries that way.

>> 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.

At the end of the day, it's all Turing-equivalent. There remain C and 
Fortran programmers who haven't been converted by the actual performance 
gains theoretically enabled by template compile-time polymorphism. 
Future supercomputers are as likely to prefer some derivative of OpenCL 
or CUDA as they are C++.

I think 'willy-nilly' makes a wonderful bottom line standard to avoid, 
but a metaprogramming-heavy design is still seems very much a matter of 
personal style and preference. In my opinion (which I'm willing to 
change as long as it doesn't add too much to my compile times. :-)

> Well, if XInt actually provided range based interface and an extension
> mechanism for external big int representation, we could have a good start.

There we go.

What would it look like? Adapters on standard container<integral type> 
concepts?

How long until I can use it at a beta-level of interface stability?

- Marsh