>  I've seen that boost has currently BOOST_NO_STRINGSTREAM; why isn't
>  there a BOOST_NO_NEW_IOSTREAMS macro instead?

Good question, no ones asked for it (until now!).

>  Moreover, I find the section 'Macros that describe defects' in
> 
>  http://www.boost.org/libs/config/config.htm
> 
> 
>  misleading because it describes the BOOST_NO_xxx macros as "the
>  implementation lacks the feature xxx".
>  As far as I've seen by working at dynamic_bitset this is not true in
>  general: for instance some of the compilers I've tried had problems
>  with member template friends (BOOST_NO_MEMBER_TEMPLATE_FRIENDS), but
>  only in some circumstances and, often, not for the syntax of the
>  declaration per se. So I would like the description to say that boost
>  renounces the usage of the feature xxx, for the reason that the
>  configured compiler has problems 'related' to that feature, not that
>  the feature isn't supported at all. In practice this means that one
>  has to intend the macros as
> 
>  BOOST_DOESNT_USE_featurexxx
> 
>  It's only a different point of view and it affects the documentation
>  only but I think it's important anyway. It also avoid us to make
>  incorrect assertions about compiler bugs (we only say that there are
>  bugs associated with a certain feature, and that therefore the code of
>  the library takes them into account - in practice, it doesn't use the
>  feature, but that in theory is not the only option).

Yes, that's what we mean.  The problem is that the descriptions are pretty
thin for some of the macros, but I probably should add a global caveat to
the docs to make it clear that we are testing for particular failures,
rather than a feature that is completely missing.  I guess ultimately it is
the test cases that are the real docs:-)

John Maddock
http://ourworld.compuserve.com/homepages/john_maddock/index.htm


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost