Q: W4003 with vc7 boost=1.32 in date_time lib
Hello, I just wanted to see if there are others getting this warning in VC7 with Boost 1.32, or it's just me doing something wrong with the #include order or forgetting a #define. The warning reads: C:\Boost\include\boost-1_32\boost\date_time\gregorian\greg_facet.hpp(293) : warning C4003: not enough actual parameters for macro 'max' thanks for any help... Dan --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.802 / Virus Database: 545 - Release Date: 26-Nov-04
Dan Dimerman wrote:
C:\Boost\include\boost-1_32\boost\date_time\gregorian\greg_facet.hpp(293) : warning C4003: not enough actual parameters for macro 'max'
before including
At Sunday 2004-11-28 14:34, you wrote:
Dan Dimerman wrote:
C:\Boost\include\boost-1_32\boost\date_time\gregorian\greg_facet.hpp(293) : warning C4003: not enough actual parameters for macro 'max'
before including
put #define NOMINMAX or put this definition into project settings. Another solution is to undef min max macros after including : #undef min #undef max
IMNSHO both of those are unacceptable solutions... date_time should be doing that itself. it also doesn't explain why with 7.1 (which has the defines bounded by #ifndef __cplusplus #endif that the problem still exists
B.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Hello Victor, VW> IMNSHO both of those are unacceptable solutions... date_time should VW> be VW> doing that itself. Sorry, should do what? WinDef.h defines min and max macros, if NOMINMAX is undefined. So date_time should somehow have specific behavior for windows headers? VW> it also doesn't explain why with 7.1 (which has the defines bounded VW> by VW> #ifndef __cplusplus VW> #endif VW> that the problem still exists There is no "#ifndef __cplusplus\n#endif" around min and max definition in WinDef.h, and IMHO shouldn't be. -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
At Monday 2004-11-29 02:11, you wrote:
Hello Victor,
VW> IMNSHO both of those are unacceptable solutions... date_time should VW> be VW> doing that itself. Sorry, should do what? WinDef.h defines min and max macros, if NOMINMAX is undefined. So date_time should somehow have specific behavior for windows headers?
VW> it also doesn't explain why with 7.1 (which has the defines bounded VW> by VW> #ifndef __cplusplus VW> #endif VW> that the problem still exists There is no "#ifndef __cplusplus\n#endif" around min and max definition in WinDef.h, and IMHO shouldn't be.
why not? all C++ users are supposed to know that they have to #define NOMINMAX if they're going to use windows? and if my defining it beforehand doesn't break anything, then neither would their doing it automatically.
-- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
Hello Victor, VW> why not? all C++ users are supposed to know that they have to VW> #define NOMINMAX if they're going to use windows? and if my VW> defining it beforehand doesn't break anything, then neither would VW> their doing it automatically. VW> There are dozens of libraries that doesn't concern to boost. I see no reasons for boost to explicitly support neither windows nor other external libraries that violates rules for standard integrity. It's my IMHO. NOMINMAX is a windows stuff, so just use it in you project, that's all. -- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
At Monday 2004-11-29 22:59, you wrote:
Hello Victor,
VW> why not? all C++ users are supposed to know that they have to VW> #define NOMINMAX if they're going to use windows? and if my VW> defining it beforehand doesn't break anything, then neither would VW> their doing it automatically. VW>
There are dozens of libraries that doesn't concern to boost. I see no reasons for boost to explicitly support neither windows nor other external libraries that violates rules for standard integrity. It's my IMHO.
NOMINMAX is a windows stuff, so just use it in you project, that's all.
I wasn't suggesting that boost do anything...but Dave gets upset when I dis Microsoft for being lazy or foolish, or just plain stupid.
-- Vyacheslav E. Andrejev System Architect, Excelsior, LLC
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Tue, 30 Nov 2004 05:59:44 +0000 (UTC), Vyacheslav E. Andrejev wrote
Hello Victor,
VW> why not? all C++ users are supposed to know that they have to VW> #define NOMINMAX if they're going to use windows? and if my VW> defining it beforehand doesn't break anything, then neither would VW> their doing it automatically. VW>
There are dozens of libraries that doesn't concern to boost. I see no reasons for boost to explicitly support neither windows nor other external libraries that violates rules for standard integrity. It's my IMHO.
NOMINMAX is a windows stuff, so just use it in you project, that's all.
I think there are reasons when on windows to not just undef these -- like when using ATL. Eric Niebler actually made most of these changes between 1.31/1.32 for all of boost -- not just date-time. Eric any thoughts on this problem/thread? Jeff
At Sunday 2004-11-28 10:26, you wrote:
Hello,
I just wanted to see if there are others getting this warning in VC7 with Boost 1.32, or it's just me doing something wrong with the #include order or forgetting a #define.
The warning reads: C:\Boost\include\boost-1_32\boost\date_time\gregorian\greg_facet.hpp(293) : warning C4003: not enough actual parameters for macro 'max'
yes I get them also. I don't know what "macro" it refers to either I'm using vc7.1 and stdlib.h explicitly doesn't #define max(a,b) if __cplusplus is defined. so I'm puzzled
thanks for any help...
Dan
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.802 / Virus Database: 545 - Release Date: 26-Nov-04
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
windows.h defines the min() and max() macros - tends to mess up c++ so
you can define NOMINMAX before any headers if you dont want that.
On Sun, 28 Nov 2004 17:54:26 -0700, Victor A. Wagner Jr.
At Sunday 2004-11-28 10:26, you wrote:
Hello,
I just wanted to see if there are others getting this warning in VC7 with Boost 1.32, or it's just me doing something wrong with the #include order or forgetting a #define.
The warning reads: C:\Boost\include\boost-1_32\boost\date_time\gregorian\greg_facet.hpp(293) : warning C4003: not enough actual parameters for macro 'max'
yes I get them also. I don't know what "macro" it refers to either I'm using vc7.1 and stdlib.h explicitly doesn't #define max(a,b) if __cplusplus is defined. so I'm puzzled
thanks for any help...
Dan
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.802 / Virus Database: 545 - Release Date: 26-Nov-04
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
-- Cory Nelson http://www.int64.org
Dan Dimerman wrote:
The warning reads: C:\Boost\include\boost-1_32\boost\date_time\gregorian\greg_facet.hpp(293) : warning C4003: not enough actual parameters for macro 'max'
This is a date_time bug. Boost has guidelines for avoiding clashes with the min/max macros, which you can read at http://boost.org/more/lib_guide.htm. Requiring users to #define NOMINMAX is not satisfatory. Sadly, there are 3rd party libraries, and even platform headers, that depend on those macros. To play well in the real world, Boost headers should compile cleanly even in the presence of the min/max macros. -- Eric Niebler Boost Consulting www.boost-consulting.com
On Tue, 30 Nov 2004 17:49:27 -0800, Eric Niebler wrote
Dan Dimerman wrote:
The warning reads: C:\Boost\include\boost-1_32\boost\date_time\gregorian\greg_facet.hpp(293) : warning C4003: not enough actual parameters for macro 'max'
This is a date_time bug. Boost has guidelines for avoiding clashes with the min/max macros, which you can read at http://boost.org/more/lib_guide.htm.
Yes, I'm afraid you are right -- we apparently missed this after you made the other boost min/max changes :-( Sadly non of our regression procedures caught this and if your primary test platform isn't Windows it's an easy mistake to make...
Requiring users to #define NOMINMAX is not satisfatory. Sadly, there are 3rd party libraries, and even platform headers, that depend on those macros. To play well in the real world, Boost headers should compile cleanly even in the presence of the min/max macros.
.rant on While I understand your point, I think we should push for reform in Redmond. 99.9% of the folks at MS know better than this, but we (the users) always have to deal with the 0.1 percent that do stupid stuff like this. Same thing goes with the DLL definitions. If MS wanted to, they could easily eliminate the requirement that classes to be exported be written with macros (eg: class SOME_MS_MACRO_MAGIC foo) and just fix the tools to allow external definitions of dll linking. I'm sick of wasting my time dealing with non-standard MS requirements. So I say, submit your bug reports to Wa. .rant off Jeff ps: I'm not an MS hater, except when they waste my time...
Jeff Garland wrote:
.rant on While I understand your point, I think we should push for reform in Redmond.
<rant snipped> Microsoft is now a much better citizen than it was when it first introduced the min/max macros into their platform headers. That wouldn't fly at MS these days. But, having worked there, I know why they would strongly resist taking the macros out. It's a breaking change, and users have a "fix" -- #define NOMINMAX. (The fact that there is at least one platform header that depends on them is clearly a bug.) What I'm trying to say is, Redmond has already reformed quite a bit -- the revolution is over, we're just left coping with its aftermath. -- Eric Niebler Boost Consulting www.boost-consulting.com
At Wednesday 2004-12-01 18:08, you wrote:
Jeff Garland wrote:
.rant on While I understand your point, I think we should push for reform in Redmond.
<rant snipped>
Microsoft is now a much better citizen than it was when it first introduced the min/max macros into their platform headers. That wouldn't fly at MS these days. But, having worked there, I know why they would strongly resist taking the macros out. It's a breaking change, and users have a "fix" -- #define NOMINMAX. (The fact that there is at least one platform header that depends on them is clearly a bug.) What I'm trying to say is, Redmond has already reformed quite a bit -- the revolution is over, we're just left coping with its aftermath.
yeah, it's why they still haven't fixed the CRTMEMDEBUG stuff either. because you can define the stuff yourself. I tried to explain to the twit on the phone that what is in there now is broken, and cannot work, changing it canNOT possibly break anything...but they're still so dense that they won't fix it. oh, and #define NOMINMAX isn't a "fix". It's a workaround
-- Eric Niebler Boost Consulting www.boost-consulting.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"
On Wed, 01 Dec 2004 17:08:50 -0800, Eric Niebler wrote
Jeff Garland wrote:
.rant on While I understand your point, I think we should push for reform in Redmond.
<rant snipped>
Microsoft is now a much better citizen than it was when it first introduced the min/max macros into their platform headers. That wouldn't fly at MS these days. But, having worked there,
Yes, I agree things are better.
I know why they would strongly resist taking the macros out. It's a breaking change,
Well, that's just wrong-headed. For one thing, making no-change is 'breaking' for people that hit this anew and waste their time figuring out the work around. I've actually known about this problem for several years and yet here I've had to relearn again. They could easily leave the macro there and change the default to NOMINMAX so that future generations don't have to continue to suffer from past evils. The customers that foolishly depend on this directly in their code would have to set a compile flag to get back the min/max definitions or patch their version of windows.h to change the default. IME 99.9% of the users 'usage' of this is to define NOMINMAX so the change would be non-breaking for these customers. This goes into the release notes and users will just deal with it. To me it is a minor price to pay to be able to able to write the string 'max' or 'min' in C++ code without adornment or fear.
and users have a "fix" -- #define NOMINMAX. (The fact that there is at least one platform header that depends on them is clearly a bug.) What I'm trying to say is, Redmond has already reformed quite a bit -- the revolution is over, we're just left coping with its aftermath.
Oh well, I've checked a patch into CVS to fix it -- thanks to Bart Garst for writing and testing it :-) Jeff
participants (7)
-
Bronek Kozicki -
Cory Nelson -
Dan Dimerman -
Eric Niebler -
Jeff Garland -
Victor A. Wagner Jr. -
Vyacheslav E. Andrejev