Message du 06/05/11 13:31 De : "Stewart, Robert" A : "'boost@lists.boost.org'" Copie à : Objet : Re: [boost] [review] string convert
Vicente BOTET wrote:
De : "Stewart, Robert"
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.
I see.
- 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.
I mentioned before that overloading can avoid such concerns.
You are right, overloading could be used, I missed this point.
If you don't supply any formatting, then you get the simpler implementation. If you do, you get the more complicated implementation.
Maybe there should be distinct names for each set in order to clarify that they work differently. Obviously, to use manipulators requires the use of a stream. Without them, other implementations are possible, though some l10n functionality is needed still for string<->type conversions.
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.
Maybe. First, there's the lexical_cast approach to always convert (or, in the modern interpretation, as if) via a stream. In that design, manipulators can influence the resulting conversion. Second, string<->type conversions are an extremely important use case.
lexical cast hides the stream usage, but we have ios << source; ios >> target; If we want to support type-to-type via stream and manimulators we will need to be able to do in the implementation ios << omn_1 << ... << omnp_n << source; ios >> imnp_1 >> ... >> imnp_k >> target; As far as I perceive the Boost.Convert library the manipulators are used either to convert to a string or from a string. I have not see deeply hwat allows the converter class. Can someone tell me if the reviewed interface can be used to make such type-to-type conversions?
In another post I proposed to use an istream proxy when converting from a string to a type
as_istream(str) >> std::hex >> i;
I do find that interesting, but does it offer enough benefit relative to the following?
std::istringstream s; s >> std::hex >> i;
I have no problems with that. I was just proposing a one-line solution.
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;
That is troublesome. However, we could create a more efficient form of std::ostringstream:
string str; converting_ostream(str) << std::hex << i;
Yes this could be useful.
Obviously, move semantics make using std::ostringstream just as efficient, though slightly less convenient:
std::ostringstream s; s << std::hex << i; string const str(s.str());
If operator <<() returned std::ostringstream, it could be streamlined still more:
string const str((ostringstream() << std::hex << i).str()); It usually is.
We could also define an operation that takes the stream and extract a type returning the value instead of requesting a variable int i = extract(str >> ios >> std::hex) string str = extract(ios << std::hex << i); With this interface we can add in a single expression output manipulators and input manipulators. Best, Vicente