Boost logo

Boost :

Subject: Re: [boost] [lexical cast] Performance improvements
From: Vicente BOTET (vicente.botet_at_[hidden])
Date: 2011-04-04 17:59:24


> Message du 19/03/11 21:57
> De : "Antony Polukhin"
> A : boost_at_[hidden]
> Copie à :
> Objet : [boost] [lexical cast] Performance improvements
>
> Working with Boost Lexical Cast library found that some casts are
> working really slow.
> For example, cast from short to int is done via cast from short to char[],
> and cast from char[] to int.
> Cast from char* to string is done via string() constructor call and string`s
> append function call (instead of string constructor call with char array as a
> parameter).
>
> So I wrote patch to Boost Lexical Cast library, that returns Target directly
> constructed from Source in cases, when:
> 1) Source and Target are arithmetics (and not char or wchar_t), and
> all values of
> Source are in range of Target
> 2) Source and Target are both char or both wchar_t
> 3) Source is array of CharT and Target is std::basic_string
> 4) Source and Target are std::basic_string with same template parameters
>
> It gives performance boost more than 10 times in case 1) , about 7
> times in case 2),
> and about 1.5 times in cases 3) and 4).

Hi,

I don't know if you are aware of Boost.Conversion on the review schedule.

This library provide a framework to specialize conversions from unrelated types much on the line you are proposing. The library provides a default conversion that uses the explicit constructor or conversion operator. In addition the library provides already a certain number of conversions between unrelated standard or boost types.

I have in my TODO list the creation of specializations for types convertible using numeric_cast and lexical_cast, but they are not yet there. I need to see how to specialize the generic behavior when these operators are applicable, the main issue is that I want to make preference to the current conversion when available Target(source), but there is no way to check for this trait without compiler support.

The main advantage of the library is that all the conversions will use the same prototype.

convert_to(Source const&);

1) Source and Target are arithmetics (and not char or wchar_t), and all values of Source are in range of Target

The default current behavior will not manage with bound checking, but the user or the library could add specialization for the builtin that uses numeric_cast.

2) Source and Target are both char or both wchar_t

This is the identity, isn't it? The default behavior works then in this case.

3) Source is array of CharT and Target is std::basic_string

This could be added easily in an extrinsic way (either by the user or as a specialization by the library).

4) Source and Target are std::basic_string with same template parameters

This is the identity, isn't it?

I think that it is better to improve my library that is there to manage with any conversion, and let lexical cast do what it did originally.

Let me know what do you think.

Best,
Vicente


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk