Re: [Boost-Users] specializing new lexical_cast

From: Kevlin Henney (kevlin_at_[hidden])
Date: 2003-04-07 02:55:23

In message <031b01c2fc98$f1065db0$8d6c6f50_at_pc>, Terje Slettebų
<tslettebo_at_[hidden]> writes
>>From: "Tom Matelich" <tmatelich_at_[hidden]>
>
>> I'm going to embark on it, but I thought I'd ask in parallel.  One of the
>> things about Terje's proposed lexical_cast was a lot of documentation of
>how
>> to specialize it.  That doesn't seem to be addressed in 1.30.0's version.
>
>Yes, in my proposal - which then was exchanged for Kevlin's new version, the
>latter I also found better - it was possible to e.g. specialise an
>implementation class, to make it work on other types, or for handling of
>special cases, e.g. for efficiency, as you mention.
>
>However, it was found that it could be better to just make one version of
>lexical_cast which works in the general case, especially due to the lack of
>time on the end, to get such a user-defined specialisation feature reviewed,
>so there was actually no docs for this specialisation in the latest version
>of the proposal.

To further clarify, lexical_cast never had efficiency as one of its main
aims. Or to be precise, it should be no less efficient than doing the
same job with stringstream. Its primary purpose is convenience rather
than customisability -- we already have stringstreams and a host of
other features for the latter.

Having seen how it is used in practice, there is a case for some
extensibility. This is still not a main aim, but whatever approach is
taken it should be as regular as possible. The current lexical_cast
addresses asymmetries inherent in numeric and string I/O, but only for
particular types of string.

The next version of lexical_cast is likely to address generalising
string handling and may also accommodate more fine-grained
internationalisation (currently internationalisation can only be handled
via the global locale). This is something that I discussed briefly at
the ACCU conference last week with Thomas Witt, and also mentioned to
Terje.

However, at the moment, extensibility for efficiency is still not a
priority, although suitable hooks may emerge as a side effect. The case
for consistent handling of conversions in a body of code is the main
motivator, so a resolution to the strtod issue may be come out in the
wash.

>However, one can still simply overload/specialise the lexical_cast function
>template, to get the same effect, even though this is not documented. It's
>similar to being able to specialise components in the standard library. I
>think this is a simpler way of doing it than the earlier way.
[...]
>It may be a good idea to explicitly document this possibility for
>lexical_cast, so it may be relied on.

Good point. I will add it to the docs.

>> The reason I'm asking is that we did some profiling and strtod kicked
>> lexical_cast's butt for string -> double.  

I would be surprised if the result had been any different :->

Check out Herb Sutter's article comparing various general formatting
facilities, including performance:

        http://www.gotw.ca/publications/mill19.htm

Kevlin
____________________________________________________________

  Kevlin Henney                   phone:  [phone]
  mailto:kevlin_at_[hidden]     mobile: [phone]
  http://www.curbralan.com        fax:    [phone]
  Curbralan: Consultancy + Training + Development + Review
____________________________________________________________