Opened 15 years ago

Closed 15 years ago

Last modified 15 years ago

#1638 closed Feature Requests (invalid)

allow lexical_cast to handle based number strings

Reported by: Steven Robbins <smr@…> Owned by: nasonov
Milestone: Boost 1.36.0 Component: lexical_cast
Version: Boost 1.34.1 Severity: Problem
Keywords: Cc:

Description

This report comes from Debian user "Wesley J. Landaker" <wjl@…> See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412931

Please allow lexical_cast to handle based number strings. Currently, it only supports decimal strings, but it should be able to handle octal and hexadecimal strings if they have correct prefix notations.

Background: This happens because lexical_cast constructs a stringstream, which by default has the ios_base::dec flag set. If this flag is unset, it will still read decimal strings, but will also automatically determine the base by looking at the prefix, so will read decimal strings if the number starts with 0-9, octal if it starts with 0, and hex if it starts with 0x.

Fix: After constructing the stringstream, simply call stringstring::unsetf(std::ios_base::basefield). Because decimal numbers are still handled correctly, this is totally backwards compatible.

Change History (3)

comment:1 by nasonov, 15 years ago

Component: Nonelexical_cast
Owner: set to nasonov
Status: newassigned

comment:2 by nasonov, 15 years ago

Resolution: invalid
Status: assignedclosed

This feature is out scope of the library.

References:

[1] Boost documentation

http://www.boost.org/libs/conversion/lexical_cast.htm#motivation

[2] Lexical Conversion Library Proposal for TR2

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1973.html

Both have this text: For more involved conversions, such as where precision or formatting need tighter control than is offered by the default behavior of lexical_cast, the conventional stringstream approach is recommended.

comment:3 by René Rivera, 15 years ago

I've run into this problem many, many times. And hadn't realized it was possible to provide for better number conversion. In my opinion allowing such number base conversion is not only within the scope, but by not allowing the conversions it specifically imposes an artificial "tighter control" than the expected behavior.

Any chance we can change your mind about this?

Note: See TracTickets for help on using tickets.