Hi John, you are the maintainer of Boost.Math and very active on the list to fix bugs in many libraries. May I ask why you ignore your own bugs such as http://svn.boost.org/trac/boost/ticket/1454? Did you not recieved the bug report because both messages were (maybe) considered as SPAM or what is the reason to not apply a patch which fixes build failures and a typo (you included sinh.hpp where sin.hpp was required)? Many other patches from me are also still not applied (and are nearly 2 months old) but math is properly maintained, right? Jens
Jens Seidel wrote:
Hi John,
you are the maintainer of Boost.Math and very active on the list to fix bugs in many libraries. May I ask why you ignore your own bugs such as http://svn.boost.org/trac/boost/ticket/1454?
Did you not recieved the bug report because both messages were (maybe) considered as SPAM or what is the reason to not apply a patch which fixes build failures and a typo (you included sinh.hpp where sin.hpp was required)?
Apologies, I hadn't seen that report, I'll look into that.
Many other patches from me are also still not applied (and are nearly 2 months old) but math is properly maintained, right?
Yep. John.
On Tue, Dec 11, 2007 at 09:37:52AM -0000, John Maddock wrote:
Jens Seidel wrote:
May I ask why you ignore your own bugs such as http://svn.boost.org/trac/boost/ticket/1454?
Apologies, I hadn't seen that report, I'll look into that.
OK, it is now fixed. But I did not get any mail about it (at least for this bug report). I miss also your last comment ("Previous fix was incomplete") and why didn't you get a mail about my initial bug report (or did you recieve it?). Is there a problem with trac and mails? PS: John, to avoid to miss other posts of you I just use this mail to send you a further trivial patch which corrects mostly wrong comments in your header inclusion file tests (did you not use libs/math/test/compile_test/generate.sh to generate these?). PS2: I still miss an explanation from you why you use both internal and external inclusion guards: boost/math/complex/asinh.hpp contains: #ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED # include <boost/math/complex/details.hpp> #endif and boost/math/complex/details.hpp: #ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED #define BOOST_MATH_COMPLEX_DETAILS_INCLUDED Is this just old code or was it necessary because of the asinh/asin typo and you did so for other files as well? I suggest to remove all outer include guards (also in other files). Jens
On 14/12/2007, Jens Seidel <jensseidel@users.sf.net> wrote:
OK, it is now fixed. But I did not get any mail about it (at least for this bug report). I miss also your last comment ("Previous fix was incomplete") and why didn't you get a mail about my initial bug report (or did you recieve it?).
Is there a problem with trac and mails?
As far as I can tell, trac doesn't mail changes caused by subversion commits. Daniel
On Fri, Dec 14, 2007 at 03:33:58PM +0000, Daniel James wrote:
On 14/12/2007, Jens Seidel <jensseidel@users.sf.net> wrote:
OK, it is now fixed. But I did not get any mail about it (at least for this bug report). I miss also your last comment ("Previous fix was incomplete") and why didn't you get a mail about my initial bug report (or did you recieve it?).
Is there a problem with trac and mails?
As far as I can tell, trac doesn't mail changes caused by subversion commits.
Right. But I expect to get a mail once a comment was added or the bug gets closed. I do get such mails for some bugs but not for all (yes, I checked my spam folder). Also some maintainers (and also John) wrote that they didn't know about a new bug report. I once was also forced to open a bug report about trac as it considered some of my patches as SPAM and rejected these. So there are definitevly some issues. The biggest problem I see is that it is impossible to search for own bugs (at least without registration which is <quote>normally granted to maintainers and authors of prospective (“sandbox”) and accepted Boost libraries, people working on the Boost website, and people contributing significant content to this Wiki.</quote>), especially once they are closed as they are not well handled on http://svn.boost.org/trac/boost/report (only one item shows also closed ones). You can also not list the submitter of a bug, only the owner ... Jens
Jens Seidel wrote:
OK, it is now fixed. But I did not get any mail about it (at least for this bug report). I miss also your last comment ("Previous fix was incomplete") and why didn't you get a mail about my initial bug report (or did you recieve it?).
Is there a problem with trac and mails?
I'm not sure: I had to add my email address under the "settings" section in order to see email notifications. I had previously assumed that it was set up automatically given that you have to supply an email address when you sign up, but apparently not.
PS: John, to avoid to miss other posts of you I just use this mail to send you a further trivial patch which corrects mostly wrong comments in your header inclusion file tests (did you not use libs/math/test/compile_test/generate.sh to generate these?).
I did auto-generate them originally, but the tests weren't as effective as I'd hoped so they got changed :-( I should remove the shell script really. I'll look into the buggy comments.
PS2: I still miss an explanation from you why you use both internal and external inclusion guards: boost/math/complex/asinh.hpp contains:
#ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED # include <boost/math/complex/details.hpp> #endif
and boost/math/complex/details.hpp:
#ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED #define BOOST_MATH_COMPLEX_DETAILS_INCLUDED
Is this just old code or was it necessary because of the asinh/asin typo and you did so for other files as well?
I suggest to remove all outer include guards (also in other files).
Why? It makes no difference, except to improve performance for compilers that don't implement the include-guard detection trick that gcc uses. Regards, John
On Fri, Dec 14, 2007 at 04:28:58PM -0000, John Maddock wrote:
Jens Seidel wrote:
PS2: I still miss an explanation from you why you use both internal and external inclusion guards: boost/math/complex/asinh.hpp contains:
#ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED # include <boost/math/complex/details.hpp> #endif
and boost/math/complex/details.hpp:
#ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED #define BOOST_MATH_COMPLEX_DETAILS_INCLUDED
Is this just old code or was it necessary because of the asinh/asin typo and you did so for other files as well?
I suggest to remove all outer include guards (also in other files).
Why? It makes no difference, except to improve performance for compilers that don't implement the include-guard detection trick that gcc uses.
Heh? What trick? To ensure that an include file is not included twice one normally defines a unique preprocessor macro at the beginning of the header file and skips processing if it was previously defined. Doesn't every Boost header does this? Do you consider using #define a trick? I just want to mention that #include <boost/math/complex/details.hpp> is easier to read than #ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED # include <boost/math/complex/details.hpp> #endif It is also more secure because you increase the chance to make a typo in the macro which could be hard to track down. You're right that it could be a little bit faster but I have never seen it somewhere (including Boost). I was just curious ... Jens
Jens Seidel wrote:
On Fri, Dec 14, 2007 at 04:28:58PM -0000, John Maddock wrote:
Jens Seidel wrote: I just want to mention that #include <boost/math/complex/details.hpp> is easier to read than #ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED # include <boost/math/complex/details.hpp> #endif
It is also more secure because you increase the chance to make a typo in the macro which could be hard to track down. You're right that it could be a little bit faster but I have never seen it somewhere (including Boost).
Both Borland and Microsoft have used the idiom above, so maybe you have never seen it because you never used either of those compilers or looked at some of the source or header files they distribute with their C++ compiler implementations.
Jens Seidel wrote:
Why? It makes no difference, except to improve performance for compilers that don't implement the include-guard detection trick that gcc uses.
Heh? What trick?
GCC has an optimisation: it spots when a file has already been included and auto-magically prevents it from being included twice, if the effect would be to include an empty file. It's similar to Microsoft's #pragma once but automatic.
To ensure that an include file is not included twice one normally defines a unique preprocessor macro at the beginning of the header file and skips processing if it was previously defined.
Doesn't every Boost header does this? Do you consider using #define a trick?
That's not what I'm talking about, and those files do use the std include guard mechanism, it's just that's there's a second catch to prevent multiple inclusion, so the file doesn't get opened twice. But in all honesty it's a triviality ;-)
I just want to mention that #include <boost/math/complex/details.hpp> is easier to read than #ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED # include <boost/math/complex/details.hpp> #endif
It is also more secure because you increase the chance to make a typo in the macro which could be hard to track down. You're right that it could be a little bit faster but I have never seen it somewhere (including Boost).
As noted by Edward, various vendors use this in their own headers. Is it a good idea? I don't know, I think the jury is still out on that one. If more compilers would follow GCC's lead and automatically recognise include guards, the the discussion would be moot anyway... John.
John Maddock wrote:
Jens Seidel wrote:
I just want to mention that #include <boost/math/complex/details.hpp> is easier to read than #ifndef BOOST_MATH_COMPLEX_DETAILS_INCLUDED # include <boost/math/complex/details.hpp> #endif
It is also more secure because you increase the chance to make a typo in the macro which could be hard to track down. You're right that it could be a little bit faster but I have never seen it somewhere (including Boost).
As noted by Edward, various vendors use this in their own headers.
Is it a good idea? I don't know, I think the jury is still out on that one.
I hate guards around #include, if that counts ;-)
If more compilers would follow GCC's lead and automatically recognise include guards, the the discussion would be moot anyway...
Huge improvement...., but I also hate traditional include guards inside the header files. The ideal solution before we get modules in the language would be to change the default behaviour in preprocessors so the typical use case "#include once" became the default and that we had to explicitly declare use case of unrestricted inclusion, "#include unrestricted". Ok, this may not be realistic given that it would break some code which depend on headerfiles being read multiple times. But without the change in default, the removal of the need for the error prone, none-intuitive, and extremly ugly traditional include guards would a move forward for the language. There are two areas that are problematic with such a direction for language support of file include restrictions. The first area is to find a smooth migration path. I think this is the worst problem. A good example of this is the situation with regard to portable use of the MS "#pragma once" extention. If it had imediatly been adapted by all compiler vendors, then the pragmatic C++ comunity migth have adapted it as the standard, alothough "#once" would have done the trick after standarization. This would have been a huge improvement over the traditional include guards. The advantage with this approach is that current default is not broken, but then we would never get the default that make sence. The problem with #pragma once is however that there is no way of smooth portable migration. Avoiding horribly ugly code is impossible, just look every place in boost it is used. As long as there is no implemented standard for this, it is basically not a way forward in my mind. The other problem area is the exact standard text. What are the required behaviour of (pre)compilers? What guaranties are compilers required to implement by the standard? I think this is quite possible to work out if preformance of compilation is something we would expect from a good implementation, but not require by the standard. I.e. if the compiler need to rescan the file to be sure the content is identical, it should be allowed to do so. Use of hash checksums, filesystem/OS features, SCM features, etc. to achive performance under these requirements should entirely be a an implementation detail. Under the current situation, I think the #pragma once should be removed from portable code. It is just too ugly to justify as long as we also need the traditional include guards. Sorry all msvc fans, that is my vote. Ask MS to fix their compiler to be effective under the current standard or help fix the standard if they need efficiency. -- Bjørn
participants (5)
-
Bjørn Roald -
Daniel James -
Edward Diener -
Jens Seidel -
John Maddock