Re: [boost] [lexical_cast] efficiency

Subject: Re: [boost] [lexical_cast] efficiency
From: Alexander Nasonov (alnsn_at_[hidden])
Date: 2010-01-18 09:37:33

18.01.10, 09:30, "Domagoj Saric" <dsaritz_at_[hidden]>:
> 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