RE: [boost] Proposal for lexical_cast/lexical_convert

From: Stewart, Robert (stewart_at_[hidden])
Date: 2002-01-25 08:35:30

From:	Björn Karlsson [SMTP:bjorn.karlsson_at_[hidden]]
> 
> There are two main reasons why lexical_cast isn't always a perfect fit (as
I see it): 
> 0) In code that doesn't otherwise use exceptions, the error handling can
become
> awkward/messy/inconsistent when using lexical_cast.

That fits embedded programming, certainly.

> 1) When a failed conversion is not considered an error, the exception
handling stands
> in the way of code clarity. 

Absolutely.  It forces exception handling to be the normal control flow.

> I seem to recall an earlier proposal for a lexical_cast, something like 
> "template<typename Target, typename Source> bool
> lexical_cast(Source arg, Target* result)", but obviously, that doesn't
> look like a cast anymore.
> 
> It's still useful though, so why don't we give it another name? 
> I think lexical_convert states the meaning quite clearly: 

It's a reasonable name.

> template<typename Target, typename Source> bool
> lexical_convert(Source arg, Target* result) 
[snip implementation]
> Passing the target by pointer or reference is a tough call - the intention
is
> made clear by using a pointer, but that allows for code like:
> int* p; boost::lexical_convert<int>(s, p);. On the other hand, passing by
> reference solves the problem but makes the code less clear. I hesitate to
> claim that one version is better than the other, so I'll leave it at that
and
> a test for !result (in the end, I think this one boils down to personal
> preference).

I use pointer parameters to indicate optional arguments, so it means the
wrong thing to me.  As you said, it leaves the door open for misuse.  I
don't think there will be room for confusion since it will be a standard
function; either you know what lexical_convert() does, or you don't.
Therefore, I think the parameter should be a non-const reference.

Presuming there's consensus on that, I still have a problem with the
signature.  My convention is to always put output parameters first in the
parameter list.  Output parameters won't be defaulted, but a function that
has defaulted parameters won't work unless they follow output parameters.
This doesn't come up all that often, but I find it better to always put
output parameters first, leaving the opportunity for defaulted parameters to
follow.  Obviously, changing the parameter order doesn't leave you with that
nice source then target flow, but then there are many standard functions for
which the order is target then source.

> There's not much code, so duplication probably doesn't matter, but the
> throwing lexical_cast could obviously be implemented in terms of
> lexical_convert:

It's not really a matter of the amount of code.  It's that any correction
that may become necessary would have to be duplicated.  lexical_cast()
should certainly be implemented in terms of lexical_convert().

> An open issue would be where the stuff should go - lexical_cast.hpp is
> very specific, but maybe the right place anyway? 

Creating lexical_convert.hpp isn't a big deal; lexical_cast.hpp can just
include it.  However, some client code may want both, so how about just
putting both in lexical.hpp?

Rob
Susquehanna International Group, LLP
http://www.sig.com