Re: [boost] [review] Convert library

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 
much difference.