hi, would it be possible to add a set of overloads to lexical_cast to allow for more efficient conversions when the code to do so is readily available (and especially when it is part of the standard library)? below is part of my own rather simplistic implementation of this idea which has been tested on VC7.1 and seems to work fine. other overloads for floats using atof etc. proceed in a similar manner to that for ints. template<class T, class U> T to(U const& u) { return to(u, Type2Type<T>()); } template<class T, class U> T to(U const& u, Type2Type<T> const&) { return lexical_cast<T>(u); } int to(std::string const& arg, Type2Type<int> const&) { return atoi(arg.c_str()); } ian whittley
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. ian whittley
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).
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users- bounces@lists.boost.org] On Behalf Of Jonathan Turkanis Sent: Thursday, June 02, 2005 1:48 PM To: boost-users@lists.boost.org Subject: [Boost-users] Re: lexical_cast
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.
Jonathan
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. 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... -delfin
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
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<fixed_string<10> >(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.
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<fixed_string<10> >(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
Is this library freely available? Not yet. The library itself work fine but there is no documentation.
It also sounds like a good addition to boost itself...
It would easy to add the same functionality to lexical_cast where I think it belongs. Having two different libraries doing the same thing is not a good idea. Problem is that the interface for lexical_cast is fixed and it is explicitly stated in the documenatation that suggestions for extra arguments will not be considered.
participants (5)
-
Delfin Rojas -
ian whittley -
Jonathan Turkanis -
Martin -
Michael B. Edwin Rickert