Re: [boost] Boost.Preprocessor - High-Precision Arithmetic Query

From: Joel de Guzman (djowel_at_[hidden])
Date: 2002-10-20 18:55:42

----- Original Message ----- 
From: "Paul Mensonides" <pmenso57_at_[hidden]>

> > I think David has a point. I must've missed the part that says that
> > 3 is the most efficient. In my mind, I mistakenly concluded that
> > no. 2 is the most efficient. In which case, I wouldn't mind
> > silent saturation or wraparound (which is what integers do anyway).
> 
> The efficiency difference is not signicant enough to make the decision based
> on that.  I just think that preprocessor failures are sometimes very hard to
> figure out the error.  If I use saturation, nothing will fail.  Rather, the
> number generated will likely be much higher than expected, which will be, in
> most cases, obvious during the rest of a compile.  Preprocessing failures
> have an annoying way of expanding into incomprehensibility.  I think it's
> somewhat unlikely to be an issue in most cases.  Basically, the question is,
> "should this generate a preprocessing error or not?"
> 
> #define X BOOST_PP_POSITIVE_HP(9 9 9 9 9 9 9 9 9)
> 
> BOOST_PP_MUL_HP(X, X)

Well, I think the answer should be related to the answer to
why processors do not issue a "glorious and loud error"
with this code:

    int i = some_big_number * some_big_number;

Still 2c worth. I really don't have a strong opinion on this
unless I'm tasked to code for the Arianne rocket :-)

--Joel