On 5/16/11 10:45 PM, Gregory Crosswhite wrote:
Hey everyone,
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
I have recently run into a scenario where it was useful to have << and 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