2014-05-16 3:42 GMT+02:00 Vladimir Batov
alex
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