Function name clash?

This is a discussion on Function name clash? within the C++ Programming forums, part of the General Programming Boards category; Hey I have this code: Code: #include <windows.h> class Thread { private: //.... public: //..... static void Yield(); }; GCC ...

  1. #1
    Registered User
    Join Date
    Aug 2005
    Posts
    96

    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()?
    Last edited by sethjackson; 05-20-2008 at 12:12 PM.

  2. #2
    Registered User
    Join Date
    May 2008
    Location
    Paris
    Posts
    248

  3. #3
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  4. #4
    Registered User
    Join Date
    Aug 2005
    Posts
    96
    Quote Originally Posted by MarkZWEERS View Post
    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.

  5. #5
    Registered User
    Join Date
    May 2008
    Location
    Paris
    Posts
    248
    Creating your own namespace would be a solution?

  6. #6
    Registered User
    Join Date
    Aug 2005
    Posts
    96
    Quote Originally Posted by matsp View Post
    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 View Post
    Creating your own namespace would be a solution?
    I have, it still doesn't work.

    Thread is inside:

    namespace Foo
    {
    namespace Bar { .....
    Last edited by sethjackson; 05-20-2008 at 12:45 PM.

  7. #7
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by MarkZWEERS View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  8. #8
    Registered User
    Join Date
    Aug 2005
    Posts
    96
    Quote Originally Posted by matsp View Post
    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!!

  9. #9
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    I would rename my function. That way you don't have to worry about it in files that call that function.

  10. #10
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by Daved View Post
    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.

  11. #11
    Registered User
    Join Date
    Jun 2005
    Posts
    6,174
    Quote Originally Posted by brewbuck View Post
    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.

  12. #12
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  13. #13
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  14. #14
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    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 Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  15. #15
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Elysia View Post
    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
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Seg Fault in Compare Function
    By tytelizgal in forum C Programming
    Replies: 1
    Last Post: 10-25-2008, 03:06 PM
  2. Another syntax error
    By caldeira in forum C Programming
    Replies: 31
    Last Post: 09-05-2008, 01:01 AM
  3. In over my head
    By Shelnutt2 in forum C Programming
    Replies: 1
    Last Post: 07-08-2008, 06:54 PM
  4. Replies: 28
    Last Post: 07-16-2006, 11:35 PM
  5. const at the end of a sub routine?
    By Kleid-0 in forum C++ Programming
    Replies: 14
    Last Post: 10-23-2005, 06:44 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21