Re: lexical_cast

From: Daniel Frey (d.frey_at_[hidden])
Date: 2000-11-21 03:54:22

--- In boost_at_[hidden], Kevlin Henney <kevlin_at_c...> wrote:
> In message <8vasrt+at8h_at_e...>, d.frey_at_g... writes
> >1) Why does lexical_cast requires the Source to be
> >Copy-Constructable? Why is lexical_cast's argument defined as
> >'Source arg' instead of 'const Source& arg'?
> 
> This follows from the style of other cast functions. However, it is
> a point of style that we might wish to revisit, which would in turn
> weaken the requirement.

I don't know how these issues are handled here, but I'd prefer the
'const Source& arg'-style.

> >2) I was a bit worried about performance. A small test showed that
> >when converting 'int' to 'string' (IMHO a very common case),
> >lexical_cast was about 18 times slower than a 'native' function. 

> The performance is, in this case, the price you pay for generality.
> Use of the I/O streams library raises the cost for the simple
> satisfaction of common interface requirements.

And for the safety and ease of use I'm willing to pay a price. But I
was wondering if we could speed it up without any drawbacks. I was
thinking of makeing the stream static, so that initialization costs
can be reduced, you just have to reset it before calling it. But this
would be a problem for multi-threading and it creates long-time
objects which I personally don't like very much. But maybe you (or
someone else) have a better idea...

> However, I have not found that I have been using lexical_cast in
> such contexts.

When writing an application that parses and executes user-supplied
strings, calculates on these data and an additional database and
finally generating HTML-pages from within C++, and trying to have both
a good latency and throughput, you'll use it a billion times if it's
fast enough :) Specialization is of course an option here, while
keeping the nice syntax. I'll therefore start using it and when the
profiler shows, that it takes up too much time, I'll write special
versions for my most common cases.

Regards, Daniel