Re: [boost] [xint] Boost.XInt formal review

Subject: Re: [boost] [xint] Boost.XInt formal review
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2011-03-07 09:08:33

Chad Nelson wrote:
> "Jeffrey Lee Hellrung, Jr." <jhellrung_at_[hidden]> wrote:
>
> > - is_odd, is_even, sign, hex_digits, is_nan: These are all
> > member functions with no same-named free function...which
> > makes me wonder why these were chosen to be member functions
> > while the likes of getbit, setbit, is_prime, etc. were
> > chosen to be strictly free functions.
>
> Because n1692, the paper presented to the C++ Standards
> Committee in 2004 that I based XInt's interface on, has them
> there. I saw no point in cluttering the interface by adding
> free functions that just call those, although if that would
> satisfy this objection, it can easily be done.

That hasn't been accepted into the standard, so it can be improved.  You might be the one to influence its improvement.

> > - pow2, factorial, nan: Same deal.  I don't see a problem
> > with making these free functions and specifying the desired
> > return value as an explicit template parameter.  It will
> > look the same but make the interface more uniform:
> >     typedef integer_t< ... > integer_type;
> >     integer_type x = integer_type::pow2(n);
> >         vs
> >     typedef integer_t< ... > integer_type;
> >     integer_type x = pow2< integer_type >(n);
>
> I could easily argue either side of that one. When I
> originally wrote that code, the current method seemed
> ever-so-slightly more appealing; now I think the way that
> you're advocating might be.

I'd rather algorithms be separate.  Even if you find that an efficiency problem, it should merely be seen as a catalyst to expand the integer_t interface to regain the lost efficiency.

> > Chad already knows my feelings on COW, but to be explicit:
> > I'm not necessarily against use of COW in general, but I
> > have yet to be given a use case where COW would outperform
> > move emulation in theory.
>
> I've located two: abs and negate. I believe those were the
> functions that originally prompted me to use it. I'm sorry
> that I didn't mention them before; I knew I had a reason for
> going to all the trouble of using it, but I didn't recall what
> that reason was until I saw those while working with the code
> today.
>
> Both involve changes to the sign bit only, and one only
> sometimes needs to alter it. It would be foolish to deep-copy
> a ten-thousand-bit or larger number just to flip the sign
> bit. Even worse, not to do anything to it at all, in the case
> of abs and already-positive numbers.

You can do the same, I should think, without COW.  All you need is to make your algorithms less naive.  The algorithms can manage the sign in a separate variable and refer to an existing magnitude or make a copy, as needed, unless I'm much mistaken.  That is a little less convenient, but should obviate COW.

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