Sorry for not writing for a long time, totally forgot about this thread. 2011/11/23 Matthew Chambers <matt.chambers42@gmail.com>:
I too would like to see optimized conversions work on string ranges; what's the point in doing a fast conversion if you have to do a string copy first? :)
There are a lot of libraries, that can have tuned conversions for lexical_cast. The bad thing, is that lexical_cast can be customized ONLY via overloading operator>>(stream&) and operator<<(stream&), and that is not very fast. That is the design. As simple, as possible. Multiple customization points will make the design obfuscated. It would be also a bad idea, to include a lot of different library headers to lexical_cast.hpp (will increase compilation times, add unnecessary dependencies...) 2011/11/24 Matthew Chambers <matt.chambers42@gmail.com>:
On 11/23/2011 11:55 AM, Olaf van der Spek wrote:
On Wed, Nov 23, 2011 at 5:55 PM, Matthew Chambers wrote:
On Oct 13, 2011 Michel Morin wrote:
- Assuming it is safe to use `std::atoi`, `std::atoi(&iter_rng.front())` is faster than both of the above two methods.
Is front() guaranteed to return a 0-terminated string?
Certainly not. I consider that caveat to be part of the "assuming it is safe" precondition.
If you assume, that it is safe to use &iter_rng.front() (extremely unsafe!), you can add overload for lexical_cast to the iterators_range_io.hpp. Something like this: template <class OutT> OutT lexical_cast(const iterator_range<char>& iter_rng) { return lexical_cast<OutT>(&iter_rng.front()); } Then it will benefit from all the char* optimizations. 2011/11/28 Matthew Chambers <matt.chambers42@gmail.com>:
Finally, I got lexical_cast down to its best performance with BOOST_LEXICAL_CAST_ASSUME_C_LOCALE (again using MSVC 10). There is some kind of optimization going on with the iterator_range->string branch, so let's ignore that. I added a sscanf line for better comparison with http://www.boost.org/doc/libs/1_48_0/doc/html/boost_lexical_cast/performance...
Thanks for that info. It looks like std::locale class has a totally different implementation under VC. I`ll take care of that and tune lexical_cast implementation for VC.
Still we see that lexical_cast is quite slow for string->float (at least on MSVC 10) which doesn't match the GCC results on the performance.html page and it's abysmal for converting iterator_ranges.
Not string->float. You are using string->double conversion. Under VC it is not tuned, because a tuned version is not exactly precise. And trading accuracy for speed is a questionable solution. By the way, last time I was looking through the Spirit implementation, it was fast, but not perfectly accurate (incorrect values in 18-20th sign after dot)
I'm hoping Antony Polukhin will chime in and say how hard it would be to add iterator_range specializations and redirect the existing string->T specializations to forward to the iterator_range ones. I don't understand the TMP in the new lexical_cast. Also, [Antony] please add something like:
Optimizations for iterator ranges will not be added in nearest releases.
"Tests were compiled with BOOST_LEXICAL_CAST_ASSUME_C_LOCALE defined for optimum performance." to the test description on the performance.html page?
They were compiled without BOOST_LEXICAL_CAST_ASSUME_C_LOCALE. Differences between GCCs and VCs implementations of std::locale are huge. I`ll optimize lexical_cast for VC soon. Best regards, Antony Polukhin