----- Original Message -----From: Bjorn KarlssonSent: Saturday, January 26, 2002 11:34 AMSubject: RE: [boost] Re: Proposal for lexical_cast/lexical_convert> From: Fernando Cacciola [mailto:fcacciola@gosierra.com]
>
> I though about this. Perhaps I didn't understand the intended
> usage for
> this.
> Is it 'just' to avoid exceptions to be thrown in case of
> error?, or is it
> intended to be used in
> contexts when failure isn't critical and you can ignore it,
> in which case a
> default Target() is ok as long as a boolean flag is also returned
> I figured that the usefulness resided in the second case, not
> the first.
>
> IOWs, I figured that the idea was to have a conversion that
> always returns
> something, but signaling if it is what was expected.
> Had I misunderstood the idea?
> If the conversion is supposed to return 'nothing' in case of
> error, then the
> original interface is better.
> If the conversion is supposed to return something, whether
> the expected
> thing or not, I recommend my interface.
>The thing is, if the operation fails, there's no guarantee of the usefulness of what's returned.
The intent is 0) no exceptions thrown, 1) client selects what consitutes an error and 2) looks *almost* like lexical_cast.
Rationale:
0) Exceptions aren't always possible to use, either by convention or by lack of exception support.
1) If a conversion isn't an error, exception handling is not only unnecessary, it also makes the code less clear.
2) lexical_cast is elegant, functional, useful and well-proven, so lexical_convert should be similar.This intent is also achieved in your proposed signature, but IMHO optional return codes are invitations to poor programming practice. By returning the result of the operation the user still has the possibility to discard the return value, but at least they'll know they're pushing their luck :-) (or clarifying that the operation cannot fail, but that argument holds equally well for both signatures).
Does that make sense?
Bjorn