Søren Lassen <s.lassen@post.tele.dk> writes:
Sorry, I should probably have intialized the dialogue in a more toned-down manner. On the other hand, I do not feel that the somewhat heated tone of the discussion is all my fault. E.g. when Dave tells me that there are no programming guidelines on the homepage, I did feel sort of snubbed -
Get over it, it's true.
he, of all persons, should know that the homepage has a link to a set of programming guidelines
Are you kidding? Why "of all persons" should I remember every link on the homepage, and know that's what you're talking about when you refer to "guidelines on the home page?"
which at least appears to be official Boost policy.
There is no guideline about constness of return types. You extrapolated from a reference to a book the idea that Boost takes everything in that book to be an absolute rule. Look, you show up with an almost completely misguided and hasty post about "bugs" in a library, then you try to claim that Boost isn't following its own programming guidelines, and then haul out http://www.boost.org/more/lib_guide.htm#Rationale_rationale to deliver what feels to me like a verbal bludgeoning with our own words. At that point I don't think you should expect anyone to bend over backwards to be understanding. So, no "the somewhat heated tone of the discussion" is not all your fault. If I were a perfectly enlightened being, I'm sure I wouldn't be annoyed and I would have found some way to gently and patiently correct all of your misperceptions. Unfortunately for everyone involved, I'm just human like everyone else. And, while I appreciate that you're willing to take some responsibility, "sorry, I shouldn't have done that... but it's really Dave's fault too" doesn't amount to much of an apology.
Anyway, it may be a good idea to include e.g. a reference to Scott's errata, and to the other books mentioned during the discussion on the guidelines page. Likewise, when there is a discussion about e.g. the const-ness of return values, it may be worth the effort to condense some of the points into a simple text that gets a link on the Guidelines page.
Patches are welcome.
-- Søren
P.S.: Here is my test program. My version of operators.hpp takes about 18 seconds with the Borland compiler and 23 with the Microsoft compiler, whereas the official version takes about 15, resp. 20 seconds to run, all very approximately (no need to count the milliseconds, the assembly output also contains more "mov" instructions in my version):
What we really need, as I have requested several times already, is a test program for the problem your other patch addresses. I mean the one that still might be valid, and that fixes the compilation failure on some compilers. -- Dave Abrahams Boost Consulting www.boost-consulting.com