Re: [boost] Re: [Config] Testing instructions for compiler vendors

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2002-12-12 19:21:11

----- Original Message -----
From: "David Abrahams" <dave_at_[hidden]>

> Errors are not a good response here, unless of course that's done
> purely as an option.

I was under the impression that causing errors and/or warnings was so
developers could be "reminded" of some type of hack for some compiler.  The
macro could be conditionally be defined based on whether or not you want
those notifications.  Issuing a warning or error on a user's system is
pointless (IMHO) unless a new release no longer supports the "hack."  In
which case, they'd get compile-time errors anyway.

> What's that going to do?  Nobody implements that #pragma, and only
> some compilers will warn about unknown pragmas. Right?

It seems like a common QI extension to me.  Either way, my point was that
you can do things to make something noticeable to the developer yet
invisible to a user based on compiler versioning.  As far as that is
concerned, the "division by zero" example is the best IMO, because it
doesn't really matter if it errors or just generates a warning--just so long
as something happens that makes it noticeable.

> Anyway, it's too much typing, IMO, and too easy to get wrong.

Yeah.

> > Actually, given a known set of symbols (such as the ones used in
config.hpp)
> > you don't need to separate the test from the symbol:
> >
> > BOOST_WORKAROUND(__SUNPRO_CC <= 0x530)
> >                          // ^ no comma
> >
> > As long as the symbols used are known, it is no problem to pull the
symbol
> > off the beginning (or end) of the expression.
>
> Yeah... I think I'd rather not do that.  The version with the comma
> works with any symbol and doesn't incur the kinds of maintenance costs
> associated with that approach.

I agree that it would be a neat trick for no good reason.  (The maintenance
would be easy though, it is simple to detect whether or not the symbol
passed is a "known" name or not, and issuing an error is easy if it is "in
the macro expansion" rather than in the expression.)  ...But this was just
for amusement anyway. ;)

Paul Mensonides