Re: [boost] Boost review of the Convert library is ongoing

Subject: Re: [boost] Boost review of the Convert library is ongoing
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2014-05-16 05:37:01

2014-05-16 3:42 GMT+02:00 Vladimir Batov <vb.mail.247_at_[hidden]>:

> alex <alexhighviz <at> hotmail.com> writes:String-to-type is obviously
> possible and there is quite a bit to be done
>
> > The library says it will start using tr1::optional at some stage. Why not
> > use boost::optional already now? It would make things a lot simpler and
> > clearer.
>
> Because right now boost::optional does not have all that is needed. Andrzej
> is working on extending boost::optional and I'll use it as soon as it's
> available.
>

Hi, I am a co-maintainer of boost::optional, I have already risen this
point with Vladimir, and I think his decision to stick with his own utility
for representing optional objects (rather than using boost::optional) for
the time being is the right one. Also, Vladimir's library and its use cases
reveals certain deficiencies in boost::optional:

1. Boost.Optional is not moveable.
2. Member function boost::optional<T>::get_value_or is slightly different
than that of the proposed std::tr2::optional<T>::value_or. Vladimir opts to
use the STD naming, which appears the right choice.
3. There is no getter function in boost::optional that treats the absence
of the expected contained value as an exceptional situation (but not a bug)
that causes an exception to be thrown (so that the user can choose whether
it is a bug or an exceptional situation when a value is absent). This is a
similar situation to functions at() and operator[] on std::vector. It is
solved in std::tr2::optional.

These things are addressed in tr2::optional; see here for details:
https://github.com/cplusplus/fundamentals-ts/blob/master/fundamentals-ts.pdf.
They should be fixed in boost::optional too, and I am working on them, but
in my own slow pace. boost::optional is already moveable in develop and
master branches. We are just waiting for the next Boost release. Until the
above issues with boost::optional are addressed I would recommend for
Vladimir to stick with his own implementation, so that his library does not
suffer from the coupling with boost::optional.

Regards,
&rzej