In [EMAIL PROTECTED]">news:[EMAIL PROTECTED], Gennaro Prota <[EMAIL PROTECTED]> 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
