This is the mail archive of the firstname.lastname@example.org
mailing list for the Cygwin project. See the Cygwin
home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]
Re: Win32 Defines & C++
- To: Nirmal Prasad <email@example.com>
- Subject: Re: Win32 Defines & C++
- From: Mumit Khan <firstname.lastname@example.org>
- Date: Wed, 24 Mar 1999 11:13:48 -0600 (CST)
- cc: email@example.com
- Delivered-To: firstname.lastname@example.org
- Delivered-To: mailing list email@example.com
- In-Reply-To: <001701be7609$ef953970$0f0a0181@devel014>
- Mailing-List: contact firstname.lastname@example.org; run by ezmlm
- Sender: email@example.com
On Wed, 24 Mar 1999, Nirmal Prasad wrote:
> This is not a cygwin related query,bug or feature request but if someone can
> help it will be great b'cos i am getting this problem in some code that i
> have while compiling under cygwin.
Neither is this a GCC problem, since you'll get the same result with MSVC
or any other C++ compiler!
> The problem i am facing is that i have some c++ class that has a member
> function which is the same as a win32 define (e.g. GetNextWindow). The
> problem is that the pre-processor substitues this and the compiler complains
> that there is something wrong. One of the solutions i thought of getting
> around this is to make the #define'd macro to an inline function and the
> code would then compile but this would be tedious if its a lot of macros . I
> was wondering if there is any other elegant solution such that i dont have
> to change any code.????
The problem of these macro definitions in Win32 API headers causes lots
of problems even in standard-conformant code; the only (obvious) suggestion
I can give is not to name member functions with the same name as a win32
API function (or just rename it when you find one that clashes).
The API headers were designed by folks who think C is the only language,
and even botches that badly.
Years ago, I remember putting together a set of platform specific
"undef.h" files that I would include after the system includes to avoid
this mess, but that really isn't the right solution. However, since you
want to avoid code changes, this may be a solution for you.
Want to unsubscribe from this list?
Send a message to firstname.lastname@example.org