> From: Stewart, Robert [mailto:email@example.com]
> 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:
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
> 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.