Re: [boost] [conversion] try_lexical_cast and 200$

Subject: Re: [boost] [conversion] try_lexical_cast and 200$
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-12-12 01:34:07

On 12/12/2013 18:41, Quoth Peter Dimov:
> "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"

+1

>> 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&)
>
> bool try_lexical_cast<In, Out>(const In&, Out&), I'd say.

+1

> optional<> is cute because you can use if( auto x =
> try_lexical_cast<Out>(in) ), but not very convenient for the common
> case of try_lexical_cast(in1, out1) && try_lexical_cast(in2, out2).

Optional would work in that case too, eg:

   if ((out1 = try_lexical_cast<T1, U1>(in1))
    && (out2 = try_lexical_cast<T2, U2>(in2)))
   {
      // both casts worked, do something with out1 and out2
   }
   else
   {
      // at least one failed, can inspect to determine which
   }

Having said that, I would probably look funny at anyone who wrote that 
code for real, since inline assignments tend to confuse people and are 
often accidental.

Also having to specify both types is more annoying than in the bool 
form, where the compiler can infer the parameters.

(I'm not really a fan of output parameters either, but c'est la vie.)

On the other hand, if it's not going to resemble "result = 
name<T>(source)" then it's not very cast-like, so the name seems a 
little odd now.  But not enough to bother me much. :)