Re: [boost] none_t I/O operators

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?

Thanks!
Greg