Re: [boost] Re: lexical_cast

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2000-11-21 10:10:41

In message <8vdd7u+5ti9_at_[hidden]>, Daniel Frey <d.frey_at_[hidden]> writes
>> 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.

Well, I must confess that the reasons for going with copying are lost to
my memory (garbage collected or simply leaked?), and if anyone can
recall why it is by copy rather than by ref please speak now! Otherwise
I suggest that we go with the less restrictive const ref.

>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...

This was considered, but there are general re-entrancy issues as well as
threading issues, eg when an implementation of a stream operator itself
uses lexical_cast.

>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.

Yup, this would be the preferred approach. Although, that said, there is
currently no Boost policy on specialisations. [Aside: Should there be
one? Certainly, replicating the standard's policy would probably
introduce more problems than it solved.]

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  Curbralan Limited               mobile: [phone]
  mailto:kevlin_at_[hidden]     fax:    [phone]
  http://www.curbralan.com
____________________________________________________________