ian whittley wrote:

...

...

int to(std::string const& arg, Type2Type<int> const&) { return atoi(arg.c_str()); }

This won't reflect the global C++ locale.

heh - i'm afraid i don't understand what you mean by that :) is it possible to rectify said problem as it would be nice to have a generic way of handling conversions without the overhead of having to use stringstreams all of the time.

What's being said is that your example using atoi is not generic - it will behave incorrectly for some other languages - atoi only handles the (latin? not a translations expert) characters 0-9, and won't be able to convert languages which use different characters for their numbers (further, it's got no error detecting, so it won't throw a boost::bad_lexical_cast when the string isn't convertable into the destination type). Making this truely generic - that is, so that it will work with C++ locales - is easiest done with stringstreams. You might be able to make some micro-optimizations by directly using locales, but most projects don't have their main bottleneck in converting to/from strings. That is, most developers have no incentive to add such micro-optimizations in. The fact that your optimizer probably eliminates a lot (most? all?) of the overhead that's possible to eliminate when using locales means there's even less incentive. Finally, if one truely does have their worst bottleneck as this conversion area, they're probably better off using a project-tailored solution which can make assumptions for optimization purpouses (e.g. atoi can be used if you're only going to be dealing with 0-9 for digits and don't need error handling).

Delfin Rojas wrote:

...

-----Original Message----- On Behalf Of Jonathan Turkanis ian whittley wrote:

...

int to(std::string const& arg, Type2Type<int> const&) { return atoi(arg.c_str()); }

This won't reflect the global C++ locale.

Please forgive my ignorance if I'm wrong but I thought the C++ locale underneath calls ::setlocale to set the global C locale and then ::atoi uses the LC_NUMERIC category of the current C locale so everything should be fine locale-wise. In fact I thought the conversion through std::stringstream ends up using std::num_get which ends up using ::strtoul.

The global C++ locale can contain user-defined facets, so the C locale cannot always be made to match the C++ locale.

On the other hand, can boost::lexical_cast accept a hex string and correctly convert it to its numeric representation? If so the ::atoi shortcut would not work...

Jonathan

-delfin

Is this library freely available? It also sounds like a good addition to boost itself... -delfin

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Martin Sent: Friday, June 03, 2005 4:22 AM To: boost-users@lists.boost.org Subject: [Boost-users] Re: lexical_cast

I have a library which allows you to do all kind of conversions like

to_string<string>(1234); to_string<wstring>(1234, &hex); to_string >(10.25, make_tuple(&fixed, setprecision(1), setw (10))); to_string<string>(1234, locale::classic()); to_string_classic<wstring>(1234); // same as above but with non-stream specializations for int (planning to add double)

from_string<int>(str); from_string<double>(str, -5); // return -5 on error from_string<double>(str, &hex); from_string<int>(str, &noskipws, std::locale("German"), 0); from_string_classic<int>(str);

If you have many conversions you can increase preformance by reusing the stream.

basic_tofrom_string<string> conv(make_tuple(setprecision(2), &fixed), locale::classic());

conv.to_string(1234, &hex); conv.to_char(1.234, setw(10)); // avoid copying result to std::string conv.from_string<double>(str, 0.0);

All conversion routines uses a home-made streambuffer with optimizations to avoid copying and memory allocations (e.g. small string optimization & buffer reuse).

Main benefit over lexical_cast is that you can control formatting & locale but performance is also much better due to less memory alllocations.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users