...

From: "Tom Matelich"

...

I'm going to embark on it, but I thought I'd ask in parallel. One of

"Terje Slettebø" wrote in message news:031b01c2fc98$f1065db0$8d6c6f50@pc... 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.

<snip>

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.

For example:

#include

namespace boost { template<> double lexical_cast<double>(const std::string &source) { // ... } }

This barfs under my compiler (BCB4/Win32), since you can't specialize a function template. From what little investigation I've done so far, it seems that the best place to do this specialization is in the boost::detail::lexical_stream class, such as the specialization already done for extracting a std::string from the lexical_stream. -- Corey Murtagh The Electric Monk "Quidquid latine dictum sit, altum viditur!"

In message <031b01c2fc98$f1065db0$8d6c6f50@pc>, Terje Slettebø writes

...

From: "Tom Matelich"

...

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: +44 117 942 2990 mailto:kevlin@curbralan.com mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________