Boost logo

Boost :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-10-20 18:23:10

----- Original Message -----
From: "Joel de Guzman" <djowel_at_[hidden]>

> > > > > I don't know what you mean by option 3. If it causes a glorious
> > > > > loud preprocessor failure, I like that best. If it fails silently,
> > > > > am somwhat ambivalent.
> > > >
> > > > It causes a preprocessing failure (i.e. a "glorious and loud one").
> > >
> > > Then why in the world would anyone want saturation instead? That will
> > > just cover bugs.
> >
> > That is why I'm asking. The arithmetic in the library currently does
> > saturation arithmetic. At this point, Joel says "saturation for sure,"
> > you [David] say error instead. I currently have it working with
> > but I can remove the saturation an cause an error. I really don't know
> > the best course of action here is--which is why I'm asking.
> 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)


Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at