Boost logo

Boost :

Subject: Re: [boost] [conversion] try_lexical_cast and 200$
From: Rob Stewart (robertstewart_at_[hidden])
Date: 2013-12-12 18:29:08


On Dec 12, 2013, at 12:41 AM, "Peter Dimov" <lists_at_[hidden]> wrote:

> Antony Polukhin wrote:
>> * `try_lexical_cast` must be added or not?
>
> The motivation given is convincing.
>
> "At Facebook we've seen many instances of programs that call lexical_cast in a try/catch. In cases where the parsing is expected to fail (eg, an argument could be an int or a date) we frequently see extremely poor performance in multithreading. GCC is known to have poor multithreaded exception handling gcc.gnu.org/ml/gcc/2013-05/msg00253.html"
>
> Even without the performance argument, seeing repeated occurrences of calling a function in a try block is a strong hint that the function perhaps ought to not report the error via an exception.

That's a reasonable justification for the desired functionality.

>> And if yes, what signature is preffered:
>>
>> bool try_lexical_cast<Out, In>(Out&, const In&)
>> bool try_lexical_cast<Out, In>(const In&, Out&)
>> boost::optional<Out> try_lexical_cast<Out, In>(const In&)

If it's to be a cast, optional is not unreasonable, but it is a bit awkward.

> bool try_lexical_cast<In, Out>(const In&, Out&), I'd say.

I prefer output parameters to be first. It allows flexibility in adding arguments and even defaulting some. (As noted elsewhere, the template parameter order is wrong.)

As others have noted, this function is no longer cast-style, so "cast" ought not to be part of the name.

___
Rob

(Sent from my portable computation engine)


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk