Re: [boost] [optional] generates unnessesary code for trivial types

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2012-02-13 12:30:05

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?