Macro function conflicts namespace function?

[Immortal Nephi]

What happen if you want to use same function name? Same function
names in other header files will be conflict.

For example

// Header1.h
#include <windows.h> // Microsoft uses a lot of macros.

namespace Header1 {

#undef funcName // only for example like Microsoft’s funcName()
void funcName() {…}
}

// Header2.h
namespace Header2 {
void funcName() {…}
}

#include “Header1.h”
#include “Header2.h”

int main() {
Header1::funcName();
Header2::funcName();

return 0;
}

Namespace is the answer, but C++ Compiler will fail to compile.
Why? Header files might have same function name as macros such as
Microsoft uses a lot of macros. You will have to write “#undef
funcName” before either same funcName functions in different
namespaces will work.
But what? You may need to use Microsoft’s functions outside
namespace. You can’t undefined them. What is the alternation?
Rename your function names inside namespace?

 

[Squeamizh]

(e-mail address removed):

     What happen if you want to use same function name?  Same function
names in other header files will be conflict.

For example

// Header1.h
#include <windows.h> // Microsoft uses a lot of macros.

namespace Header1 {

#undef funcName // only for example like Microsoft’s funcName()
     void funcName() {…}
}

// Header2.h
namespace Header2 {
     void funcName() {…}
}

#include “Header1.h”
#include “Header2.h”

int main() {
     Header1::funcName();
     Header2::funcName();

     return 0;
}

     Namespace is the answer, but C++ Compiler will fail to compile.
Why?  Header files might have same function name as macros such as
Microsoft uses a lot of macros.  You will have to write “#undef
funcName” before either same funcName functions in different
namespaces will work.

These complaints should really go to Microsoft (not that they could or
would do much about it). Another common source of conflicting macros are
the Perl headers.

     But what?  You may need to use Microsoft’s functions outside
namespace.  You can’t undefined them.  What is the alternation?
Rename your function names inside namespace?

Or rename the macro

#define WinGetUserName(a,b) GetUserName(a,b)
#undef GetUserName
TCHAR buffer[N];
if (WinGetUserName(buffer, N)) ...

Does that work? It doesn't seem to work for me. For example:

$ cat preproc01.cpp
#define MACRO1 (i = 10)

#define MACRO2 MACRO1
#undef MACRO1

#include <iostream>

int main()
{
int i = 100;

MACRO1;

std::cout << "i = " << i << '\n';
}

$ g++ preproc01.cpp
preproc01.cpp: In function 'int main()':
preproc01.cpp:12: error: 'MACRO1' was not declared in this scope


....but if I comment out the "#undef" line, it compiles without
problem.

Or use the correct function without macro trickery

#undef GetUserName
wchar_t buffer[N];
if ( ::GetUserNameW(buffer, N)) ...

hth
Paavo

 

[Squeamizh]

(e-mail address removed):

These complaints should really go to Microsoft (not that they could or
would do much about it). Another common source of conflicting macros are
the Perl headers.

Or rename the macro

#define WinGetUserName(a,b) GetUserName(a,b)
#undef GetUserName
TCHAR buffer[N];
if (WinGetUserName(buffer, N)) ...

Does that work?  It doesn't seem to work for me.  For example:

$ cat preproc01.cpp
#define MACRO1 (i = 10)

#define MACRO2 MACRO1
#undef MACRO1

#include <iostream>

int main()
{
    int i = 100;

    MACRO1;

    std::cout << "i = " << i << '\n';

}

$ g++ preproc01.cpp
preproc01.cpp: In function 'int main()':
preproc01.cpp:12: error: 'MACRO1' was not declared in this scope

...but if I comment out the "#undef" line, it compiles without
problem.

Oops, my mistake, I misunderstood the problem. Sorry!

 

[Gennaro Prota]

What happen if you want to use same function name? Same function
names in other header files will be conflict.

For example

// Header1.h
#include<windows.h> // Microsoft uses a lot of macros.

namespace Header1 {

#undef funcName // only for example like Microsoft’s funcName()
void funcName() {…}
}

// Header2.h
namespace Header2 {
void funcName() {…}
}

#include “Header1.hâ€
#include “Header2.hâ€

int main() {
Header1::funcName();
Header2::funcName();

return 0;
}

Namespace is the answer, but C++ Compiler will fail to compile.
Why? Header files might have same function name as macros such as
Microsoft uses a lot of macros. You will have to write “#undef
funcName†before either same funcName functions in different
namespaces will work.

These complaints should really go to Microsoft (not that they could or
would do much about it). Another common source of conflicting macros are
the Perl headers.

But what? You may need to use Microsoft’s functions outside
namespace. You can’t undefined them. What is the alternation?
Rename your function names inside namespace?

Or rename the macro

#define WinGetUserName(a,b) GetUserName(a,b)
#undef GetUserName
TCHAR buffer[N];
if (WinGetUserName(buffer, N)) ...

Or use the correct function without macro trickery

#undef GetUserName
wchar_t buffer[N];
if ( ::GetUserNameW(buffer, N)) ...

You are better off not fiddling with the macro definitions. If
they used function-like macros then adding parentheses at both
the definition and the usage points would be enough:

// A solution that doesn't solve anything
//
#include <windows.h> // !!!

namespace mine_and_not_yours {

fallible< std::string >
( GetModuleFileName )()
{
return fallible< std::string >(
"I'm lazy and adding all those parentheses already"
" tired me... just look at argv[ 0 ] and cross your"
" fingers." ) ;
}

}

...

fallible< std::string > foo =
( mine_and_not_yours::GetModuleFileName )() ;


but this is *not* the case.

They *do* use function-like macros in some cases, though, e.g.
with their min/max definitions.

Note that at the call point, the parentheses also inhibit ADL,
which is something to take into account (in general, of course;
if there are no arguments or if you qualify explicitly, well...
).

All things considered, the best advice is: work out a coherent
naming scheme that avoids the conflicts in the first place.

And never include <windows.h> from an include file (please,
don't tell me that it is "difficult", "awkward" or whatever: it
can be done and has a lot of advantages).