Boost logo

Boost :

Subject: Re: [boost] none_t I/O operators
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-06-05 16:29:18

On 5/16/11 10:45 PM, Gregory Crosswhite wrote:
> Hey everyone,
> I have recently run into a scenario where it was useful to have << and
> >> I/O operators defined for none_t. I was using Boost Program
> Options to create a list of program options, and I wanted one of my
> options to be a help message. Since this option has no value except
> for the side effect of printing a help message and exiting, I gave it
> the type none_t, i.e.:
> options.add_options()
> ( "help"
> ,opts::value<none_t>()->zero_tokens()->notifier(...function
> that prints help message...)
> ,"print help message and exit\n"
> )
> When I did this, it complained that the >> operator was not defined
> for none_t, so I went ahead and defined my own I/O operators, which
> are essentially just no-ops:
> inline std::istream& operator>> (std::istream& in, boost::none_t&
> _) { return in; }
> inline std::ostream& operator<< (std::ostream& out, const
> boost::none_t& _) { return out; }
> It seems to me that these are the natural I/O operators to define for
> this type, and so it would be useful to have them be officially part
> of Boost. Although it is unlikely that a user would ever call them
> directly, their existence could prove useful in various circumstances
> where a generic I/O function is being applied to a none_t, such as the
> case I ran into/
> If people were willing to accept a patch that adds these operators to
> Boost, then I would be willing to write such a patch. Obviously I
> would need to generalize the istream/ostream types to the full generic
> versions which include the template parameters for character traits,
> etc. I would also add forward declarations of istream and ostream
> just before these declarations so that the implementation would not
> need to have the <istream> and <ostream> headers as dependencies,
> though this would be tricky because I'd need to figure out how to
> detect if <istream> and/or <ostream> have not been included yet.
> Thoughts?
> Cheers,
> Greg

YAY! By the three-week rule, since nobody has replied in the negative
that means that my idea has therefore been approved to be part of
Boost!!! :-D

On a more serious note, though, is there a trick one can use to write
I/O operators like the ones I defined above without necessarily pulling
in <iostream>? I am of course aware of the existence of forward
declarations, but unless my understanding of them is wrong (and
hopefully it is :-) ) they cause compiler errors when the forward
declared class has already been actually declared, so using forward
declarations would break in the case that the user had already pulled in
<iostream> before the forward declarations appeared.

Or, on the other hand, is the relative overhead of pulling in <iostream>
actually relatively small in the grand scheme of things so that this is
something that a library writer should not worry about in general when
thinking about supplying I/O operators for a supplied type?


Boost list run by bdawes at, gregod at, cpdaniel at, john at