Re: [boost] [Review] XInt Review

Subject: Re: [boost] [Review] XInt Review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-03-05 12:41:23

Marsh Ray wrote:
> 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" ?
>
> 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.

+1

> > Well, at when do you start feeling "it compiles for too
> > long" ? Template heavy code is like other code, it has to be
> > well written to be fast, and here, fast to compile.
>
> If I sit down to experiment, starting 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.

This is a legitimate concern, but don't forget the benefits that accrue to single tool solutions.  The extra effort to create and maintain a Lex/Yacc solution is a drag on productivity, too.

> I think 'willy-nilly' makes a wonderful bottom line standard
> to avoid, but a metaprogramming-heavy design still seems very
> much a matter of personal style and preference.

Indeed and it is easy to overuse it.  In part it comes from a sense of superiority as relatively few understand it well.  That's not to say there aren't real benefits from TMP.

> > Well, if XInt actually provided range based interface and an
> > extension mechanism for external big int representation, we
> > could have a good start.
>
> What would it look like? Adapters on standard
> container<integral type> concepts?

Even with such a design, there's need for an xint::integer type to make its use simple when the flexibility isn't needed.

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

Exactly.  I think xint::integer can be accepted and later layered atop what Joel describes.  Accepting XInt doesn't need to preclude the generic design.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.