[test] test/included min max macro issue

Hi Including "boost/test/included/unit_test.hpp" from the current SVN version also causes min and max macros to be defined on Windows (by headers pulled in from execution_monitor.ipp). Not being an expert on min/max macro issues, I wonder if this is necessary, or if the macro could be prevented from leaking to user code (without the user defining NOMINMAX). Regards, Stephan

"Stephan Tolksdorf" <andorxor@gmx.de> wrote in message news:449425F6.3030508@gmx.de...
Hi
Including "boost/test/included/unit_test.hpp" from the current SVN version also causes min and max macros to be defined on Windows (by headers pulled in from execution_monitor.ipp). Not being an expert on min/max macro issues, I wonder if this is necessary, or if the macro could be prevented from leaking to user code (without the user defining NOMINMAX).
I am not quite sure what you are complaining about. Boost.Test doesn't define these macro nor it could undefine them. If you do not want to be exposed to system level headers use offline component. Gennadiy

Gennadiy Rozental wrote:
"Stephan Tolksdorf" <andorxor@gmx.de> wrote in message news:449425F6.3030508@gmx.de...
Hi
Including "boost/test/included/unit_test.hpp" from the current SVN version also causes min and max macros to be defined on Windows (by headers pulled in from execution_monitor.ipp). Not being an expert on min/max macro issues, I wonder if this is necessary, or if the macro could be prevented from leaking to user code (without the user defining NOMINMAX).
I am not quite sure what you are complaining about. Boost.Test doesn't define these macro nor it could undefine them. If you do not want to be exposed to system level headers use offline component.
Just to clarify, all Boost libraries aim for complete neutrality regarding the min/max macros. They should compile cleanly regardless of whether the macros are defined or not, and should neither cause them to be defined (unless they must include system headers which define them) or undefine them. See: http://boost.org/more/lib_guide.htm -- Eric Niebler Boost Consulting www.boost-consulting.com

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler | Sent: 19 June 2006 19:44 | To: boost@lists.boost.org | Subject: Re: [boost] [test] test/included min max macro issue | | Gennadiy Rozental wrote: | > "Stephan Tolksdorf" <andorxor@gmx.de> wrote in message | > news:449425F6.3030508@gmx.de... | > | >>Hi | >> | >>Including "boost/test/included/unit_test.hpp" from the current SVN | >>version also causes min and max macros to be defined on Windows | | Just to clarify, all Boost libraries aim for complete neutrality | regarding the min/max macros. They should compile cleanly | regardless of | whether the macros are defined or not, and should neither | cause them to | be defined (unless they must include system headers which | define them) | or undefine them. | | http://boost.org/more/lib_guide.htm Says: # If you want to call std::numeric_limits<int>::max(), use (std::numeric_limits<int>::max)() instead. # If you want to call a min() or max() member function, instead to doing obj.min(), use (obj.min)(). Just to be clear, are you saying that these forms should ALWAYS be used in all code that might encounter windows.h or the min max macros (which obviously includes all Boost code)? This is a minor PITA, but we could get used to it :-( Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

