From: thoss AT wiesbaden DOT netsurf DOT de (Marcus Thoss)
Subject: gcc STDCALL attribute
16 Nov 1996 07:11:36 -0800
Sender: daemon AT cygnus DOT com
Approved: cygnus DOT gnu-win32 AT cygnus DOT com
Distribution: cygnus
Message-ID: <328DD51D.269.cygnus.gnu-win32@wiesbaden.netsurf.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 3.0 (Win95; I)
Original-To: gnu-win32 AT cygnus DOT com
Original-Sender: owner-gnu-win32 AT cygnus DOT com

Modifying a set of win32 headers for the win32 gcc
I traced back most of the problems concerned with
COM interface declarations to the STDCALL attribute.

The STDMETHOD expands as follows in front of the
thus declared method:
virtual HRESULT STDMETHODCALLTYPE (def. in OBJBASE.H)
STDMETHODCALLTYPE itself is defined as __stdcall which
is being replaced by gcc as __attribute((__stdcall__)).

STDMETHOD is used to define COM Interface routines
which are the building blocks of OLE2 and RPC services, too.

Unfortunately, gcc(g++) 'ignores' the stdcall attribute
contained in STDMETHOD declarations, since it doesn't accept
this attribute in connection with (pure virtual, in this
case) class member functions. If you compile apps using the
COM interface headers, you'll get a rather long list
of 'attribute ''stdcall'' ignored'.

The use of stdcall is to tell the code generator not
to remove the calling arguments from the stack, but to 
leave this task to the function called.

Question: Is this problem being worked on (at cygnus, 
anywhere else in the gcc development community) ?
I would like to know if there are any basic problems
in implementing a stdcall behaviour for virtual member
functions in gcc/g++ or a hint where to look in the
scanner code inside gcc for a fix.

Hope to move development a little step towards COM support
(no personal favour for this model, though)
Marcus
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".