In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes >> From: Markus Werle <[EMAIL PROTECTED]> >> >> The feature mentioned in the subject is missing in boost. >> (actually it throws) >> I propose adding something simmilar to the (incomplete) stuff below. >> >> template <typename Source> >> class lexical_stream_common_stuff<bool, Source> > >This could be a possibility. Rather than testing for the strings "true" and >"false" (which wouldn't respect locale), it may be better to set the ios_base >"boolalpha" flag, which reads and writes bool as "true" and "false" (or whatever >is set for the locale). > >However, the question is that some users may want to read/write "0" and "1", >instead. > >This has the same problem as other stream configuration, such as setting the >number base, etc.
Sensitivity to the global locale is important, so this would certainly have to be a consideration. However, it is not clear to me that "true" and "false" are necessarily better than "1" and "0" because that result is rarely surprising or awkward in the context of I/O streams. This differs from either precision loss for numerics or whitespace quirks for text types, which are the two obvious exceptions made in lexical_cast at present. Years ago I considered the bool issue, and rejected it the need for such special casing because it felt like more of a "would be nice if" than a "must have" feature. I am not sure that has changed. There are two basic directions in which I intend to evolve lexical_cast that may be relevant here: (1) Formulate the general model of conversion that is used in a way that allows text and numeric types to be considered part of a model rather than exceptions to it. In the past suggestions for lexical_cast have tended to focus on point solutions or have been implementation focused. It is time to tidy up the underlying conceptual model and make it explicit. However, I am not overly keen on adding Boolean types as an additional category that needs to be modelled. (2) Allow some form of parameterisation when converting -- but, just to be clear, this would not result in changes to the core lexical_cast function template or the addition of extra arguments. The motivation for this is the ability to use locales other than the global one, and is something that I have been discussing with Thomas Witt. Handling format- related flags would be a logical extension of this, and might be the way to address any need to work with bool as "true"/"false" rather than "1"/"0". Kevlin ____________________________________________________________ Kevlin Henney phone: +44 117 942 2990 mailto:[EMAIL PROTECTED] mobile: +44 7801 073 508 http://www.curbralan.com fax: +44 870 052 2289 Curbralan: Consultancy + Training + Development + Review ____________________________________________________________ _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost