Re: [boost] [none_t] I/O operators patch

Subject: Re: [boost] [none_t] I/O operators patch
From: Gregory Crosswhite (gcross_at_[hidden])
Date: 2011-06-06 11:28:49

On 6/6/11 7:30 AM, Stewart, Robert wrote:
> You have no tests or documentation.  Once you have tests, preferably tests you've ensured fail without your patch and pass with it, the tests must run the testing gauntlet.

That is certainly reasonable, though I would prefer to know that there 
was a good chance that my patch would actually be accepted before going 
to the trouble of doing that first.  :-)

> Then, when all tests pass on all available platforms, you can ask that your patches be incorporated.

So, I am glad that you brought this up because it is actually something 
I have been wondering about:  how do boost developers typically test on 
all available platforms?  Do they just personally tend to have all or 
most of the available platforms available to them, or are there public 
test beds available for this purpose?  I know that there are such 
systems that constantly run regressions tests for the trunk and release 
branches, but I haven't seen any information on the web site about 
resources for people like me who would like to test a patch on platforms 
other than what we have access to (which on my case is gcc 4.2 on a Mac 
and gcc 4.4 on Linux) before it makes its way into the trunk.

> To the foregoing procedural issues, there's also the concern that you got almost no response to your proposal.  That suggests that there is little to no interest.  If that's truly the case, then your idea may best be implemented locally.

That's is certainly a fair point (despite my kidding "three-week rule", 
which just gave me an excuse to bring up the discussion again :-) ), 
especially since the design choices that I currently see to implement 
this idea in Boost are to either include <iosfwd> in none_t.hpp in order 
to make these operators be always available to users, which incurs the 
overhead of <iosfwd> for a negligible chance that the operators will be 
used, or to put the operators in a separate none_t_io.hpp file, which 
people are likely to miss when they do need the operators which means 
that there is a good chance that a user would just inadvertently end up 
re-implementing them anyway.

Regardless, if nothing else I have learned a lot from this process.  
:-)  Thank you very much for the feedback!

Cheers,
Greg