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

Fernando Cacciola wrote:

"Yuval Ronen" escribió en el mensaje

...

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 #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.

Well, I'm not sure it is that easy. Since BOOST_OPTIONAL_DISCLUDE_NONE will be compiler specific, most code will have to add the counterpart:

#ifdef BOOST_OPTIONAL_DISCLUDE_NONE #include #endif

somewhere else, otherwise none_t will be just equally undefined.

Well, I guess that it depends on how portable the code should be. If the user is writing code without much of portability requirements, then he can leave it for the Boost auto-detection configuration, which means that for most users with most compilers, none.hpp will be included at no extra work. This is something I would really like to have. Users who write code which must be very portable, can include none.hpp specifically, even without the #ifdef. The worst that can happen is that this header will be included twice on some compilers. Not a big deal IMO.

So the "complete" solution seems too contrived to me given that the only real problem here is just that the documentation is incomplete and users wanting to use "none" don't have a clue about how to do it. I believe that with a clear documentation users won't have any problem including none.hpp manually in just the right place.

This feature I asked will make my life nicer, sure, but on the other hand, not as much as world peace, so I won't make that a huge fuss of it if weren't to be implemented... ;-)

...

1. Lift none_t from detail to boost.

OK

...

2. Improve docs wrt 'none' global instance.

OK

...

3. Include none.hpp with optional unless the user/compiler dislikes it.

Not so sure ;)

Thank you for the report!

Fernando Cacciola

Thank you very much for listening! Yuval