Re: [boost] [optional] generates unnessesary code for trivial types
Side question: is streamablity going to be in your proposal? It is not currently. The reason for that is that there is no clear way how it should be implemented (a similar issue applies to pairs, tuples, variant, any, etc...) See http://lists.boost.org/Archives/boost/2005/03/81619.php<http://www.google.com/url?sa=D&q=http://lists.boost.org/Archives/boost/2005/03/81619.php&usg=AFQjCNFPzL-GUYzdflTuhTsLwJS4r5R9NQ>for discussion. I believe that the problem is with the streaming itself. For instance, should streaming out and then streaming the result back in produce the same value? Some people expect that, but even std::string could not provide this behavior.
I'd do only << and forget about >>
But even that appears like a non-obvious thing to me. Would other people here in the list, and also developers in general agree that it is ok that you have output operation but no input operation? I think that in the standard library they always go in pairs. (I am not sure, though). Also, how would you implement it? what should an uninitialized optional print? Nothing? but how is having printed an uninitialized optional<int> different that not having printed anything? A question mark? but how would the following two be different: optional<string> o1; // uninitialized optional<string> o2 = "?"; cout << o1; cout << o2; If you propose to provide only output operation, then it looks like you want this for some sort of logging. But perhaps it is better to have some overloaded function toString() that converts all the types to strings. Usually the string format that works for one program does not work for the other. And there appears to be no natural/intuitive way of representing any type (like optional) as text. Regards, &rzej
On Monday, February 13, 2012 17:25:32 Andrzej Krzemienski wrote:
But even that appears like a non-obvious thing to me. Would other people here in the list, and also developers in general agree that it is ok that you have output operation but no input operation? I think that in the standard library they always go in pairs. (I am not sure, though).
In my own code I often find myself defining only output operators. For things more complex than enums or numerics I usually handle input with specialized solutions, with tools line Boost.Spirit. As for the standard library, I'm not sure but dos thread::id have an input operator?
Also, how would you implement it? what should an uninitialized optional print? Nothing? but how is having printed an uninitialized optional<int> different that not having printed anything? A question mark? but how would the following two be different:
FWIW, boost::optional provides both input and output.
If you propose to provide only output operation, then it looks like you want this for some sort of logging. But perhaps it is better to have some overloaded function toString() that converts all the types to strings. Usually the string format that works for one program does not work for the other. And there appears to be no natural/intuitive way of representing any type (like optional) as text.
I usually dislike toString and alike methods. I think, manipulators are more flexible and modularized approach. Do you think it would be possible to provide different manipulators to fulfill different IO requirements?
On Mon, Feb 13, 2012 at 5:25 PM, Andrzej Krzemienski <akrzemi1@gmail.com> wrote:
Also, how would you implement it?
if (o1) os << *o1;
what should an uninitialized optional print? Nothing? but how is having printed an uninitialized optional<int> different that not having printed anything? A question mark? but how would the following two be different:
They won't.
If you propose to provide only output operation, then it looks like you want this for some sort of logging. But perhaps it is better to have some overloaded function toString() that converts all the types to strings.
Isn't that what << is for? :p
Usually the string format that works for one program does not work for the other. And there appears to be no natural/intuitive way of representing any type (like optional) as text.
Right and that's not limited to optional. Defining no IO seems ok too. -- Olaf
participants (3)
-
Andrey Semashev -
Andrzej Krzemienski -
Olaf van der Spek