18.01.10, 09:30, "Domagoj Saric" <dsaritz@gmail.com>:
The first problem is the ('standard') "std::streams vs efficency" issue: - on msvc 9.0 sp1 the single line boost::lexical_cast( "321" ); caused 14 calls to new and 26 calls to EnterCriticalSection() (not to mention vtable initializations, virtual function calls, usage of locales...) the first time it is called, and 3 calls to new and 15 calls to EnterCriticalSection() on subsequent calls
First of all, which boost version do you use? If it's a recent version, a conversion from char const[4] to int should not create a stringstream object, only the std::locale object. If you alsways use the "C" locale, you can eliminate a construction of that object if you define BOOST_LEXICAL_CAST_ASSUME_C_LOCALE. Can you please run your test it and report a number of calls to the new operator and the EnterCriticalSection function?
...It also caused the binary (which does not otherwise use streams) to increase by 50 kB! ...which is IMNHO abhorrent...
Since std::streams is a part of C++ std library, I'd say it's a problem of a C++ vendor. If you call lexical_cast from more than one DSO, it further increases a size by mutliple instantiations in diferent DSO. I'd personally move some functions to libboostconversion.{so,DLL} to reduce a size but I already hear complaints from header-only lovers ;-)
As a start maybe this problem could be sufficiently "lessened" by providing lexical_cast specializations/overloads that use C library functions (strtol, itoa and the likes) as they suffer less from bloat/performance issues than std::streams.
C and C++ locate are not neccessarily equal.
Ideally, IMHO, lexical_cast<> should provide the power/configurability of boost::numeric_cast (so that one can, for example, say I do not need/want to use locales/assume ASCII strings and things like that).
Flexibility of numeric_cast is a separate project. Check the review schedule.
The second problem is the use of exceptions (or better of only using exceptions): if, for example, one uses lexical_cast<> deep in the bowels of some parser it is probably "natural" to use a bad_cast exception to report an error to the outside world but if one uses lexical_cast<> to convert a string entered into a widget by a user into an int it would mostly be simpler to have a simple error code if the user entered an invalid string and issue a warning and retry "at the face of the place" (without the need for try-catch blocks)... In other words maybe a dual/hybrid approach of using both exceptions and error codes (through different overloads would be justified).
I'm afraid it's too late to change lexical_cast, it's already in the next standard. But there are two libraries in the review queue. I don't know if they give you enough flexibility, though. I hope this helps, Alex