On 19 Oct 2000, Lars Gullik Bj�nnes wrote:
> What I'd like to know is how XTL solve:
>
> string line;
> cin >> line;
> int a = stream_cast(line);
>
> or
>
> int b = stream_cast("123");
>
> I do not thing xtl is suited fot that specific task, which was the
> reason why i mentioned stream_cast in the first place.
You are right. XTL can not solve that specific task at all.
My point is exactly that you can not directly compare stream_cast and
XTL. Andre P. did that, and seemed to conclude that XTL was inferior
to stream_cast.
> stream_cast and XTL are completely different beasts, but sometimes
> they can be used for the same/similar task.
My point is that if you want to do, what XTL does, you won't find anything
better.
If you want to do something else, stream_cast might be better. It seems
you would like to use stream_cast to help parse input that is passed to
LyXFunc. That seems plausible, but please realize that stream_cast does
not do anything else than provide a nice name for a bunch of simple
converters.
In particular, it won't help you with error handling, parameter checking
and so on. XTL certainly will not, since XTL can not parse at all.
If you want to solve a parsing problem, you should go look for parsing
solutions. stream_cast is one such element in a string parsing toolchain,
but there are many others as well. In particular, stream_cast is NOT
a complete solution.
Basically, I'm just saying that XTL is a complete solution to the
problem of serializing data structures, while stream_cast is only a
small element in a solution of a bigger problem.
stream_cast can be used both for serializing, and for general parsing, but
it's not a complete solution in either case.
> | Please don't say that stream_cast is technically superior to XTL.
> | That is simply not true.
>
> Who said that?
Andre P. implied it.
> | I just thought that I would clarify things a bit.
>
> Not sure if you did.
Maybe I messed up my quoting a bit.
Greets,
Asger
