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