[lexical-cast] version of lexical_cast in 1.46.1 is quite older than in trunk
We discovered lexical_cast from 1.43 and 1.46.1 versions do not work in our program. But version of lexical_cast from trunk work very well. Version information: 1.46.1 - rev. 56161 13.09.2009 trunk - rev.65279 5.09.2010 1) Is there any reason that release does not include last version lexical_cast from trunk? 2) May be there are a lot of such forgotten files in trunk? Sergey Voropaev
This is really sad! "SergV" <serge-voropaev@yandex.ru> wrote in message news:loom.20110329T052451-354@post.gmane.org...
We discovered lexical_cast from 1.43 and 1.46.1 versions do not work in our program. But version of lexical_cast from trunk work very well. Version information: 1.46.1 - rev. 56161 13.09.2009 trunk - rev.65279 5.09.2010
1) Is there any reason that release does not include last version lexical_cast from trunk? 2) May be there are a lot of such forgotten files in trunk?
Sergey Voropaev
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Michael Goldshteyn wrote:
"SergV" <serge-voropaev@yandex.ru> wrote in message news:loom.20110329T052451-354@post.gmane.org...
We discovered lexical_cast from 1.43 and 1.46.1 versions do not work in our program. But version of lexical_cast from trunk work very well. Version information: 1.46.1 - rev. 56161 13.09.2009 trunk - rev.65279 5.09.2010
1) Is there any reason that release does not include last version lexical_cast from trunk? 2) May be there are a lot of such forgotten files in trunk?
This is really sad!
Do you volunteer to maintainer lexical_cast? - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40
Michael Goldshteyn wrote:
"SergV"<serge-voropaev@yandex.ru> wrote in message news:loom.20110329T052451-354@post.gmane.org...
We discovered lexical_cast from 1.43 and 1.46.1 versions do not work in our program. But version of lexical_cast from trunk work very well. Version information: 1.46.1 - rev. 56161 13.09.2009 trunk - rev.65279 5.09.2010
1) Is there any reason that release does not include last version lexical_cast from trunk? 2) May be there are a lot of such forgotten files in trunk?
This is really sad!
Do you volunteer to maintainer lexical_cast? Does that mean lexical_cast is orphaned? I'd like to see lexical_cast have optimized conversions for string->number and number->string (template specializations using strtol/strtod; or optionally using
On 3/30/2011 9:22 AM, Vladimir Prus wrote: the spirit-based construe_cast). Being able to pass ios flags to control the format (i.e. boolalpha) would be nice too. The only hurdle I see was mentioned on 2010/01/19 by Alexander Nasonov:
You can't use C functions from C++ without saving the old C locale and restoring it after a conversion. Now, if you take into account multi-threading ... This would be a big argument in favor of construe_cast I guess.
-Matt
On Wed, 2011-03-30 at 18:16 +0300, Matthew Chambers wrote:
Does that mean lexical_cast is orphaned? I'd like to see lexical_cast have optimized conversions for string->number and number->string (template specializations using strtol/strtod; or optionally using the spirit-based construe_cast). Being able to pass ios flags to control the format (i.e. boolalpha) would be nice too.
Which reminds me - lexical_cast error messages are not very informative, so in order to save debugging time I've used local variants like this: template <typename T> T number_cast(const std::string & theValue) { try { return boost::lexical_cast<T>(theValue); } catch(boost::bad_lexical_cast &) { throw std::runtime_error("number_cast failed to convert '"+theValue+"' to " + number_name<T>()); } } with template <typename T> inline const char * number_name() { return "a number"; } template <> inline const char * number_name<float>() { return "float"; } template <> inline const char * number_name<int>() { return "int"; } ... My template programming is not much beyond the level displayed above, so I will not venture to suggest how a feature like this could or should be incorporated into boost::lexical_cast, but I'd be very happy if someone would be interested and skilled enough to do so. --> Mika Heiskanen
On 3/30/2011 10:46 AM, Mika Heiskanen wrote:
On Wed, 2011-03-30 at 18:16 +0300, Matthew Chambers wrote:
Does that mean lexical_cast is orphaned? I'd like to see lexical_cast have optimized conversions for string->number and number->string (template specializations using strtol/strtod; or optionally using the spirit-based construe_cast). Being able to pass ios flags to control the format (i.e. boolalpha) would be nice too.
Which reminds me - lexical_cast error messages are not very informative, so in order to save debugging time I've used local variants like this:
template<typename T> T number_cast(const std::string& theValue) { try { return boost::lexical_cast<T>(theValue); } catch(boost::bad_lexical_cast&) { throw std::runtime_error("number_cast failed to convert '"+theValue+"' to " + number_name<T>()); } }
with
template<typename T> inline const char * number_name() { return "a number"; }
template<> inline const char * number_name<float>() { return "float"; } template<> inline const char * number_name<int>() { return "int"; } ...
My template programming is not much beyond the level displayed above, so I will not venture to suggest how a feature like this could or should be incorporated into boost::lexical_cast, but I'd be very happy if someone would be interested and skilled enough to do so.
Agreed. This should be added as well. I don't care that TR1's std::lexical_cast will differ in implementation. That's not a sound argument for letting boost::lexical_cast fester, especially when there is so much room for improvement. In other words, how many things in boost have equivalently named entities in std? How many of them do the exact same thing vs. do it better? -Matt
On Wed, Mar 30, 2011 at 11:58 AM, Matthew Chambers <matt.chambers42@gmail.com> wrote:
... I don't care that TR1's std::lexical_cast will differ in implementation. That's not a sound argument for letting boost::lexical_cast fester, especially when there is so much room for improvement. In other words, how many things in boost have equivalently named entities in std? How many of them do the exact same thing vs. do it better?
Could you explain? There isn't any "TR1 std::lexical_cast", AFAIK. --Beman
On 1/18/2010 8:37 AM, Alexander Nasonov wrote:
I'm afraid it's too late to change lexical_cast, it's already in the next standard.
I didn't bother checking the truth of this since I only pay attention to what's in the next standard when it's out. :) -Matt On 4/1/2011 7:14 AM, Beman Dawes wrote:
On Wed, Mar 30, 2011 at 11:58 AM, Matthew Chambers <matt.chambers42@gmail.com> wrote:
... I don't care that TR1's std::lexical_cast will differ in implementation. That's not a sound argument for letting boost::lexical_cast fester, especially when there is so much room for improvement. In other words, how many things in boost have equivalently named entities in std? How many of them do the exact same thing vs. do it better?
Could you explain? There isn't any "TR1 std::lexical_cast", AFAIK.
--Beman
participants (6)
-
Beman Dawes -
Matthew Chambers -
Michael Goldshteyn -
Mika Heiskanen -
SergV -
Vladimir Prus