By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,805 Members | 1,056 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,805 IT Pros & Developers. It's quick & easy.

Calling convention: is __cdecl cross-platform?

P: n/a
VC has a __cdecl specifier which allows functions and methods to
be called with varying parameter count.

(I understand this is the default for functions in general but in VC,
instances use another convention unless they have an ellipsis
argument.)

I can force GCC and other compilers to use such a convention by
declaring all methods with an ellipsis, but I'd rather not clutter my
method definitions with these.

So, is the __cdecl specifier generally available in some form
(at least on GCC with different CPU types, Mac compilers)
or do I need the ellipsis?

Why I want it:

I'm designing simple plugin model for using C++ plugins in
an interpreted language. I need to handle method calls with
generic code.

It is to be used on MSW as well as embedded Linux.

I know the Qt framework uses a similar technique for its
slot/signal dispatch mechanism - general functions are defined
which take an object and 9 parameters. But I don't know how
Qt makes this work on various compilers.
Oct 27 '08 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Ole Nielsby wrote:
VC has a __cdecl specifier which allows functions and methods to
be called with varying parameter count.
So, is the __cdecl specifier generally available in some form
(at least on GCC with different CPU types, Mac compilers)
or do I need the ellipsis?
I'm designing simple plugin model for using C++ plugins in
an interpreted language. I need to handle method calls with
generic code.
Rather than passing variable-length argument lists, why not just pass
standard collections of arguments, e.g. in std::vectors?
Oct 27 '08 #2

P: n/a
Jeff Schwab <je**@schwabcenter.comwrote:
Ole Nielsby wrote:
>VC has a __cdecl specifier which allows functions and methods to
be called with varying parameter count.
>So, is the __cdecl specifier generally available in some form
(at least on GCC with different CPU types, Mac compilers)
or do I need the ellipsis?
>I'm designing simple plugin model for using C++ plugins in
an interpreted language. I need to handle method calls with
generic code.

Rather than passing variable-length argument lists, why not just pass
standard collections of arguments, e.g. in std::vectors?
I want to keep the C++ plugins close to normal C++ style so
that my C++ trained colleagues can create the plugins easily.

Therefore, the plugin host must translate between
as-normal-as-possible C++ style calls and interpreted calls.

The host is compiled without specific knowledge of the signatures
of the plugins.

Frameworks like UNO, COM, Qt... do this. I know Qt uses a
dummy-argument technique, and that's what I intend to do too.
I just need to be sure a caller-pops calling convention is used
for methods - preferably without using the ellipsis in the method
parameters of the plugins.
Oct 27 '08 #3

P: n/a
Ole Nielsby wrote:
Jeff Schwab <je**@schwabcenter.comwrote:
>Ole Nielsby wrote:
>>VC has a __cdecl specifier which allows functions and methods to
be called with varying parameter count.
So, is the __cdecl specifier generally available in some form
(at least on GCC with different CPU types, Mac compilers)
or do I need the ellipsis?
I'm designing simple plugin model for using C++ plugins in
an interpreted language. I need to handle method calls with
generic code.
Rather than passing variable-length argument lists, why not just pass
standard collections of arguments, e.g. in std::vectors?

I want to keep the C++ plugins close to normal C++ style so
that my C++ trained colleagues can create the plugins easily.
Passing a statically typed container by reference is "normal C++ style."
Circumventing the formal type system (e.g. with ellipses) is unusual.
Therefore, the plugin host must translate between
as-normal-as-possible C++ style calls and interpreted calls.
Right, so far so good. Shouldn't the host know, when it is compiled,
how many arguments each plugin function will expect? Plugins typically
have to conform to a fairly stringent API so that the host will know how
to invoke them.
The host is compiled without specific knowledge of the signatures
of the plugins.
It doesn't need to be too specific, but the quantity of arguments
expected by each function is pretty fundamental.

