Re: [boost] Another set of macros to deprecate (and then remove)?

Subject: Re: [boost] Another set of macros to deprecate (and then remove)?
From: Nathan Ridge (zeratul976_at_[hidden])
Date: 2012-12-17 01:00:35

> > Here's my understanding, based on reading the docs at:
> > http://www.boost.org/doc/libs/1_52_0/libs/config/doc/html/boost_config/boo
> > st_macro_reference.html
> >
> >
> > For things that are in the standard, we note their absence.
> > For example: BOOST_NO_STDC_NAMESPACE and BOOST_NO_CXX11_RVALUE_REFERENCES
> >
> > For optional (extra?) language/library features, we note their presence
> > BOOST_HAS_TR1 or BOOST_HAS_SGI_TYPE_TRAITS
>
> Thanks. This proves that the choice is deliberate.
>
> However, it doesn't answer whether using the double-negative is a good idea.
> Why not use BOOST_STDC_NAMESPACE and BOOST_CXX11_RVALUE_REFERENCES instead?

I think the idea is that the "normal" state of affairs (in this case 
meaning the latest language standard being fully supported) involves 
no config macros being defined, and the more "abnormal" the state of 
affairs gets (e.g.language feature not supported, compiler has a bug, 
etc.) the more config macros have to be defined.

I'm not sure what the underlying reason for that is, but I'll venture 
a guess: perhaps the hope is that as time goes by and support for older
compilers is dropped, there will be language features that work with
all supported compilers, compiler bugs that no longer affect any 
supported compilers, etc., and the config library can then simply 
"forget" about those features and bugs as it forgets about older 
(unsupported) compilers. Otherwise as time goes by and more language 
standards are made, the config library would keep accumulating 
knowledge about how to detect support for various language features, 
but most of that knowledge would be unnecessary.

Perhaps the config library authors can confirm whether my speculation 
about the rationale is correct.

Regards,
Nate