On 25 May 2014 14:03, Vladimir Batov
Jeroen, Thank you for your input. My apologies for snipping (a lot) -- I want to focus on the immediate. If we clear this one up, we'll get to the rest next. If we do not clear this one up, we won't get to the rest. :-)
You're more than welcome, you may have snipped a little too much but I'll get to that below.
...
as other have argued boost::lexical_cast is used without the try-catch in a lot of places. Simply expecting it not to
Jeroen Habraken wrote throw
and dropping everything on the ground when it does isn't the nicest way to go about things but it does get things done.
Jeroen, seriously, we are serious people writing serious s/w. Should we be discussing children playing with matches here? :-)
Unfortunately I believe we should, whilst we might be writing serious software there are enough who aren't -- you'd be surprised how often people are using boost::lexical_cast without the try - catch at the place I currently work. Again, unfortunately.
I guess the question is whether we should make it harder to use the library in such a way, and I think we shouldn't.
It is the wrong angle IMO. First, we should make it work properly. Then we make it as simple to use as possible within the constraints imposed by the first point.
Agreed.
Note that for this to be efficient I'd like to see the optional to be movable, which isn't yet the case with boost::optional if I'm not mistaken.
You might have noticed that I mention std::tr2::optional... which has what you are after. Andrzej is working on incorporating/backporting those features to boost::optional. "Life happened" to him also :-) but I am hoping, if we are extra nice, he might just might to get the interface we are after into 1.56. Andrzej, ple-e-e-ease, pretty pretty please!?
Wonderful, I'd love to see that make it into 1.56.0.
I'm slowly warming up to the optional-based interface as it eliminates the throwing / non-throwing interface discussion, which is a good thing. Once again two comments, first of which is what's going to happen until the std::optional (whether in TR2 or elsewhere) is widely accepted. The optional provided by boost has a slightly different interface and isn't movable.
It is
std::tr2::optional<TypeOut> convert(TypeIn const&, Converter const&);
you are warming up to, right? If it is so, I am really glad to hear that. I am not married to it but all things considered it seems the most generic and flexible, functionally-complete, not too verbose... and sufficiently close to lexical_cast :-) for people not to feel alienated.
Given the immense variability of conversion-related deployments I see this interface as the only one that everyone can deploy -- exceptions? no problem; delayed exceptions? easy; no exceptions but failure-condition returned instead? piece of cake; can't be bothered processing the failure-condition and wanna proceed with the default? coming right up; want to process failure but still go with the default? anything to keep the user happy!
So far, no one (to my knowledge) has come up with another interface which simpler without sacrificing those mentioned important qualities (given we are talking about a library-grade interface).
Close, I'd like an overload without the Converter const & as well, defaulting to a converter chosen via a customisation point. This is what I believe you've unintentionally snipped, and I'm curious as to your opinion on it as I believe it to be a crucial part of the interface.
The second is performance, with boost::coerce a lot of time was invested to prevent the interface from slowing down the conversion itself. I simply don't know how this interface will behave in that regard, when I have more time I'll try some benchmarking.
Ah, that should not be a problem. I don't think. I actually expect the convert() interface to be wiped out altogether when optimized. That is, all power to you, the converter writer. So, what do you say? Are we in business?.. So to speak? :-)
We're getting there. Jeroen