Re: diffrence?




"Keith Thompson" <kst-u@xxxxxxx> wrote in message
news:ln1w051tbl.fsf@xxxxxxxxxxxxxxxxxx
raashid bhatt <raashidbhatt@xxxxxxxxx> writes:
what is the diffrence between

typedef void (__cdecl *PyClean)(void);
void (__cdecl *PyClean)(void);

Ignoring the "__cdecl", the first declared PyClean as an alias for the
type "void (*)(void)" (pointer to function with no parameters
returning void), and the second declares PyClean as an object of that
type.

"__cdecl" is probably a compiler-specific extensions. To find out
what it means, you'll need to consult the documentation for your
compiler. It's not a standard C feature.

What is the real question behind this question? Did you not know what
"typedef" means? The "Py" prefix leads me to suspect this has
something to do with Python; if so, comp.lang.python might be a better
place to ask -- though I'm sure they'll want more context than you've
provided.


you don't know what __cdecl is?...

well, maybe not, since it requires using one of the many compilers that
target, of all archs, x86... with such obscure names as, gcc, msvc, intel,
watcom, ...

actually, I doubt there is any real major compilers for x86 that don't know
these keywords, the reason being that, at least on Windows, there are
several different calling conventions in use (__cdecl, __stdcall, ...) and
it is necessary for the compilers to know these in order to be able to deal
with the system headers (where different libraries may be compiled to use
different calling conventions). programmers have to deal with these issues
periodically due to minor incompatibilities (function pointers using one
convention not being directly passable to libraries using another, ...).
typically, at least one of these is present in each and every declaration in
the system headers. otherwise, it is left purely up to the compiler to pick
which convention to use as the default, though __cdecl is most common, which
is also, more or less, the convention typically used on Linux and MacOS (I
think MacOS makes a slight tweak, and requires call frames to be aligned on
a 16-byte boundary, ... as well as other slight variances between compilers
and OS's).

since most of these compilers are cross platform, it is likely these
keywords still work on OS's like Linux or MacOS as well (albeit there is
much less reason for using them on these archs).

....



.



Relevant Pages

  • Re: x86 Stack Confusion
    ... on the x86 platform the convention exists that is adhered to ... even when you vary compilers on each side. ... typical Pascal compilers for x86 from yester year used another ...
    (comp.lang.c)
  • Re: GNAT parameter passing, C-style?
    ... > It's not a misunderstanding, it's part of the C standard spec and ... > compilers still do it. ... No. IBM and Microsoft for example went to what you call "Pascal" convention ...
    (comp.lang.ada)
  • Re: File Extension Association in Solaris
    ... Compilers generally allow multiple file types to be passed as arguments; ... extensions; it's merely a convention. ... convention; it's just part of the string that names the file. ... to opinions held by my employer, Sun Microsystems. ...
    (comp.sys.sun.admin)
  • Re: "C" calling convention on x86
    ... Scott Moore wrote: ... >> convention does not depend on what compiler or mode. ... It may use registers. ... > are even compilers that pass the parameters in fixed global locations. ...
    (comp.lang.asm.x86)
  • Re: C programming on ARM
    ... It's a fair point that there is a difference what you can rely on for real, practical C and what the standards say. ... right shifts working as expected, division rounding as expected, char ... Aside from alignment problems (which may mean that using the pointer does not "just work", even if conversions back and forth do), ... You can't rely on these things having a consistent pointer size - you should not even rely on the C requirement of a "void *" supporting them all (embedded compilers don't always follow the standards if they conflict with generating good object code for real-world source code). ...
    (comp.arch.embedded)