Hey everyone, Since my idea to add I/O operators for none_t has been approved by the community according to the three-week rule --- which as you all know states that any proposals that have received no feedback on the list after three weeks are therefore automatically approved by the community ;-) --- I have written a patch based on the feedback I have received to implement these operators and attached it to this e-mail. To summarize my earlier e-mail, the advantage of having these operators around is that they allow generic I/O code to be applied to data of type none_t. One decision that I made in this patch that I have mixed feelings about is that I put the operators in the boost namespace. The advantages of this approach are obvious, but the disadvantage is that this "hides" them from the user who might not realize that he or she needs to import operator>> and operator<< in order to access them (since importing qualified operators is something that is not usually done) but instead conclude they they don't exist at all. Alternatives include putting them in the global namespace and putting them in the std namespace. Any thoughts on this? Since the window for adding new features to Boost closes tomorrow, and this patch is relatively small and should be fairly innocuous, is there a chance that this or something like it could be considered for the next release? Thanks! :-) Greg
2011/6/6 Gregory Crosswhite <gcross@phys.washington.edu>
Hey everyone,
Since my idea to add I/O operators for none_t has been approved by the community according to the three-week rule --- which as you all know states that any proposals that have received no feedback on the list after three weeks are therefore automatically approved by the community ;-) --- I have written a patch based on the feedback I have received to implement these operators and attached it to this e-mail. To summarize my earlier e-mail, the advantage of having these operators around is that they allow generic I/O code to be applied to data of type none_t.
One decision that I made in this patch that I have mixed feelings about is that I put the operators in the boost namespace. The advantages of this approach are obvious, but the disadvantage is that this "hides" them from the user who might not realize that he or she needs to import operator>> and operator<< in order to access them (since importing qualified operators is something that is not usually done) but instead conclude they they don't exist at all. Alternatives include putting them in the global namespace and putting them in the std namespace. Any thoughts on this?
Since the window for adding new features to Boost closes tomorrow, and this patch is relatively small and should be fairly innocuous, is there a chance that this or something like it could be considered for the next release?
Thanks! :-) Greg
Hi Greg, I personally don't see any use for these operators, nor any harm they could do. About your namespace concern: wolud these operators be found via ADL, if you put them into the same namecpace, as none_helper (that is boost::detail)? Also, did you consider adding these operators to another file (i.e. none_t_io.hpp), so that users of none_t, who (usually) don't need these operators, don't get <iosfwd> on the way? Notice, that boost::none is defined in a separate file too. Regards Kris
On 6/5/11 5:23 PM, Krzysztof Czainski wrote:
About your namespace concern: wolud these operators be found via ADL, if you put them into the same namecpace, as none_helper (that is boost::detail)?
Yup, that seems to do it --- sweet! :-)
Also, did you consider adding these operators to another file (i.e. none_t_io.hpp), so that users of none_t, who (usually) don't need these operators, don't get<iosfwd> on the way? Notice, that boost::none is defined in a separate file too.
Good idea. My new proposal is to add a new header file called none_t_io.hpp, which I have attached to this e-mail. Thank you very much for your feedback, Kris! :-D Cheers, Greg
Gregory Crosswhite wrote:
I have written a patch based on the feedback I have received to implement these operators and attached it to this e-mail.
[snip]
Since the window for adding new features to Boost closes tomorrow, and this patch is relatively small and should be fairly innocuous, is there a chance that this or something like it could be considered for the next release?
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. Then, when all tests pass on all available platforms, you can ask that your patches be incorporated. 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. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
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
Gregory Crosswhite wrote:
On 6/6/11 7:30 AM, Stewart, Robert wrote:
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?
No. Developers usually just push things into trunk after testing on whatever platforms were at hand. Then, the developers check the regression tests results to learn what other platforms may balk.
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.
When there is reason to suspect problems on other platforms, folks just post asking for help on specific platforms. _____ Rob Stewart robert.stewart@sig.com Software Engineer using std::disclaimer; Dev Tools & Components Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
participants (3)
-
Gregory Crosswhite -
Krzysztof Czainski -
Stewart, Robert