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 <raashidbhatt@gmail.comwrites:

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-u@mib.org <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"

In article <eafa8$48ba7c6a$7937d7da$23811@saipan.com>,
cr88192 <cr88192@NOSPAM.hotmail.comwrote:

>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-u@mib.orgwrote in message
news:ln1w051tbl.fsf@nuthaus.mib.org...

>
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-u@mib.orgwrote in message
news:ln1w051tbl.fsf@nuthaus.mib.org...

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

Ian Collins said:

cr88192 wrote:

<snip>

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.

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

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

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" <rjh@see.sig.invalidwrote in message
news:ltednU4af-7KnSbVnZ2dnUVZ8qfinZ2d@bt.com...

Ian Collins said:
>

>
<snip>
>

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

>
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" <jameskuyper@verizon.netwrote in message
news:OyIuk.196$1a2.169@trnddc04...

cr88192 wrote:
...

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

cr88192 wrote:

"James Kuyper" <jameskuyper@verizon.netwrote in message
news:OyIuk.196$1a2.169@trnddc04...

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

I wasn't sure whether you'd consider x86_64 as a special case of x86. My
own code has no need to worry about the differences between x86 and
x86_64 - it's written to perform the same operations in either case.

now, it sounds to me like maybe you are using something like Linux,

Good guess! Not all of the world (not even all of the x86 world) is a
Windows.

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

I can't find any mention of them in "info gcc", though it mentions many
other features that are Windows specific.

"Stephen Sprunk" <stephen@sprunk.orgwrote in message
news:54Auk.38851$ZE5.25232@nlpi061.nbdc.sbc.com...

cr88192 wrote:

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

only if one sticks by this certain fantasy in these parts, that one uses C
apart from computers...

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

yes, I was not trying to imply that it was particularly relevant, more just
complaining about the apparent ignorance of this keyword on the part of the
person responding (to me, this comming off as a fair deal of ignorance as to
what it is actual coders are faced with...).

real world code involves many such things, and it is generally good to know
them, of all things, so that the code actually works, and is capable of
doing all these mundane tasks that people here like to regard as
"impossible...".


it is analogous to me of like:
a biologist who is ignorant of centrifuges (or considers that the actual
practice of using tools and actual organisms to study biology is below
them);
an automotive specialist who does not know about things like socket sets, or
about the difference between socket for hand-driven wrenches and impact
sockets (or thinks it is demeaning to actually work on cars);
....


abstractions apart from the reality is, IMO, distasteful.

but, then again, this could just be my ExTJ side showing...

S

cr88192 wrote:

"Richard Heathfield" <rjh@see.sig.invalidwrote in message
news:ltednU4af-7KnSbVnZ2dnUVZ8qfinZ2d@bt.com...

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

Only Windows compilers.

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

<OT>
AFAIK, Windows/x86 is the only (today, at least) platform where multiple
calling conventions are widely used. This is because Microsoft, in its
infinite wisdom, decided that the Windows API would use the Pascal
calling convention (which they called __stdcall), while many programs
and libraries use the normal C calling convention (which MS called
__cdecl) for everything else. Some compilers can be set to either one
as the default, so functions in the headers of libraries distributed to
others are usually declared one or the other to prevent problems.

If any of the above is incorrect, that just shows _why_ this is OT for
comp.lang.c and should be discussed on a MSWindows-specific newsgroup.
</OT>

S

"James Kuyper" <jameskuyper@verizon.netwrote in message
news:VIJuk.152$Dj1.13@trnddc02...

cr88192 wrote:

>
I wasn't sure whether you'd consider x86_64 as a special case of x86. My
own code has no need to worry about the differences between x86 and
x86_64 - it's written to perform the same operations in either case.
>

ok.

luckily at least, calling conventions are a lot more consistent on x86-64,
where the calling conventions are more of a per-OS issue and not so much a
per-library issue.

>
Good guess! Not all of the world (not even all of the x86 world) is a
Windows.
>

none the less, presumably people should know how things work in windows,
rather than acting like all this stuff is a big mystery...

>
I can't find any mention of them in "info gcc", though it mentions many
other features that are Windows specific.

possibly, no one bothered to write about it.

it is one of those things that is needed to make code and libraries work
right on Windows, and may need to be dealt with in some cases by programmers
(mostly in an indirect way when dealing with the Win32 API and passing
callbacks, where it is wrapped by macros like BWINAPI and similar).

it is also necessary for compilers to know about it so that they can deal
with the existing libraries (such as the Win32 API, ...).

it is one of those features that is needed (in a fundamental way) for stuff
to work, but is otherwise neither very interesting nor useful.


I just get tired here of people always ignoring or denying the existence of
stuff like the stack, the linker, libraries, ... which are important to know
about for anyone to actually effectively make use of the language.

"cr88192" <cr88192@NOSPAM.hotmail.comwrote:

"James Kuyper" <jameskuyper@verizon.netwrote in message

>
none the less, presumably people should know how things work in windows,
rather than acting like all this stuff is a big mystery...

Why? If I drive, or even repair, cars, I have no reason to know about
the piston timings of a two-stroke moped.

Richard

cr88192 said:

"Richard Heathfield" <rjh@see.sig.invalidwrote in message
news:ltednU4af-7KnSbVnZ2dnUVZ8qfinZ2d@bt.com...

<snip>

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

It was a long time ago that I lost count of the number of portable C
libraries I've written, and many of these have been turned into DLLs (with
no source mods). I've never once used the __stdcall keyword in any of
them. If a compiler obliged me to do so, I'd drop the compiler and find a
C compiler instead.

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

"cr88192" <cr88192@NOSPAM.hotmail.comwrites:

"Stephen Sprunk" <stephen@sprunk.orgwrote in message
news:54Auk.38851$ZE5.25232@nlpi061.nbdc.sbc.com...

>
only if one sticks by this certain fantasy in these parts, that one uses C
apart from computers...
>
>

>
yes, I was not trying to imply that it was particularly relevant, more just
complaining about the apparent ignorance of this keyword on the part of the
person responding (to me, this comming off as a fair deal of ignorance as to
what it is actual coders are faced with...).

You inferred my "apparent ignorance" from the fact that I chose not to
discuss it?

I've heard of __cdecl, and I have a fairly good idea what it means.
I've never used it, or had any need for it, myself. I don't know for
sure that it means the same thing in all implementations that support
it, and I was unwilling to make that assumption. In any case, since
the question was about the difference between two declarations, *both*
of which used __cdecl, it hardly seemed relevant.

real world code involves many such things, and it is generally good to know
them, of all things, so that the code actually works, and is capable of
doing all these mundane tasks that people here like to regard as
"impossible...".

I don't recall saying that any particular task is "impossible" in C.
I may at times have said that some task is impossible using only
standard C. The conclusion is not that the task can't be done, or
even that it shouldn't be done, merely that it requires things that
are beyond the scope of this newsgroup.

it is analogous to me of like:
a biologist who is ignorant of centrifuges (or considers that the actual
practice of using tools and actual organisms to study biology is below
them);

It's more like a biologist who declines to discuss centrifuge
calibration in a forum that discusses, say, evolutionary biology.

an automotive specialist who does not know about things like socket sets, or
about the difference between socket for hand-driven wrenches and impact
sockets (or thinks it is demeaning to actually work on cars);

I'm not an automotive specialist, but I'd guess that almost all
mechanical work on cars would require the use of socket sets. The
analogy doesn't hold up; most C programming doesn't require the use of
__cdecl.

abstractions apart from the reality is, IMO, distasteful.

Right, just like E = mc^2 is distasteful unless you plug in specific
values for E and m. Abstractions are useful.

but, then again, this could just be my ExTJ side showing...

I'll gladly confess one piece of ignorance: I don't know what "ExTJ is
supposed to mean. (No, I'm not asking.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"

[__cdecl]

cr88192 said:

it is one of those things that is needed to make code and libraries work
right on Windows,

Sorry, but I must disagree. This is the compiler-writer's problem, not the
user-programmer's problem. No strictly-conforming program can use __cdecl,
and any "C compiler" that can't translate a strictly-conforming program
has a rather poor claim to the title, at best.

I just get tired here of people always ignoring or denying the existence
of stuff like the stack, the linker, libraries, ... which are important
to know about for anyone to actually effectively make use of the
language.

I just get tired here of people always ignoring or denying the existence of
newsgroups where the discussion of stuff like the stack, the linker,
libraries is topical. Whether or not we would *like* those things to be
topical here, they are not. But there *are* newsgroups where they are
topical, and discussion about them no doubt rages freely within those
groups.

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

Keith Thompson said:

<snip>

most C programming doesn't require the use of __cdecl.

I disagree, since you imply that some does. None does. If the use of
__cdecl is required, what we're doing isn't C programming any more. That
doesn't mean that what we're doing isn't good and useful - but C it ain't.

<snip>

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

Richard Heathfield <rjh@see.sig.invalidwrites:

Keith Thompson said:
<snip>
>

>
I disagree, since you imply that some does. None does. If the use of
__cdecl is required, what we're doing isn't C programming any more. That
doesn't mean that what we're doing isn't good and useful - but C it ain't.
>
<snip>

C with extensions is still C. That doesn't mean it's good or useful,
but it's still C -- as the standard specifically acknowledges.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <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"

In article <lntzd0wasj.fsf@nuthaus.mib.org>,
Keith Thompson <kst-u@mib.orgwrote:

>Richard Heathfield <rjh@see.sig.invalidwrites:

>
>C with extensions is still C. That doesn't mean it's good or useful,
>but it's still C -- as the standard specifically acknowledges.

That's not what a lot of people here think. Many of the hard-core regs
here (including you, I'm pretty sure - though I see that you've been
saying otherwise recently) have been quite adamant that "That's not C"
(when faced with something that includes, say, POSIX and/or Windows
constructs). As if it would be just as valid to say it was, say,
Pascal, as to say it was C.

Of course this position is ludicrous, but that's CLC...

Keith Thompson said:

Richard Heathfield <rjh@see.sig.invalidwrites:

>
C with extensions is still C.

Only when being compiled on an implementation that supports those
extensions with that syntax and those semantics. On implementations that
don't, it's just an error.

That doesn't mean it's good or useful,
but it's still C -- as the standard specifically acknowledges.

It's the same problem as void main. C99 tried to "fix" void main (and
double main, and struct tm **main) by, in a sense, codifying different
syntaxes for main - but did so in a way that is inherently meaningless.
Yes, extensions are part of C in the sense that C compilers can accept
(and even define) them, but they are not part of C in the sense that
compilers can reject them.

Consider this:

now is the time for all good men to come to the aid of their party

According to you, there are good grounds for considering this to be C.
After all, any implementation is allowed to grant it meaning as an
extension. And the token sequence even appears in K&R2!

What about this?

WRITE OUTPUT TAPE 6, 601, IA, IB, IC, AREA

(I am given to understand from clc discussions over the last few years that
there is at least one conforming implementation that accepts Fortran
programs.)

Whenever we try to classify anything as "is X" or "is not X", there is a
risk that the line will be blurred. About the best we can do is to realise
that there are some things that definitely are X, some things that are
definitely not X, and a fuzzy boundary in between that is best avoided
when clarity is more important than a futile attempt to achieve
classificatory perfection.

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

Richard Heathfield <rjh@see.sig.invalidwrites:

Keith Thompson said:
>

>
Only when being compiled on an implementation that supports those
extensions with that syntax and those semantics. On implementations that
don't, it's just an error.
>

>
It's the same problem as void main. C99 tried to "fix" void main (and
double main, and struct tm **main) by, in a sense, codifying different
syntaxes for main - but did so in a way that is inherently meaningless.
Yes, extensions are part of C in the sense that C compilers can accept
(and even define) them, but they are not part of C in the sense that
compilers can reject them.
>
Consider this:
>
now is the time for all good men to come to the aid of their party
>

The problem here is that sane, sentient programmers would know where to
draw the line. Clearly you do not qualify.

Richard Heathfield <rjh@see.sig.invalidwrites:

Keith Thompson said:
>

>
Only when being compiled on an implementation that supports those
extensions with that syntax and those semantics. On implementations that
don't, it's just an error.

I'd call it non-portable C (and therefore still C) that isn't
supported by the current implementation.

If I have a file named "hello.c" with the following contents:

#include <stdio.h>
int main(void) { puts("hello, world"); return 0; }

it remains C whether I happen to have a C implementation available or
not.

>
It's the same problem as void main. C99 tried to "fix" void main (and
double main, and struct tm **main) by, in a sense, codifying different
syntaxes for main - but did so in a way that is inherently meaningless.
Yes, extensions are part of C in the sense that C compilers can accept
(and even define) them, but they are not part of C in the sense that
compilers can reject them.

Compilers can reject program that declare objects bigger than 65535
bytes. That doesn't make a program that declares such an object
non-C; it merely makes it non-portable C.

Since C is specifically designed to allow for writing non-portable
code (though it's certainly also possible to write portable C code),
it seems silly to say that any C code that's not portable is not C.

Consider this:
>
now is the time for all good men to come to the aid of their party
>
According to you, there are good grounds for considering this to be C.
After all, any implementation is allowed to grant it meaning as an
extension. And the token sequence even appears in K&R2!

I doubt that any existing C implementation provides an extension which
makes the above anything other than a syntax error (unless, of course,
it appears in a string literal, in a comment, or perhaps in a few
other contexts I won't bother to think about). If I'm correct, then
it doesn't qualify as a "conforming program" in the sense defined in
C99 4p7. (You could probably write a conforming implementation that
accepts it in a few minutes, as a wrapper around an existing
conforming implementation.)

What about this?
>
WRITE OUTPUT TAPE 6, 601, IA, IB, IC, AREA
>
(I am given to understand from clc discussions over the last few years that
there is at least one conforming implementation that accepts Fortran
programs.)

gcc certainly accepts Fortran programs, if it's been configured to do
so (you can choose during installation which languages to support).
But a given compiler with different sets of command-line options can
be two different implementations. gcc normally determines the
language to compile by looking at th