Re: [boost] [review] Convert library

Subject: Re: [boost] [review] Convert library
From: Vladimir Batov (Vladimir.Batov_at_[hidden])
Date: 2014-05-25 22:36:59

On 05/26/2014 12:24 AM, Jeroen Habraken wrote:
> On 25 May 2014 14:03, Vladimir Batov <vb.mail.247_at_[hidden]> wrote:
>
> You're more than welcome, you may have snipped a little too much but 
> I'll get to that below.
>> Jeroen Habraken wrote
>>> ...
>>>
>>> as other have argued boost::lexical_cast is used
>>> without the try-catch in a lot of places. Simply expecting it not to
>> 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.

Sorry, I just can't resist picturing that we are developing domestic gas 
stoves... Whilst we might be developing/manufacturing essential 
appliance for food-preparation purposes we should be considerate of 
those who'll be sticking their heads in and blowing their houses up 
using our appliances. Uhm, I do not think so.  :-)

That said, if you have an interface that keeps me (ordinary user) happy 
and works for those thrill-seekers by blowing their heads off... and the 
community is happy... I am happy... Let's adapt it...

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

Sure thing. Currently "convert" has two overloads. Can you write all 
overloads that you are proposing? With defaults and stuff. I suspect 
some might not survive simply because their signatures clash.

As for "defaulting to a converter chosen via a customization point", so 
far I am OK with it... unless we hit some unexpected implementation 
issue. I only remember Andrzej's "no globals" view. A global would have 
to be thread-safe and all.