Subject: Re: [boost] [review] Convert library
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2014-05-26 02:02:44
On 26/05/2014 15:34, quoth Vladimir Batov:
> Thank you for the Boost.Filesystem and Boost.Asio pointers.
> Unfortunately, I am not familiar with the libs. If they indeed handle
> deployment cases similar to those I've been moaning about, then it might
> be wise to postpone going any further with "convert" and study those
> libs for already-existing/established solutions... without
> "optional"-generated controversy... Maybe someone else could shed more
> light on that?...
The behaviour being referred to is that most methods come with two
overloads: one that accepts a non-const reference to
boost::system::error_code (traditionally boost::system::error_code& ec);
this form is guaranteed to return errors via the output parameter
instead of throwing. The other overload does not have this parameter,
and can throw exceptions -- typically as boost::system::system_error(ec)
from an internal call to the other overload.
Given that Boost.System is in similar standards flux to boost::optional
AFAIK, I'm not sure that this necessarily helps.
Personally, I think that optional returns are probably more practically
useful; while there are times when it might be nice to differentiate
between types of conversion failure (eg. unexpected character, not valid
in this locale, too large, etc), in practice it doesn't usually make
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk