[Boost-users] Re: [optional] comments about none_t

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2005-02-22 01:47:37

Jonathan Turkanis wrote:
> Yuval Ronen wrote:
> 
>>In addition to improving the docs, I'd say that it's even better to
>>include the boost/none.hpp header with optional.hpp so it could be
>>easily found and reached. As I understood, the reason why this is not
>>done now, is because some compilers (such as Borland's) have troubles
>>with initialized data and pre-compiled headers. If this is truely the
>>case, then I think it's easily solved. Include as follows:
>>
>>#ifndef BOOST_OPTIONAL_DISCLUDE_NONE
>>#include <boost/none.hpp>
>>#endif
>>
>>while the BOOST_OPTIONAL_DISCLUDE_NONE flag can be set either by the
>>user, or automatically if a troublesome compiler is detected. If
>>Boost.Config could automatically detect and set a
>>BOOST_NO_INITIALIZED_DATA flag, then the optional library is left with
>>fairly simple code.
> 
> 
> The problem is that people may write code expecting it to be portable and then
> discover that it fails to compile on some platforms. Making users include a
> separate header forces them to confront the problem earlier; in particular it
> gives them a chance to decide whether using none is worrth the cost of giving up
> precompiled headers on some platforms.

I'm not sure about that. There are plenty of places in Boost where 
certain features are suported only by some compilers because other 
compilers have problems. So it's not the only place where it's quite 
possible to write code that seems to be portable but is actually not.

The chance to decide whether to use none or precompiled headers is still 
there. It didn't go anywhere, and it's not hidden or "swept under the 
rug" in any way. I'd even say that making these users different than 
others (don't get automatic none) actually raises the issue to be even 
more visible.