Re: Using GDI+ in C++
From: Larry Brasfield (donotspam_larry_brasfield_at_hotmail.com)
Date: 02/25/05
- Next message: Danilo Reinhardt: "Re: VC 7 DLL Export"
- Previous message: Scott McPhillips [MVP]: "Re: Problems with printf() and globals in multi-threaded app?"
- In reply to: Nick: "Re: Using GDI+ in C++"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 25 Feb 2005 08:30:58 -0800
"Nick" <nospam@altavente.com> wrote in message
news:e8lTVkxGFHA.2924@TK2MSFTNGP15.phx.gbl...
> WOW, thanks Larry. May I ask why this worked? if I could get some understanding of why it wasn't working I should hopefully be
> able to avoid these problems in the future...
I'm afraid that, in this case, I pulled the two necessary
facts for your fix from memory. But I can answer the
less specific question you perhaps intended.
Once, I did have to figure out why winsoc2.h has to
be included before windows.h, using a few tools that
are not quite as necessary anymore. (a Perl script to
show include ordering and nesting, which it deduced
from preprocessor output gotten via CL /E and a .exe
that extracted symbol definition info from the debug
database built with /Zi options) I used them to figure
out how to modify library or API headers.
When you merely need to use provided headers that
are improperly designed and tested, (without changing
them), the exact reason for the failures is not important;
it suffices to discover their ordering requirements. For
that purpose, today, the compiler has a few options that
aid such investigations, demonstrated below. (This was
done in the Vc7\PlatformSDK\Include subdirectory of
the Developer's Studio installation root directory, after
running Vc7\bin\vcvars32.bat to coax the compiler into
working usefully from a CLI shell.)
A useful technique for finding incorrectly ignored dependencies
is to compile a single .h file in the appropriate C or C++ mode.
This fails on line 28 of GdiPlusEnums.h:
cl /Zs /showIncludes /Tp gdiplus.h
Examination of the compiler complaint and that line show that
'UINT' is not known as a type, verified by success of:
cl /Zs /showIncludes /FIwtypes.h /Tp gdiplus.h
The same types are defined by windows.h, which you needed
anyway, so getting that include first should be enough. But,
strangely, it is not, since this fails:
cl /Zs /showIncludes /DWIN32_LEAN_AND_MEAN /FIwindows.h /Tp gdiplus.h
whereas this succeeds:
cl /Zs /showIncludes /FIwindows.h /Tp gdiplus.h
The problem with winsock2.h is a long-standing one that
most users of the modern sockets API have encountered.
The reason for it can be seen by looking at the output of:
cl /Zs /showIncludes /Tp Windows.h
where an include of winsock.h appears. This interferes with
some definitions provided by winsock2.h, as can be inferred
by looking at the complaints and using findstr.exe to locate
the definitions of the symbols mentioned in the complaints.
This interference can be verified by the failure of:
cl /Zs /showIncludes /FIWinSock.h /Tp WinSock2.h
The fix, which I call a "preemptive include", is to include
winsock2.h before windows.h gets a chance to include
the problematic winsock.h header. That this is a sortof
supported cure can be seen in winsock2.h, where it says:
#define _WINSOCKAPI_ /* Prevent inclusion of winsock.h in windows.h */
Apparently, the author(s) of that header preferred that
kludge over a more comprehensive fix involving windows.h,
which likely were deemed untouchable for various reasons.
-- --Larry Brasfield email: donotspam_larry_brasfield@hotmail.com Above views may belong only to me.
- Next message: Danilo Reinhardt: "Re: VC 7 DLL Export"
- Previous message: Scott McPhillips [MVP]: "Re: Problems with printf() and globals in multi-threaded app?"
- In reply to: Nick: "Re: Using GDI+ in C++"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