How about this: If the host provides a function template (rather than a
raw function) for registering the callbacks, then the static type of
each callback will be available to the host, and the number of arguments
can be gathered implicitly as part of the registration. Rather than
just registering a function pointer, the template instantiation (which
knows from the static type system how many arguments the callback
expects) can call an underlying registration function with both the
callback function's address and the number of arguments expected.
Frameworks like UNO, COM, Qt... do this. I know Qt uses a
dummy-argument technique, and that's what I intend to do too.
The only one of those I've used is Qt, and I'm not aware of it using any
kind of "dummy-argument technique." Qt uses a heavyweight preprocessor
(moc) to collect information about function signature before the C++ is
even compiled. The per-signal/slot signature information has to be
maintained at run-time by member lists of the relevant QObjects; that's
why you can only use the signal/slot mechanism with QObjects. It's a
slow, memory-hungry, error-prone technique; for example, the "types" of
function parameters are represented solely by the strings in the
function declarations, without any regard for context. If different
strings are used in the signal and slot declarations (e.g. to use local
typedefs), Qt gets confused. Qt also delays the parameter matching
until the signal/slot connections are attempted, at run-time, so you get
signal/slot mismatch errors at run-time that should have been caught at
compile-time. If you really want to go that route, be very sure you've
got test coverage for every possible connection. (Of course, that would
be difficult, since you're writing a plugin architecture.)
I just need to be sure a caller-pops calling convention is used
for methods - preferably without using the ellipsis in the method
parameters of the plugins.
That's an awfully low-level set of details to be worrying about for
something as high-level as a plugin architecture, which by its nature
should probably be defined as abstractly as possible (so that a wide
variety of client code will work with it).
Oct 27 '08 #4

P: n/a
Ole Nielsby wrote:
VC has a __cdecl specifier which allows functions and methods to
be called with varying parameter count.

(I understand this is the default for functions in general but in VC,
instances use another convention unless they have an ellipsis
argument.)

I can force GCC and other compilers to use such a convention by
declaring all methods with an ellipsis, but I'd rather not clutter my
method definitions with these.

So, is the __cdecl specifier generally available in some form
(at least on GCC with different CPU types, Mac compilers)
or do I need the ellipsis?
No, it's windows specific.

--
Ian Collins
Oct 27 '08 #5

P: n/a
Jeff Schwab <je**@schwabcenter.comwrote:
Ole Nielsby wrote:
>Jeff Schwab <je**@schwabcenter.comwrote:
>>Ole Nielsby wrote:
VC has a __cdecl specifier which allows functions and methods to
be called with varying parameter count.
So, is the __cdecl specifier generally available in some form
(at least on GCC with different CPU types, Mac compilers)
or do I need the ellipsis?
I'm designing simple plugin model for using C++ plugins in
an interpreted language. I need to handle method calls with
generic code.
Rather than passing variable-length argument lists, why not just pass
standard collections of arguments, e.g. in std::vectors?

I want to keep the C++ plugins close to normal C++ style so
that my C++ trained colleagues can create the plugins easily.

Passing a statically typed container by reference is "normal C++ style."
Circumventing the formal type system (e.g. with ellipses) is unusual.
A statically typed container is fine if the elements have the same
type, which is not the case here.

Circumventing the type system may be unusual in C++ programming
in general, but when interfacing with dynamically typed languages, it's
bread and butter. Many component systems work that way.
>Therefore, the plugin host must translate between
as-normal-as-possible C++ style calls and interpreted calls.

Right, so far so good. Shouldn't the host know, when it is compiled, how
many arguments each plugin function will expect? Plugins typically have
to conform to a fairly stringent API so that the host will know how to
invoke them.
But I'm going for a generic plugin mechanism. The APIs of individual
plugins are specified by a simple IDL which is interpreted by the host.
(Perhaps I should call it a "lightweight component mechanism".
>The host is compiled without specific knowledge of the signatures
of the plugins.

It doesn't need to be too specific, but the quantity of arguments expected
by each function is pretty fundamental.

How about this: If the host provides a function template (rather than a
raw function) for registering the callbacks, then the static type of each
callback will be available to the host, and the number of arguments can be
gathered implicitly as part of the registration. Rather than just
registering a function pointer, the template instantiation (which knows
from the static type system how many arguments the callback expects) can
call an underlying registration function with both the callback function's
address and the number of arguments expected.
I'm having trouble understanding this.

The host and the plugin are compiled as separate projects. In which
of these would the callback registration function template be
instantiated?

If it is instantiated in the host, the host would have to be recompiled
when a new type of plugin is added, and this is precisely what I
want to avoid. The host is agnostic of the details of the plugin
interfaces until it gets the IDL at run time.

If its' instantiated in the plug - well, the template would either have
to construct a middleware layer between the plug and a generic
interface in the host, or somehow pass the type information to
the host in a format the host can interpret.

The "middleware layer" is above my template metaprogramming
skills - I think the PyBoost library does something like that but
I haven't found a description of the technique I understand.

The "type information passing" would not differ much from the
IDL based solution on the host side.
>Frameworks like UNO, COM, Qt... do this. I know Qt uses a
dummy-argument technique, and that's what I intend to do too.

The only one of those I've used is Qt, and I'm not aware of it
using any kind of "dummy-argument technique."
If you check the QMetaObject Class Reference
http://doc.trolltech.com/4.4/qmetaobject.html
you'll find invocation methods that use dummy arguments.
I don't know for sure but it's my understanding that the
signal/slot mechanism uses these methods.
Qt [...] signal/slot mechanism [is] a slow, memory-hungry,
error-prone technique.
Agree, and I don't intend to copy it. I have much faster and safer
ways of doing the dynamic calls. I'm just having a problem with
dummy parameters and calling conventions.
>I just need to be sure a caller-pops calling convention is used
for methods - preferably without using the ellipsis in the method
parameters of the plugins.

That's an awfully low-level set of details to be worrying about
for something as high-level as a plugin architecture, which by
its nature should probably be defined as abstractly as possible
(so that a wide variety of client code will work with it).
"As abstractly as possible" may be fine when you combine things
at compile time, in an all C++ setting. But under the conditions
of having a host that is compiled to executable code without
knowledge of the plug API details, a low level interface is
required.

Btw what led me to design the plugin scheme was this case:

A collegue of mine implemented a glucose level simulation for
diabetes patients using Mathlab and some tools that produced
C code. I implemented a GUI for it using my interpreted PILS
language which comes with bindings to the juce GUI framework.
To make it work in a rush, I wrapped the glucose model C
code in a C++ class and fed it to the homebrew interface
generator I used to interface PILS to juce, and compiled it
into the PILS interpreter. But it doesn't really make sense
that my PILS language - which is rather general-purpose
- should come with a glucose simulation - and the app
shows some weird compiler- and optimization dependent
problems (oddly enough, with VC2008/WinXP, debug mode
works fine but release mode needed some optimizations turned
off for it to work, with GCC/Ubuntu, debug mode is flawed but
release mode works fine - this would be easier to diagnose if I
could compile and test the plugin separately.) ... so I need a
plugin system. I investigated UNO, Ice... but they are too
heavyweight, we want to be able to deploy on wrist watches
etc. so I need something light.
Oct 27 '08 #6

P: n/a
On Oct 27, 11:06 am, "Ole Nielsby"
<ole.niel...@tekare-you-spamminglogisk.dkwrote:
VC has a __cdecl specifier which allows functions and methods
to be called with varying parameter count.
__cdecl is not part of C++ (as it's name indicates---names
starting with __ are in the implementor's namespace). Anything
you do using __cdecl is pure VC++: compiled with VC++, it works
as Microsoft specified, and it probably can't be compiled with
any other compiler.
(I understand this is the default for functions in general but
in VC, instances use another convention unless they have an
ellipsis argument.)
You understand wrong. Unless the function parameter list ends
with an elipsis, you must call it with the number and type of
arguments indicated.
I can force GCC and other compilers to use such a convention
by declaring all methods with an ellipsis, but I'd rather not
clutter my method definitions with these.
A lot of compilers (including g++, I think, at least under Linux
or Solaris) only support one calling convention. And use that
convention regardless of whether there is an ellipsis or not, or
whether the function is ``extern "C"'' or not. Other compilers
may change the convention according to the langauge---I've used
compilers which used a different convention for C and C++.
So, is the __cdecl specifier generally available in some form
(at least on GCC with different CPU types, Mac compilers) or
do I need the ellipsis?
It depends on what you want to do. If you want to pass a
variable number of arguments, you need the elipsis.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Oct 28 '08 #7

This discussion thread is closed

Replies have been disabled for this discussion.