[boost] Re: integral_c on g++2.95.3

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-02-05 08:08:21

"Gennaro Prota" <gennaro_prota_at_[hidden]> wrote in message
news:shv14v41u7d7s69j86ausqiivg9mcpso6b_at_4ax.com...
> On Tue, 4 Feb 2003 13:03:05 -0300, "Fernando Cacciola"
> <fernando_cacciola_at_[hidden]> wrote:
>
> >Dave Abrahams wrote:
> >> On Tuesday, February 04, 2003 8:05 AM [GMT+1=CET],
> >> Joel de Guzman <djowel_at_[hidden]> wrote:
> >>
> >>> Yup, this works:
> >>>
> >>> #elif defined(__GNUC__) && (__GNUC__ < 3)
> >>>     // g++ 2.95.3 cannot take static_cast the casts,
> >>>     typedef integral_c<T, T(value + 1)> next;
> >>>     typedef integral_c<T, T(value - 1)> prior;
> >>
> >> Hey, does that one work for Borland, too?  Maybe we could get rid of
the
> >> conditionals?
> >
> >The conditionals for using 'N' instead of 'value' are still needed.
> >The c-style cast works, though.
>
> "needed" is a strong word :-) If you qualify the name:
>
>    typedef integral_c<T,  (integral_c<T, N>::value) + 1 > next;
>    typedef integral_c<T,  (integral_c<T, N>::value) - 1 > prior;
>
>
> then Borland digests it.

I see. I should have known that (John shown long that bcc required full
qualification for integral constants).

> FWIW, my opinion is that conditionals should
> be absolutely the last resort in this kind of situations and that
> library authors should first experiment by rearranging the code in a
> way that contents the maximum number of supported compilers. The
> conditionals save the author's time in the first place, but waste both
> the author's and the users' one in the long term as they complicate
> maintenance, testing and understandability of the code.
>
I agree, at least in theory; though I think John is entitled to do it
however he sees appropriate.

--
Fernando Cacciola