Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Joel Falcou (joel.falcou_at_[hidden])
Date: 2011-03-04 10:19:45

Oook ... well, first i want to stress out i am not here to get personal 
at you Chad. This is a review process not a crusade.

Here's comment on your comments. Consider unanswered comments as being 
accepted by me as valid.

> Why would you? Give me a viable use-case, and if it fits the library's
> design criteria, I'll be happy to try to make it happen.

Well, let's say i just have some file format storing large integer this 
way or receiving large integer over a network by unconnected packet.
It's a variation of reading the int value from a string like 
"45748764465768754564634687314313270".

> No, you cannot. Deliberately. If you were able to, then the interface
> would be permanently stuck at a version-1 state, because if I made any
> future changes to it, it would break existing client code. In my
> opinion, the freedom to improve the internal design without breaking
> client code is far more desirable than giving client code free rein to
> mess around in its internals.

No. you shield yourself from this by having a proper iterator/range 
types that hides said details of your internals. Code works with 
std::vector iterator everywhere and the concept iterator makes it 
possible to work even if w/e vendor decide to implement quantum 
information storage instead of contiguous one.

> Your opinion has been noted. The code is not ideal, but it works, it's
> available, and it can (and will, if not rejected) be improved. If
> you're waiting for the perfect library to come along before you'll
> accept it, you're going to be waiting forever.

I am not. I am pointing out the fact that the current design is still 
requiring concept refinement so you could :

a/ propose your current implementation as a basic, free for all solution
b/ enable mapping to other representation with extension points

> Point A, you don't have to, LCM is already in there.

So i missed it. Sorry

> Point B, it can handle essentially any mathematical operation that can be expressed as
> a combination of existing operations. No one has yet provided any
> concrete example of a mathematical operation that *can't* be done using
> the operators and functions already available, and I suspect you'd have
> to get pretty esoteric to find one.

OK, so let me rephrase. What if i want to implement a function that has 
a non trivial algorithm which is faster than the usual combo of operations ?

> Then you're don't understand it.
Maybe, but I'll wager I do. Other concern is sharing data like this 
between threads may lead to memory contention and/or false sharing if 
data fit incomplete cache lines.

> Yes, I could break it up into 2K one-line files. Somehow I think that
> would be even harder to follow.

20 x 100 lines is OK in my book

> Would it be easier on everyone if I just deleted that line, since most
> people are bikeshedding about it?

Yes.

> GMP is a collaboration of dozens of developers, contains years of work,
> and includes low-level optimizations that go against XInt's design
> goals. XInt is the product of one developer over five months. Do you
> measure a child's running speed against that of an Olympic gold
> medalist?

No I am not, you are by actually putting the dreaded "it is fast" line 
in the documentation.

Development is not a fire and forget process, even more so if you go 
over some task like this one where people has tons of diverging use 
cases and expectations. I am not slapping you with a large trout for 
fun, i am just trying to show you that, if made more generic, you can 
still have your current impl and let said people with unusual needs be 
able to tweak the library from the outside to fulfill them.