| Author |
problems with new boost lib
|
|
| Duane Hebert 2005-04-06, 12:52 pm |
| I'm in the process of updating from boost 1.31 to 1.32. I have a header
file
that stores some constants for numeric limits.
It looks like this:
// usual header guards
#include <limits> // for numeric_limits
const float maxFloat = std::numeric_limits<float>::max();
//
I get the following errors for each line in the header file:
c:\MSVC\Projects\Common\numeric_constant
s.h(6) : warning C4003: not enough
actual parameters for macro 'max'
c:\MSVC\Projects\Common\numeric_constant
s.h(6) : error C2589: '(' : illegal
token on right side of '::'
c:\MSVC\Projects\Common\numeric_constant
s.h(6) : error C2059: syntax error :
'::'
c:\MSVC\Projects\Common\numeric_constant
s.h(6) : error C2059: syntax error :
')'
c:\MSVC\Projects\Common\numeric_constant
s.h(6) : error C2059: syntax error :
')'
It seems that it thinks that max is a macro. Am I missing an include or
something?
| |
| Duane Hebert 2005-04-06, 12:52 pm |
|
"Duane Hebert" <spoo@flarn.com> wrote in message
news:OStotfeOFHA.244@TK2MSFTNGP12.phx.gbl...
> I'm in the process of updating from boost 1.31 to 1.32. I have a header
> file
> that stores some constants for numeric limits.
> It looks like this:
>
> // usual header guards
> #include <limits> // for numeric_limits
> const float maxFloat = std::numeric_limits<float>::max();
I found one solution on the boost site:
const float maxFloat = (std::numeric_limits<float>::max)();
Macros s*ck.
| |
| Carl Daniel [VC++ MVP] 2005-04-06, 12:52 pm |
| Duane Hebert wrote:
> I'm in the process of updating from boost 1.31 to 1.32. I have a
> header file
> that stores some constants for numeric limits.
> It looks like this:
>
> // usual header guards
> #include <limits> // for numeric_limits
> const float maxFloat = std::numeric_limits<float>::max();
> //
>
> I get the following errors for each line in the header file:
>
>
> c:\MSVC\Projects\Common\numeric_constant
s.h(6) : warning C4003: not
> enough actual parameters for macro 'max'
> c:\MSVC\Projects\Common\numeric_constant
s.h(6) : error C2589: '(' :
> illegal token on right side of '::'
> c:\MSVC\Projects\Common\numeric_constant
s.h(6) : error C2059: syntax
> error : '::'
> c:\MSVC\Projects\Common\numeric_constant
s.h(6) : error C2059: syntax
> error : ')'
> c:\MSVC\Projects\Common\numeric_constant
s.h(6) : error C2059: syntax
> error : ')'
>
> It seems that it thinks that max is a macro. Am I missing an include
> or something?
max IS a macro, unfortunately, if you've #included <windows.h> (thanks to
the Platform SDK group years ago).
You can #define NO_MINMAX before including windows.h to prevent the macros.
You can also re-phrase your code:
const float maxFloat = std::numeric_limits<float>::(max)();
That odd looking syntax is still a valid function invocation in C++, but it
won't be recognized as a use of the max(a,b) macro by the preprocessor.
-cd
| |
| Stephen Howe 2005-04-06, 12:52 pm |
| > It seems that it thinks that max is a macro.
Which it may do if you are including <windows.h> which defines those
non-standard macros.
Have you defined NOMINMAX before including it?
Stephen Howe
| |
| Duane Hebert 2005-04-06, 12:52 pm |
|
"Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
wrote in message news:eWblhzeOFHA.3928@TK2MSFTNGP09.phx.gbl...
> max IS a macro, unfortunately, if you've #included <windows.h> (thanks to
> the Platform SDK group years ago).
> You can #define NO_MINMAX before including windows.h to prevent the
macros.
We're not directly including windows.h anywhere but we are doing unmanaged
c++ with Qt. Either Qt or boost must be pulling it in.
> You can also re-phrase your code:
>
> const float maxFloat = std::numeric_limits<float>::(max)();
>
> That odd looking syntax is still a valid function invocation in C++, but
it
> won't be recognized as a use of the max(a,b) macro by the preprocessor.
That particular syntax didn't seem to work. I think it has to do with the
namespaces. This does seem to work:
const float maxFloat = (std::numeric_limits<float>::max)();
Thanks for the suggestion though. Funny thing is that this didn't happen
with the previous version of boost.
| |
| Duane Hebert 2005-04-06, 12:52 pm |
|
"Stephen Howe" <stephenPOINThoweATtns-globalPOINTcom> wrote in message
news:Ok2440eOFHA.3336@TK2MSFTNGP09.phx.gbl...
>
> Which it may do if you are including <windows.h> which defines those
> non-standard macros.
> Have you defined NOMINMAX before including it?
We're not directly including it. Either boost or Qt may be.
At any rate, I bracketed the calls to max as suggested by Carl
in another post and this seems to work.
One of my favorite things about winapi stuff is the macros <g>
Normally I get bit by the "somefunctionA" is not a member due
to the Unicode macros.
| |
| Carl Daniel [VC++ MVP] 2005-04-06, 12:52 pm |
| "Duane Hebert" <spoo@flarn.com> wrote in message
news:u8eSJDfOFHA.2604@TK2MSFTNGP10.phx.gbl...
> "Carl Daniel [VC++ MVP]" <cpdaniel_remove_this_and_nospam@mvps.org.nospam>
> wrote in message news:eWblhzeOFHA.3928@TK2MSFTNGP09.phx.gbl...
>
> That particular syntax didn't seem to work. I think it has to do with the
> namespaces. This does seem to work:
>
> const float maxFloat = (std::numeric_limits<float>::max)();
Yeah - I forgot to include the namespace inside the ().
-cd
| |
| Gene Bushuyev 2005-04-06, 12:52 pm |
| Macros strike again!
min/max macros are frequent offenders. So when I create a header file for
public consumption when I can't know what is included before it, I always
start with:
#undef min
#undef max
"Duane Hebert" <spoo@flarn.com> wrote in message
news:OStotfeOFHA.244@TK2MSFTNGP12.phx.gbl...
> I'm in the process of updating from boost 1.31 to 1.32. I have a header
> file
> that stores some constants for numeric limits.
> It looks like this:
>
> // usual header guards
> #include <limits> // for numeric_limits
> const float maxFloat = std::numeric_limits<float>::max();
> //
>
> I get the following errors for each line in the header file:
>
>
> c:\MSVC\Projects\Common\numeric_constant
s.h(6) : warning C4003: not enough
> actual parameters for macro 'max'
>
| |
| Duane Hebert 2005-04-06, 12:52 pm |
|
"Gene Bushuyev" <gb@127.0.0.1> wrote in message news:dAz4e.1776$qD2.612@newssvr14.news.prodigy.com...
> Macros strike again!
> min/max macros are frequent offenders. So when I create a header file for
> public consumption when I can't know what is included before it, I always
> start with:
> #undef min
> #undef max
That was actually my first solution<g>
We use some 3rd partly libs though and I would hate to
update one that pulled in some redef of min or max
later. I went with the bracketing the function idea.
I wonder if MS will ever get rid of all these macros <g>
| |
| Lisa Pearlson 2005-04-12, 4:00 am |
| Why would microsoft get rid of min and max macro's?
So to be compatible with standards? Since when is that a priority for M$? :)
"Duane Hebert" <spoo@flarn2.com> wrote in message
news:uYIP94jOFHA.204@TK2MSFTNGP15.phx.gbl...
>
> "Gene Bushuyev" <gb@127.0.0.1> wrote in message
> news:dAz4e.1776$qD2.612@newssvr14.news.prodigy.com...
>
> That was actually my first solution<g>
> We use some 3rd partly libs though and I would hate to
> update one that pulled in some redef of min or max
> later. I went with the bracketing the function idea.
> I wonder if MS will ever get rid of all these macros <g>
>
>
| |
| Simon Trew 2005-04-12, 4:00 am |
| "Duane Hebert" <spoo@flarn2.com> wrote in message
news:uYIP94jOFHA.204@TK2MSFTNGP15.phx.gbl...
>
> "Gene Bushuyev" <gb@127.0.0.1> wrote in message
> news:dAz4e.1776$qD2.612@newssvr14.news.prodigy.com...
>
> That was actually my first solution<g>
> We use some 3rd partly libs though and I would hate to
> update one that pulled in some redef of min or max
> later. I went with the bracketing the function idea.
> I wonder if MS will ever get rid of all these macros <g>
>
I doubt it, for the same reason you imply. If you undefine them, then
existing code that relies on their implementation details will break.
Microsoft used to have a strong tradition of not breaking existing code,
though some bloggers now believe this has gone by the wayside. (I shan't
reference the blogs, this is a newsgroup, right, and anyway, it's 2am and
it's my birthday.)
No doubt somwhere there is code that relies on min(a++, b++) evaluating a++
and b++ twice, though no sequence point intervene, or max(x(), y()) calling
x and y twice.
S.
| |
| Carl Daniel [VC++ MVP] 2005-04-12, 4:00 am |
| Lisa Pearlson wrote:
> Why would microsoft get rid of min and max macro's?
> So to be compatible with standards? Since when is that a priority for
> M$? :)
The problem is that they don't conflict with the C standard, and the
official API of Windows is defined in C, not C++. Unless the C++ team wants
to take on the (eternal) task of maintaining a separate C++ API for Windows,
there's nothing they can do. Since the Platform SDK folks work in C,
they're more concerned about backwards compatibility with the existing
Windows code base than with C++ standard compliance.
-cd
| |
| Stephen Howe 2005-04-12, 4:00 am |
| > Unless the C++ team wants to take on the (eternal) task of maintaining a
> separate C++ API for Windows, there's nothing they can do.
Yes they can. if _cplusplus is defined then the header files in Windows can
make sure min and max are not defined as macros.
Stephen Howe
| |
| Carl Daniel [VC++ MVP] 2005-04-12, 4:01 pm |
| Stephen Howe wrote:
>
> Yes they can. if _cplusplus is defined then the header files in
> Windows can make sure min and max are not defined as macros.
You missed my point - the issue is not technical but political. The PSDK
folks, who own windows.h, apparently don't care about C++ compliance. The
VC++ folks, who do care about C++ compliance, can't make changes to
windows.h without taking on an everlasting job of fixing every new version
of the PSDK header files that comes along, and coming up with new names for
all the files (since windows.h would still be for C), and updating all the
documentation, and ...
-cd
|
|
|
|