[boost] none_t I/O operators

Subject: [boost] none_t I/O operators
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-05-17 01:45:42

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