Re: [boost] Re: integral_c on g++2.95.3

From: Dave Abrahams (dave_at_[hidden])
Date: 2003-02-05 17:32:39

In news:shv14v41u7d7s69j86ausqiivg9mcpso6b_at_[hidden],
Gennaro Prota <gennaro_prota_at_[hidden]> typed:

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

Nice to know.  What about all the other compilers?

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

That particular section of code, though trivial, presents different problems
for a wide variety of compilers, many of which can't be tested together on
the same machine.  In situations like that, it can be a lot safer to
explicitly say "this is the code that works for compiler X", rather than to
rearrange it for compilers X and Y, and later discover that you broke
compiler Z.  Also, you have to leave a comment in the code which says
something like "don't touch this code, because I've set up the house of
cards just right for all these compilers: ABCDE...".  Now suppose I come
along and want to support compiler Q, which chokes on that arrangement.
What am I supposed to do?

Most of us agree with the idea of finding one clean implementation; I just
wonder if it's practical in cases like this.  Oh, and BTW, programmers *did*
experiment to try and achieve that.  It proved to be extremely difficult, if
not impossible.

-- 
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com