Paul A Bristow wrote:
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler | | Just to clarify, all Boost libraries aim for complete neutrality | regarding the min/max macros. They should compile cleanly | regardless of | whether the macros are defined or not, and should neither | cause them to | be defined (unless they must include system headers which | define them) | or undefine them. | | http://boost.org/more/lib_guide.htm
Says:
# If you want to call std::numeric_limits<int>::max(), use (std::numeric_limits<int>::max)() instead.
# If you want to call a min() or max() member function, instead to doing obj.min(), use (obj.min)().
Just to be clear, are you saying that these forms should ALWAYS be used in all code that might encounter windows.h or the min max macros (which obviously includes all Boost code)?
This is a minor PITA, but we could get used to it :-(
That's exactly what I'm saying. Any time your fingers type "min" or "max", you should ask yourself if the min/max macros will make a hash of your code. If you forget, the Boost.Inspect tool, which is run by the release manager, will remind you. It automatically checks for violations of Boost's min/max guidelines. -- Eric Niebler Boost Consulting www.boost-consulting.com

| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler | Sent: 20 June 2006 20:26 | To: boost@lists.boost.org | Subject: Re: [boost] [test] test/included min max macro issue | | | Paul A Bristow wrote: | > | > | > | -----Original Message----- | > | From: boost-bounces@lists.boost.org | > | [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler | > | | > | Just to clarify, all Boost libraries aim for complete | neutrality | > | regarding the min/max macros. They should compile cleanly | > | regardless of | > | whether the macros are defined or not, and should neither | > | cause them to | > | be defined (unless they must include system headers which | > | define them) | > | or undefine them. | > | | > | http://boost.org/more/lib_guide.htm | > | > Says: | > | > # If you want to call std::numeric_limits<int>::max(), use | > (std::numeric_limits<int>::max)() instead. | > | > # If you want to call a min() or max() member function, | instead to doing | > obj.min(), use (obj.min)(). | > | > Just to be clear, are you saying that these forms should | ALWAYS be used in | > all code that might encounter windows.h or the min max | macros (which | > obviously includes all Boost code)? | > | > This is a minor PITA, but we could get used to it :-( | | That's exactly what I'm saying. Any time your fingers type "min" or | "max", you should ask yourself if the min/max macros will | make a hash of | your code. If you forget, the Boost.Inspect tool, which is | run by the | release manager, will remind you. It automatically checks | for violations | of Boost's min/max guidelines. Thanks for making this absolutely clear. I am sure I am not alone in needing to put some serious global grepping on my TODO list. Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com

A further quick question on this problem. It is my custom (having a strong view that it aids readers - including me - of my programs) to write #include <limits> using std::numeric_limits; How do I avoid min/max macro problems when writing, for example, return numeric_limits<double>::max(); ? (numeric_limits<double>)::max(); ??? Or have I done it already? Thanks Paul --- Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539561830 & SMS, Mobile +44 7714 330204 & SMS pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler | Sent: 20 June 2006 20:26 | To: boost@lists.boost.org | Subject: Re: [boost] [test] test/included min max macro issue | | | Paul A Bristow wrote: | > | > | > | -----Original Message----- | > | From: boost-bounces@lists.boost.org | > | [mailto:boost-bounces@lists.boost.org] On Behalf Of Eric Niebler | > | | > | Just to clarify, all Boost libraries aim for complete | neutrality | > | regarding the min/max macros. They should compile cleanly | > | regardless of | > | whether the macros are defined or not, and should neither | > | cause them to | > | be defined (unless they must include system headers which | > | define them) | > | or undefine them. | > | | > | http://boost.org/more/lib_guide.htm | > | > Says: | > | > # If you want to call std::numeric_limits<int>::max(), use | > (std::numeric_limits<int>::max)() instead. | > | > # If you want to call a min() or max() member function, | instead to doing | > obj.min(), use (obj.min)(). | > | > Just to be clear, are you saying that these forms should | ALWAYS be used in | > all code that might encounter windows.h or the min max | macros (which | > obviously includes all Boost code)? | > | > This is a minor PITA, but we could get used to it :-( | | | That's exactly what I'm saying. Any time your fingers type "min" or | "max", you should ask yourself if the min/max macros will | make a hash of | your code. If you forget, the Boost.Inspect tool, which is | run by the | release manager, will remind you. It automatically checks | for violations | of Boost's min/max guidelines. | | | -- | Eric Niebler | Boost Consulting | www.boost-consulting.com | _______________________________________________ | Unsubscribe & other changes: | http://lists.boost.org/mailman/listinfo.cgi/boost |

Not being an expert on min/max macro issues, I wonder if this is necessary, or if the macro could be prevented from leaking to user code (without the user defining NOMINMAX).
I am not quite sure what you are complaining about. Boost.Test doesn't define these macro nor it could undefine them. If you do not want to be exposed to system level headers use offline component.
The question basically was, if the macros could be automatically undefined after the inclusion of the windows headers in case they weren't defined in beforehand (or alternatively, if NOMINMAX could be selectively defined for the implementation of Boost.Test). Stephan

On Mon, 19 Jun 2006 20:50:00 +0200, Stephan Tolksdorf <andorxor@gmx.de> wrote:
The question basically was, if the macros could be automatically undefined after the inclusion of the windows headers in case they weren't defined in beforehand (or alternatively, if NOMINMAX could be selectively defined for the implementation of Boost.Test).
That would of course be possible, but still not transparent. Basically the first inclusion of windows.h for each translation unit determines whether the min and max macros will be present. If inclusion by unit_test.hpp is the first one then whatever it does it influences subsequent inclusions (which are actually no-ops, due to include guards); if it isn't the first one then the situation remains the same automatically, for the same reason. Microsoft's logic for the windows.h header seems to imply that it is never included from include files. This holds every time you put NOMINMAX, NOTHIS or NOTHAT macros in the apparent intent to give the user more control: what results, as you can see, is no control at all. --Gennaro.

Gennaro Prota wrote:
That would of course be possible, but still not transparent. Basically the first inclusion of windows.h for each translation unit determines whether the min and max macros will be present.
(...)
Microsoft's logic for the windows.h header seems to imply that it is never included from include files. This holds every time you put NOMINMAX, NOTHIS or NOTHAT macros in the apparent intent to give the user more control: what results, as you can see, is no control at all.
Thanks for explaining the issue. Stephan

Stephan Tolksdorf wrote:
Not being an expert on min/max macro issues, I wonder if this is necessary, or if the macro could be prevented from leaking to user code (without the user defining NOMINMAX).
I am not quite sure what you are complaining about. Boost.Test doesn't define these macro nor it could undefine them. If you do not want to be exposed to system level headers use offline component.
The question basically was, if the macros could be automatically undefined after the inclusion of the windows headers in case they weren't defined in beforehand (or alternatively, if NOMINMAX could be selectively defined for the implementation of Boost.Test).
Could they be undefined? Yes. Should they? Absolutely not. Whether we like it or not, there is code out there that depends on the fact that #include <windows.h> causes the min/max macros to be defined. Boost should not interfere. -- Eric Niebler Boost Consulting www.boost-consulting.com
participants (5)
-
Eric Niebler
-
Gennadiy Rozental
-
Gennaro Prota
-
Paul A Bristow
-
Stephan Tolksdorf