Kevlin Henney wrote:
> In article <[EMAIL PROTECTED]>, Vladimir Prus
> <[EMAIL PROTECTED]> writes
>
> >The principle of least astonishment can be applied in a different way. We
> >all know that lexical cast uses streams, and
> >
> > stringstream ss(" 1 ");
> > int i;
> > ss >> i;
> > cout << i << "\n";
> >
> >certainly works. It's surprising that lexical_cast<int>(" 1 ") does not
> >work.
>
> This is argument by false analogy. If the above were to fail, eg "a" was
> the initialiser, it won't throw an exception.
Unfortunately, I don't understand what you mean. What's the "above" and what's
"it"?
> Yes, there is an
> underlying stringstream, but lexical_cast uses stringstream; it is not
> stringstream. The current model ensures that, unlike I/O streams, input
> and output are treated more symmetrically and various constraints, such
> as the full conversion of a buffered representation, are strongly
> enforced.
Hm, where the "current model" comes from? The version in CVS was added during
1.30 preparation and it was expected to fix some known problems with the
previous version. You now say about "current model" which emerged, and
I don't see *anything* in docs about it. The docs, actually, don't say how
spaces are handled, or that any changes were made to this part and that all
input should be consumed.
> A quick inspection of its history reveals a move away from the looser
> I/O stream model of conversion. The original design was softer and more
> script-like in its tolerances, but the general needs that most users had
> were stricter.
I've some problems with this reasoning:
1. I never seen posts which asked for this change of semantic and
I'm not sure it's good in practice.
2. As I say in other post
(http://article.gmane.org/gmane.comp.lib.boost.devel/19133), the
change breaks conversions to user-defined classes.
> If you want the kind of behaviour described above, I suggest using --
> wait for it -- std::stringstream,
Using std::stringstream is not that convenient, for the reasons described
in lexical_cast docs.
> or writing a trim function that cuts
> leading and trailing space characters.
This would help in string->something conversion case, though I don't like
extra efforts.
> >BTW, I cannot find the test case for trailing space in
> >lexical_case_test.cpp, and... the following works with gcc 3.2:
...
> Thanks for spotting this. That is missing, and the accommodation of that
> behaviour is legacy -- it is incompatible with the idea that full
> conversion only is supported, and the way that textual types are
> handled.
I can say only that I'd be -1 on the change, because I don't see the practical
need to it.
> >Alas, it's not very helpfull as a debugging tool as it is.
>
> No, and that's because it is not primarily intended to be a debugging
> tool. The only resolution I can see that accommodates this in part,
> without running foul of reasonable constraints on exception types, is to
> use a fixed-size char array that truncates the residual buffer content
> if necessary.
Hmm... why is this complexity is needed? Can't you just have an
shared_ptr<std::string> member in exception class, which the entire
'what' message. Yes, the required memory is unbounded, but copy
ctor will never throw an exception.
- Volodya
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
