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.