|
Boost : |
Subject: Re: [boost] [lexical_cast] A suggestion
From: Vladimir Batov (batov_at_[hidden])
Date: 2009-02-06 17:01:26
> ... I like the lexical_cast< int >("x", -1); syntax much more.
>
> If the syntax is considered unacceptable, I can suggest another
> alternative:
>
> int x = lex_cast< int >("x").with_default(10);
> int y = lex_cast< int >("y").or_default_constructed();
The situation with the additional default parameter to lexical_cast is just
crazy. People clearly need the behavior and have been asking for it since
2005 and they still get nothing but excuses and explanations instead. In
fact, according to Kevlin's
http://lists.boost.org/Archives/boost/2005/05/85519.php post it was the
original behavior. I greatly appreciate Kevlin's contribution but
unfortunately in the current form lexical_cast is hardly useful to me (and I
suspect many others) -- throwing an exception (and having to process it) on
something as mundane as string conversion failure is, well, a bit
heavy-handed -- it results in unbelievably messy and ugly code. The second
issue (actually *first* for me) is the default-constructability.
I can understand Kevlin's reaction like "we looked at the possibilities, we
rejected them". Well, maybe it is time to have a look again. We make wrong
decisions all the time. There is nothing wrong in revisiting/re-evaluating
old decisions as we get more experience.
I sympathize with the idealistic desire for lexical_cast to look like the
dynamic_cast et al. The problem is that no matter how you make lexical_cast
look it does not do what other language-supported casts do -- dynamic_cast
el al work with *types*, lexical_cast works with *values*. Making
lexical_cast look like what it is not (the "real" casts) has no practical
value and is just misleading.
Now seemingly out of desperation people are venturing into
lexical_cast<optional>
lex_cast< int >("x").with_default(10);
lex_cast< int >("y").or_default_constructed();
It's just crazy from the usability point of view. Are you sure users will
appreciate all that mounting complexity on top of lexical_cast? All that is
needed
lexical_cast(Source const&, Target const& =Target())
or most likely a completely independent overload
lexical_cast(Source const&, Target const&)
That overload can live side-by-side with the original lexical_cast without
disturbing it... unless "lexical_cast" character sequence has been
trade-marked. I'll be first to use it.
I need scissors with two rings for fingers. The scissors' designer might
strongly insist on a variation with just one ring for one finger due to its
minimalist and beautiful design looking like something else. It has no
*practical* use for me. We can strike a compromise or I'll have to go
someplace else. That's what I understand has been happening since 2005 --
people have been simply turned away and that is wrong -- we write code for
people and want people using our code (I do). C++ is full of compromises --
compromises due to C compatibility, usability, just convenience. People love
it.
Best,
V.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk