«

what is the diffrence between

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

于 Sat, 30 Aug 2008 20:22:47 -0700，raashid bhatt写到：

> what is the diffrence between
>
> typedef void (__cdecl *PyClean)(void); void (__cdecl *PyClean)(void);

The first PyClean is one function pointer type,
The second one is one Function pointer.

It means that you can use PyClean pcFunc1; with the first one.
But it can not be used with the second one.

raashid bhatt <> 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.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

"Keith Thompson" <kst-> wrote in message
news:...
> raashid bhatt <> 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).

....

In article <eafa8$48ba7c6a$7937d7da$>,
cr88192 <> wrote:

>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, ...

You're only likely to encounter it if you use an x86 compiler
*on MS Windows*. I have compiled C programs on a variety of
x86 systems for many years, and never saw it until someone tried
to compile my code on Windows and added a whole bunch of clutter
to all my .h files.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

cr88192 wrote:
> "Keith Thompson" <kst-> wrote in message
> news:...
>> raashid bhatt <> 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.
>
> 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, ...

By virtue of having two leading underscores, __cdecl is in the namespace
reserved to implementations and, without naming the specific
implementation used, we cannot make any assumptions about what it means
-- and if named, it would still be off-topic.

<OT>However, all of us know that it's almost certainly to be a common
extension that specifies the calling convention used by a function, like
__stdcall and _fastcall, usually only encountered on Windows systems but
sometimes available on other x86 systems. That has no bearing on the
OP's question about "typedef", though.</OT>

S

cr88192 wrote:
> "Keith Thompson" <kst-> wrote in message
> news:...
>> raashid bhatt <> 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, ...
>
Well I've been using x86 for a very long time and I've certainly never
used it.

> actually, I doubt there is any real major compilers for x86 that don't know
> these keywords,

None on the x86 systems I use do.

--
Ian Collins.

cr88192 wrote:
....
> 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, ...

It's not supported in default mode by the gcc compiler installed on the
intel x86 machines I use at work, nor the x86_64 machine I have at home.
"info gcc" doesn't give me any information about it. If I need a special
command line option to turn it on, I don't know which option that is.

I won't pretend ignorance of the keyword, but I am unfamiliar with it,
I've had no reason to even think about it in more than a decade.

"Richard Heathfield" <> wrote in message
news:ltednU4af-...
> Ian Collins said:
>
>> cr88192 wrote:
>
> <snip>
>
>>> 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, ...
>>>
>> Well I've been using x86 for a very long time and I've certainly never
>> used it.
>
> Right. It's not actually necessary. It once occurred to me to bother to
> find out what it means, so I did, and it sounded terribly, terribly dull
> and pointless - so I didn't bother to remember it.
>

it does matter a lot to people who write compilers though...


>>> actually, I doubt there is any real major compilers for x86 that don't
>>> know these keywords,
>>
>> None on the x86 systems I use do.
>
> ISTR that MSVC litters its headers with _cdecl, but C programmers are
> under
> no obligation whatsoever to follow suit.
>

unless of course, one is writing libraries, or they feel inclined to use the
__stdcall convention (generally expected for most libraries with a DLL based
interface).

> --
> Richard Heathfield <http://www.cpax.org.uk>
> Email: -http://www. +rjh@
> Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
> "Usenet is a strange place" - dmr 29 July 1999

"James Kuyper" <> wrote in message
news:OyIuk.196$1a2.169@trnddc04...
> cr88192 wrote:
> ...
>> 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, ...
>
> It's not supported in default mode by the gcc compiler installed on the
> intel x86 machines I use at work, nor the x86_64 machine I have at home.
> "info gcc" doesn't give me any information about it. If I need a special
> command line option to turn it on, I don't know which option that is.
>
> I won't pretend ignorance of the keyword, but I am unfamiliar with it,
> I've had no reason to even think about it in more than a decade.

well, x86!=x86_64, I would be surprised if they work on x86-64...

now, it sounds to me like maybe you are using something like Linux, which
does not normally use these keywords, none the less, gcc itself has them for
the reason that they are needed for it to target Windows...