On Tuesday, May 03, 2011 10:33:50 AM Vladimir Batov wrote:
"Gordon Woodhull" <gordon@woodhull.com> wrote in message news:<7A4B6296-A86F-4BF9-ACE5-525B4052EE26@woodhull.com>...
Note that performance concerns are out of scope of Boost.Convert.
Why?
Because the author chose not to address them. It's not a more efficient alternative. It's just a more powerful (if wacky) interface.
I'm certainly not saying that it's not an important concern! Performance is the main reason I don't use lexical_cast more.
Gordon,
Thank you for trying reading my mind. In this instance, I suspect, you read it wrong though. ;-) Indeed, I did not address the performance as IMHO that's an implementation detail which needs to come next -- after API/functionality has been settled on. Although I did provide a half-hearted example how to go about optimizing with string-to-bool when the time comes.
If we decide to go ahead building/extending a set of converters (based on this lib. or any other lib), then I'd probably favor the user choosing which converter he/she wants by specifying
#include <boost/convert/string-to-bool-fast.hpp> or #include <boost/convert/string-to-int-spirit.hpp>
Something along these lines. That way stream-based converters would co-exist with some quick ones. Just a thought.
Wouldn't it be very tedious to incorporate the locales and formaters when using these optimizations? Have you really thought this through? Wouldn't it render all the "nice" operator overloading tricks useless? Again you claim your library to be extendable while it's not really. You have all those nice features so that you can easily use std locales and formatters (But i suspect these only work well with stdlib like streams). Once you incorporate any custom non stream based converter, all bets are off. Did I miss something obvious here?