Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2011-03-05 02:42:37

On 04/03/11 23:35, Marsh Ray wrote:
> 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.
I requires some adaptation and planning to fully see where the lazyness 
as to play a role.
>
> 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.
Maybe.
> 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.
>
Well, i can see that. But what if the compilation cost comes with some 
garanteed performances ?
>  Thus I tend to favor Lex/Yacc over Spirit and possibly would stick    
> GMP over a proto-based solution.
Even for performances improvement or better code maintenance ?
> 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++.
Or not, really ...

> 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?
Depends of the author really. As I said i am not expert in this very 
specific  area but as I understand it it is a matter of changing the 
granualrity of the elements used to store the piece of the bigger int 
and how they are stored in memory. If this part of the interface coudl 
be made geenric enough, we could even have bigint implemented on top of 
fusion vector or mpl sequence of CT integers or SIMD vector.