Function name clash?

Printable View

05-20-2008
sethjackson

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()?
05-20-2008
MarkZWEERS

I have found this online: http://www.tilander.org/aurora/2008/...-windowsh.html
05-20-2008
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
05-20-2008
sethjackson

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. :(
05-20-2008
MarkZWEERS

Creating your own namespace would be a solution?
05-20-2008
sethjackson

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 { .....
05-20-2008
matsp

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
05-20-2008
sethjackson

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!!
05-20-2008
Daved

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

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.
05-21-2008
grumpy

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.
05-21-2008
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.
05-21-2008
matsp

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
05-21-2008
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.
05-21-2008
matsp

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
05-21-2008
Elysia

However, if they let that one out of the headers, it would break legacy code, so I fail to see why they should let it outside.
Even if there was a legitimate reason to do it, on today's compilers, they can fix that mistake now. It's bad enough that the Windows API is C. Let's now screw up users C/C++ applications.
05-21-2008
matsp

Quote:

Originally Posted by Elysia

However, if they let that one out of the headers, it would break legacy code, so I fail to see why they should let it outside.
Even if there was a legitimate reason to do it, on today's compilers, they can fix that mistake now. It's bad enough that the Windows API is C. Let's now screw up users C/C++ applications.

No, it doesn't break anything. Yield is no longer available in new code-format. If you compile with a new Windows.h, then you get the new Yield. The actual Yield function only works in 16-bit .EXE's, so it would be clearly b0rken to expect a 32-bit app to run on a 16-bit system. So nothing is broken. It's just a way to remove a function that used to exist. It helps people porting old 16-bit apps to Windows 32-bit mode [not that it's likely to occur very often these days].

--
Mats
05-21-2008
grumpy

Apart from the minor point that static inline functions are not supported in older versions of C, declaring a function as static inline can still introduce name clashes.

In the real world, companies like Microsoft come under more pressure to maintain backward compatibility (eg keep old code in header files that will work with old code) than they do from people who insist they must use the latest and greatest language features.

Corporate or government customers of companies like Microsoft often stick with older versions of compilers, etc that work and only upgrade if their are compelling business reasons to upgrade (the enjoyment of programmers being able to use modern language constructs is rarely a compelling business argument, and good programmers are productive whether they are allowed to use modern code constructs or not). The larger customers then tend to insist that any newer compilers maintain support of their old code without modification (as the cost of modernising old code is significant, and offers relatively few business benefits). Those customers give significant push-back if compatibility with old compilers is lost.

Large business clients tend to carry more weight than individuals, meaning a disincentive to lose backward compatibility. Business wise, it also makes sense for Microsoft to maintain one version that works rather than multiple versions that might break sometimes. In practice, that means headers like <windows.h> support the lowest common denominator -- vanilla C code, few if any C++ extensions, extensions that are common to all Microsoft compilers, use of macros, etc.

Does it mean that Microsoft attaches less priority to the programmers who want to use all the latest features? Sure. Those programmers tend to be a minority, and don't have the economic clout -- and Microsoft is not in business to provide services unless they profit from it. The pragmatic approach is to work within limitations (eg if you use <windows.h> pick names to avoid clashes) rather than insisting on large vendor like Microsoft supporting features (eg new pragmas) that benefit a minority. Unless, of course, you're willing to PAY Microsoft enough to make it worthwhile to support your features.