RE: [boost] Proposal for lexical_cast/lexical_convert

From: Björn Karlsson (bjorn.karlsson_at_[hidden])
Date: 2002-01-25 09:48:30

> From: Stewart, Robert [mailto:stewart_at_[hidden]]
> 
> 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.
> 

Interesting! Another popular practice regarding pointers vs. references, and
the one I usually follow is that pointers -> the argument will be changed,
references -> nope, const references -> a means to 1) avoid copying overhead
and 2) const correctness. (In no way do I mean to imply that this is _The
Way_.)
I agree that the potential misuse argument is a good one, but I think it
competes width the fact that a reference would shroud the intention and
"logic type safety". 
Consider what happens with a reference version:

std::string source="11";
int target=17;
boost::lexical_convert(source, target); // If I don't know the correct
order, the compiler still assumes I do.
boost::lexical_convert(target, source); // If I don't know the correct
order, the compiler still assumes I do.

> 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.
> 

This is another case of the "opposing best practices problem" :-). 

> > 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().
>

Agreed. If they end up in different headers, the maintenance cost may be
justified by the reduced dependency. On the other hand, they'll be destined
to evolve together, so I think you're right.
 
> > 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?
> 

Sounds good to me (lexical_convert.hpp). Or, lexical_cast.hpp could include
lexical_convert. Or, they could be moved to lexical.hpp, conversion.hpp or
lexical_conversion.hpp. Argh. I dunno.
 
Anyway, I think a strong reason for not touching the name of
lexical_cast.hpp is to avoid breaking existing code.

Bjorn