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
>>> and dropping everything on the ground when it does isn't the nicest way
>>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk