More changes to the Inspection Report: * Line numbers are now shown when a problem is associated with a specific line in a file. * Apple macros clashes now show the specific name causing the problem. * Spacing is optimized so that problems without line numbers don't take up so much report space. See the results at http://boost.cowic.de/rc/inspect-trunk.html Thanks to everyone who commented yesterday! --Beman
Beman Dawes wrote:
More changes to the Inspection Report:
* Line numbers are now shown when a problem is associated with a specific line in a file. * Apple macros clashes now show the specific name causing the problem. * Spacing is optimized so that problems without line numbers don't take up so much report space.
See the results at http://boost.cowic.de/rc/inspect-trunk.html
Thanks to everyone who commented yesterday!
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
HI, Could it be possible to unify the report of *APPLE-MACROS* calls to Apple's debugging macros in file *M* uses of min or max that have not been protected from the min/max macros, or unallowed #undef-s BTW, the report use sometimes the abbreviated form *XX* and some times the English form. tools/build/v2/build/virtual_target.py: *Lic* tools/build/v2/doc/development_plan.html: Unlinked file Could this be unified? Some times we will modify a source file (C++), then remove the modifications, but sometimes we can left trailing white spaces and double white lines that are not easy to view. Tis changes will made the file to be committed the next time we commit the modified files even if these spaces are not useful in C++ files. In addition they make a difference when we use a diff tool, or when we merge two files, increasing the possibility of conflicts. What about reporting trailing spaces? What about reporting double empty lines? Can some options be added so the inspection tool can *EOL* replace invalid (cr only) line-ending by the correct ones. *END* add a newline to last line of the files that doesn't ends with *Tab* replace tabs with a given number of white spaces (default could be 8) *Trim* remove the white spaces from the end of a line *DBL* replace double white lines by one Best, Vicente -- View this message in context: http://old.nabble.com/-inspect--More-changes-to-Inspection-Report-tp27225588... Sent from the Boost - Dev mailing list archive at Nabble.com.
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Tuesday, January 19, 2010 1:13 PM To: Boost Developers List Subject: [boost] [inspect] More changes to Inspection Report
More changes to the Inspection Report:
* Apple macros clashes now show the specific name causing the problem.
It is clearly a nuisance for all Boost authors to avoid using the lowercase name 'check' - and even more to have to change code retrospectively. (It wouldn't be quite so bad of they had followed the UPPERCASE for MACROS convention, or if macros were namespaced). I'm sure it is too late to do anything about this now, but do we have any channel for Boost to send an Official Raspberry to Apple by way of complaint - to try (probably in vain) to reduce the risk of something like this in future. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com
On Thu, Jan 21, 2010 at 7:17 AM, Paul A. Bristow <pbristow@hetp.u-net.com> wrote:
* Apple macros clashes now show the specific name causing the problem.
It is clearly a nuisance for all Boost authors to avoid using the lowercase name 'check' - and even more to have to change code retrospectively.
(It wouldn't be quite so bad of they had followed the UPPERCASE for MACROS convention, or if macros were namespaced).
I'm sure it is too late to do anything about this now, but do we have any channel for Boost to send an Official Raspberry to Apple by way of complaint - to try (probably in vain) to reduce the risk of something like this in future.
Good question. Some companies respond best to private contacts. Others only do anything about complaints received as formal support requests from their registered users. Still others react mostly to negative press coverage, or negative comments on their public support forums. Does anyone know what seems to work with Apple developer issues? --Beman
On Jan 21, 2010, at 4:17 AM, Paul A. Bristow wrote:
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Sent: Tuesday, January 19, 2010 1:13 PM To: Boost Developers List Subject: [boost] [inspect] More changes to Inspection Report
More changes to the Inspection Report:
* Apple macros clashes now show the specific name causing the problem.
It is clearly a nuisance for all Boost authors to avoid using the lowercase name 'check' - and even more to have to change code retrospectively.
I agree.
(It wouldn't be quite so bad of they had followed the UPPERCASE for MACROS convention, or if macros were namespaced).
There is a way to deal with this which doesn't require any code changes. The macros in question are defined in a file "/usr/include/AssertMacros.h", which is guarded by an #ifndef __ASSERTMACROS__ #define __ASSERTMACROS__ ...... #endif construct. If we were to define __ASSERTMACROS__ in the darwin.jam file, then these macros would never be defined. However, this could lead to other problems down the road. -- Marshall
Marshall Clow wrote:
There is a way to deal with this which doesn't require any code changes. The macros in question are defined in a file "/usr/include/AssertMacros.h", which is guarded by an
#ifndef __ASSERTMACROS__ #define __ASSERTMACROS__ ...... #endif
construct. If we were to define __ASSERTMACROS__ in the darwin.jam file, then these macros would never be defined.
However, this could lead to other problems down the road.
It would lead to problems now for anyone using BBv2 for non-Boost (or mixed) development and happens to be using those macros. If we had a standard "prefix.hpp" & "suffix.hpp" that all libraries could include we could def+undef the guard while including Boost headers. But this is still fragile as people could include the AssertMacros.h before Boost headers. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera-2 wrote:
Marshall Clow wrote:
There is a way to deal with this which doesn't require any code changes. The macros in question are defined in a file "/usr/include/AssertMacros.h", which is guarded by an
#ifndef __ASSERTMACROS__ #define __ASSERTMACROS__ ...... #endif
construct. If we were to define __ASSERTMACROS__ in the darwin.jam file, then these macros would never be defined.
However, this could lead to other problems down the road.
It would lead to problems now for anyone using BBv2 for non-Boost (or mixed) development and happens to be using those macros. If we had a standard "prefix.hpp" & "suffix.hpp" that all libraries could include we could def+undef the guard while including Boost headers. But this is still fragile as people could include the AssertMacros.h before Boost headers.
I've read recent discussion and the ticket 2115 [1] and my impression is that this problem has not been solved, has it? Is there any recommendation how to cope with this problem in Boost Libraries. [1] https://svn.boost.org/trac/boost/ticket/2115 Best regards, ----- -- Mateusz Loskot http://mateusz.loskot.net -- View this message in context: http://old.nabble.com/-inspect--More-changes-to-Inspection-Report-tp27225588... Sent from the Boost - Dev mailing list archive at Nabble.com.
participants (6)
-
Beman Dawes -
Marshall Clow -
Mateusz Loskot -
Paul A. Bristow -
Rene Rivera -
Vicente Botet Escriba