C2923 when compiling template class Vector3 (Name conflicts with macros)

[EasternJournalist]

I was compiling with C++17 MSVC. And it went : 'Float' is not a valid template type argument for parameter 'Float'. And a lot of compiling errors followed.

The errors occurr here (and also the same in the function "max").

template <typename Float>
inline Vector3<Float> min(const Vector3<Float>& a, const Vector3<Float>& b) noexcept
{
   ...
}

I suppose it's because min and max are defined macro in its included files. After changing the name of the funtions to "Min" and "Max", it passes successfully. It can also be solved by undefining min and max at the head of the file.

[EasternJournalist]

Another conflict with macro is the variable "near" in Traverser<Float, Primitive, Intersector, Flags>::traverse in traverser.h. It needs to be undefined.

#ifdef near
#undef near
#endif
...

[brandonpelfrey]

I was compiling with C++17 MSVC.
...
I suppose it's because min and max are defined macro in its included files. After changing the name of the funtions to "Min" and "Max", it passes successfully. It can also be solved by undefining min and max at the head of the file.

Thanks for the note. Does MSVC expose a define that I could use to un-define the macros only in the case of MSVC?

[brandonpelfrey]

Another conflict with macro is the variable "near" in Traverser<Float, Primitive, Intersector, Flags>::traverse in traverser.h. It needs to be undefined.

#ifdef near
#undef near
#endif
...

https://stackoverflow.com/a/119553/115546
Sounds like a relic from segmented memory days which gets included through some Windows-specific include file.

What is the top-level include that is introducing the macros? I don't have a Windows system to test this.

[EasternJournalist]

I was compiling with C++17 MSVC.
...
I suppose it's because min and max are defined macro in its included files. After changing the name of the funtions to "Min" and "Max", it passes successfully. It can also be solved by undefining min and max at the head of the file.

Thanks for the note. Does MSVC expose a define that I could use to un-define the macros only in the case of MSVC?

Another conflict with macro is the variable "near" in Traverser<Float, Primitive, Intersector, Flags>::traverse in traverser.h. It needs to be undefined.

#ifdef near
#undef near
#endif
...

https://stackoverflow.com/a/119553/115546
Sounds like a relic from segmented memory days which gets included through some Windows-specific include file.

What is the top-level include that is introducing the macros? I don't have a Windows system to test this.

Thanks for your reply.

You can use _MSC_VER to test if the compilor is MSVC. It's a macro that identifies the version of MSVC.
The head files where near is introduced is minwindef.h, which defines _MINWINDEF_.

[brandonpelfrey]

@EasternJournalist Thanks for _MSC_VER to identify MSVC compiler. How is minwindef.h getting included? I don't want to change the names of the functions min/max if possible, and there would be many software projects that would name something min/max so I want to find out how to avoid minwindef.h being included, or undefine min/max before defining them in our vector class. We should not need to change our function names.

[EasternJournalist]

Yes. #define NOMINMAX at the very beginning could skip the definition of macros min and maxin minwindef.h. https://stackoverflow.com/questions/13416418/define-nominmax-using-stdmin-max But I simply solve it by undefining like this without identify the compilor and platform.

#ifdef  min
#undef min
#endif

I guess undefining min and max will not cause any trouble, since few third party softwares would use this macro #define min ((a)<(b)?(a):(b)) .

For the problem with near, as is mentioned in https://stackoverflow.com/a/119553/115546.

#ifdef near
#pragma push_macro("near")
#undef near
...
...
#pragma pop_macro ("near")
#endif

But in most cases it can be simply un-defined because it is rarely used now.