Re: [boost] [review] Convert library

On 05/26/2014 12:24 AM, Jeroen Habraken wrote:

On 25 May 2014 14:03, Vladimir Batov wrote:

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.

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.