Function name clash?

Hey I have this code:

Code:

---

#include <windows.h>

class Thread
{
private:
   
    //....

public:

    //.....

    static void Yield();
};

---

GCC gives me these errors:

#1. Thread.hpp:line#: error: declaration does not declare anything
-> this is the line "Yield()" is on

#2. Thread.cpp:line#: error: expected unqualified-id before '{' token
-> this is the line "void Thread::Yield()" is on

#3. Thread.cpp:line#: error: invalid function declaration
-> this is the line "void Thread::Yield()" is on

I think this happens because of the <windows.h> header....
Anyways, why do the errors occur and how do I fix them?

I mean why does Thread::Yield() conflict with Yield()?

I have found this online: http://www.tilander.org/aurora/2008/...-windowsh.html

I'm pretty sure this is because there is a Yield() function in Windows 3.1, which is no longer needed in modern Windows, and there is a

Code:

---

#define Yield()

---

If I compile this:

Code:

---

#include <windows.h>

int Yield();

---

It becomes this:

Code:

---

//<snip lots of stuff from Windows.h>
# 115 "m:/epoc32/gcc_mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h" 2 3
# 2 "win.c" 2

int ;

---

So the "Yield()" went missing.

Unfortunately, I can't find which part of the rather complex set of headers that Windows.h drags in that actually does this define.

--
Mats

Quote:

---

Originally Posted by MarkZWEERS

I have found this online: http://www.tilander.org/aurora/2008/...-windowsh.html

---

Thanks, but my code is inside TWO namespaces, and it still doesn't work!?

Yeah I'll have to agree with that blog post windows.h is the worst header ever. :(

Creating your own namespace would be a solution?

Quote:

---

Originally Posted by matsp

I'm pretty sure this is because there is a Yield() function in Windows 3.1, which is no longer needed in modern Windows, and there is a

Code:

---

#define Yield()

---

If I compile this:

Code:

---

#include <windows.h>

int Yield();

---

It becomes this:

Code:

---

//<snip lots of stuff from Windows.h>
# 115 "m:/epoc32/gcc_mingw/bin/../lib/gcc/mingw32/3.4.2/../../../../include/windows.h" 2 3
# 2 "win.c" 2

int ;

---

So the "Yield()" went missing.

Unfortunately, I can't find which part of the rather complex set of headers that Windows.h drags in that actually does this define.

--
Mats

---

Perhaps #undef Yield() might work?

Quote:

---

Originally Posted by MarkZWEERS

Creating your own namespace would be a solution?

---

I have, it still doesn't work.

Thread is inside:

namespace Foo
{
namespace Bar { .....

Quote:

---

Originally Posted by MarkZWEERS

Creating your own namespace would be a solution?

---

No, it's not a namespace issue.
I just found this in winbase.h, line 2019:

Code:

---

#define Yield()

---

If you do:

Code:

---

#undef Yield

---

after windows.h, it should solve the problem.

--
Mats

Quote:

---

Originally Posted by matsp

No, it's not a namespace issue.
I just found this in winbase.h, line 2019:

Code:

---

#define Yield()

---

If you do:

Code:

---

#undef Yield

---

after windows.h, it should solve the problem.

--
Mats

---

Heh yep. Thanks mats!!

I would rename my function. That way you don't have to worry about it in files that call that function.

Quote:

---

Originally Posted by Daved

I would rename my function. That way you don't have to worry about it in files that call that function.

---

What Daved is suggesting might make you say:

"Oh my God, that sucks."
or...
"That's the stupidest thing I've ever heard."

Both are true. It's still probably the right solution. You just have to adjust to the fact that Microsoft doesn't give a crap about your problems and will gleefully stomp all over you. Obsoleting the Yield() function by #defining it into nothingness is utterly wrong, but it's what they've given you.

Quote:

---

Originally Posted by brewbuck

Both are true. It's still probably the right solution. You just have to adjust to the fact that Microsoft doesn't give a crap about your problems and will gleefully stomp all over you. Obsoleting the Yield() function by #defining it into nothingness is utterly wrong, but it's what they've given you.

---

While I'm not exactly shy about criticising Microsoft, your criticism is unfair, brewbuck.

A basic rule of life with the C/C++ preprocessors is that macros can interact with code in unexpected ways and it is necessary to cope when they do. You would also get other strange (but different) effects if that header file declares types, variables, or functions with the same names as entities in your code i.e. you still need to cope.

No vendor can provide useful material in a header file (eg for a library) without the risk of clashing with user code: all useful header files #define macros and/or declare things. So, if you employ a vendor specific header file (like <windows.h>) it is your responsibility to work around any clashes that occur. It is not the vendor's responsibility to ensure that there can never be a clash with arbitrary user code - because it is technically impossible to make such a universal guarantee.

Criticising a vendor for not achieving the technically impossible is always unfair.

However, at the same time, defining a common function name was a pretty poor move on Microsoft's part. Their IDE supports #pragmas, to deprecate and whatnot, so it would be better to use those instead.

Quote:

---

Originally Posted by Elysia

However, at the same time, defining a common function name was a pretty poor move on Microsoft's part. Their IDE supports #pragmas, to deprecate and whatnot, so it would be better to use those instead.

---

Or simply something like this:

Code:

---

static inline void Yield(void) {}

---

Then it's in the public namespace, doesn't do anything [can be removed by the compiler].

But I suspect it's got hysterical reasons for being the way it is.

--
Mats

Or perhaps both ways! And inline static function plus deprecated pragmas.
No matter what reasons they were, if you ask me, doing a define like that is simply inexcusable, especially when it leaks out from the headers. They can define it within the actual headers, sure, but when the headers stop, it should be undefined again.

Quote:

---

Originally Posted by Elysia

Or perhaps both ways! And inline static function plus deprecated pragmas.
No matter what reasons they were, if you ask me, doing a define like that is simply inexcusable, especially when it leaks out from the headers. They can define it within the actual headers, sure, but when the headers stop, it should be undefined again.

---

Well, the whole point of the define is to make the old Yield function for Windows 3.x to compile into nothing, since it was part of the 3.x API (and had a meaning therem, namely to let other processes run), but when the Win32/Win95/NT API came about, it lost it's purpose and needed to be removed. Since some code would call this quite often, even having a dummy function would lead to a bit of overhead. And the point when this was done was perhaps before inline of empty functions would be removed if the function was empty? [I wasn't there when they decided to do this].

--
Mats