Thread: 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'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

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?

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 { .....

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

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.

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.

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