views:

59

answers:

3

This has actually occurred twice now. I'm writing a cross-platform application, and some of my function names conflict with the Windows API. What I did (for example with LoadObject) was...

#undef GetObject

Is this an okay approach, or should I rename my functions?

A: 

If you're working with C++ you should put your functions into classes and namespaces to avoid these sort of problems (a.k.a methods).

dtroy
It is a private method. Still occurred. Understand though, have a good idea of an approach to take. Thanks.
person
The problem is that many (or most) Win32 APIs are really macros that define to an ANSI or Unicode variant of the underlying API. And the macro "namespace" doesn't care one little bit about the C++ namespace or class scope.
Michael Burr
You're Absolutely right. He should rename the methods too.
dtroy
Windows defines `LoadObject` as `LoadObjectA` or `LoadObjectW` for unicode builds. Of course, you can `#undef` the conflicting definitions (inside `#ifdef _WIN32` block, of course), but I think the following rule is better: either you stay away from platform-defined names, or you separate the bulk of your application as a library that never includes Windows, and then use these names freely.
Alex Emelianov
+1  A: 

You could put your functions in a namespace or a class (if applicable). If you are calling within a class then remember the this keyword. this->aliasedFunction();

Kyle
The problem is that the Windows API defines most of its names as macros, which don't respect namespaces or classes.
James McNellis
+1  A: 

If you intend for your code to be used alongside of the Windows API, I'd recommend renaming the functions. Yes, that's a hassle, but it's (in my opinion) better than undefining parts of the Windows API, even if you don't use those parts (someone else using your code might need to use those parts).

James McNellis
Alright, and thanks for the info on the Win API defining its names as macros.
person