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

Subject: Re: [boost] [optional] generates unnessesary code for trivial types
From: Andrzej Krzemienski (akrzemi1_at_[hidden])
Date: 2012-02-13 15:51:11

> > 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?

I have checked the standard and indeed thread::id provides operator<<
without the matching operator>>, so this asymmetry would not be a precedent
in the standard. Although the situation with thread::id is speciffic. ID's
are assigned by the OS and trying to assign them by other means would
definitely be an error.
I also checked boost::optional and it provides both (I learned two new
things today). Uninitialized optional of any type renders "--" (two
dashes); whereas initialize optional always prepends a space. I am not sure
if this does not look like hack; but people already said this would not be
much of a problem.

Certainly, there ways to make the output of optional configurable. I am not
sure manipulators would be my preference. An alternative would be the
approach that Boost.Date_time has adopted: you set your preference per
stream (plus one global setting) by means of locale mechanism. However,
when it comes to proposing stuff in front of the ISO committee, there is
one other factor, which I failed to mention yet. It is the "fragility" of
the process. I am concerned that if anything turns out to be controversial,
the whole Optional would be at risk of being rejected. This might be an
exaggeration (I have never gone through the process of proposing something
and then pushing it through), but Optional has already been proposed by
Fernando (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1878.htm)
and rejected; primarily for two things: operators -> and * and the
semantics for optional reference assignment (see
http://lists.boost.org/Archives/boost/2005/10/95079.php). I would much like
to avoid the situation where Optional (which I believe is very useful to
wide variety of programmers) would be rejected because of one additional,
however tiny, controversy of streaming operator.

Regards,
&rzej