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

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

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

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