Message du 05/05/11 22:57 De : "Matthew Chambers" A : boost@lists.boost.org Copie à : Objet : Re: [boost] [review] string convert
On 5/5/2011 3:17 PM, Vicente BOTET wrote:
Message du 05/05/11 19:48 De : "Stewart, Robert" A : "'boost@lists.boost.org'" Copie à : Objet : Re: [boost] [review] string convert
Vicente BOTET wrote:
are we discussing here a generic interface from type-to-type or one that uses an intermediary stream to make the conversion?
I've been considering it the former. Why does using a stream to make the conversion affect that?
The fact that we want to add some formatting parameters, apply manipulators and so on to a generic interface disturb me.
- T convert_cast(S, formatting = none); can throw - T convert_cast(S, T, formatting = none) - optional name_me_1(S, formatting = none) - optional name_me_1(S, T, formatting = none) - pair name_me_2(S, T, formatting = none)
I would prefer to don't pay for these defaulted parameters in the generic case.
Maybe I'm wrong, but the manipulators are only useful when converting from a string or to a string. If this is the case, all the stream stuff should be moved to a string conversion interface. I would even prefer that the stream part stay away and independent. In another post I proposed to use an istream proxy when converting from a string to a type
as_istream(str)>> std::hex>> i;
For conversions from a type to a string, we can use an ostream proxy, which is implicitly convertible to string.
string str = as_ostream()<< std::hex<< i;
Conversions from strings to primitives and vice versa will vastly outnumber other type-to-types. If we're going to bias the interface in some way, I believe in doing it for the general case. And unless I'm missing something, the as_xstream syntax has the same implicit conversion problem that the convert::from() syntax has.
Hrr, you are right for the as_ostream It will be great if we could write str << as_ostream() << std::hex<< i; and str >> as_iistream() >> std::hex>> i; In these cases there will not be implicit conversion. Another possibility is to have a string converter that follows the numeric converter pattern template (*...*) struct converter { static result_type convert ( argument_type s ) ; result_type operator() ( argument_type s ) const ; // other specific functions }
Other kinds of type-to-type conversion that aren't better served by numeric_cast (unless you're proposing to wrap numeric_cast with boost.conversion?) are practically edge cases, aren't they? We can allow the interface to support them, but we shouldn't reduce it to the lowest common denominator when the general requirements are higher.
Well, this is the intent of my library Boost.Conversion. If you think that this is not useful, I have lost client ;-)
Also, the string conversion will be optimized for the common cases: integral<->string and floating<->string. Lexical_cast's current stream-only implementation won't suffice. Basically, I think type-to-stream-to-type should be the fallback mechanism if no specialization is available. And of course sometimes even that fallback mechanism will fail with UDTs.
Boost.conversion fallback mechanism for convert_to is a call to the explicit conversion Target(rhs). If the user wants another kind of conversion he must overload the convert_to function. If the user think that two types can be converted using lexical_cast, numeric_cast or other specific mechanism, he will need to make an overload and forward to the corresponding cast. I like this generic interface, as it allows to name all the conversions the same way. If more sophisticated conversion are needed it will be better to use a string converter, numeric converter or any other specific mechanism. Well, this is how I see this conflicting subject. Best, Vicente