diffrence?

[raashid bhatt]

what is the diffrence between

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

 

[cch@srdgame]

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

 

[Keith Thompson]

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.

 

[cr88192]

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

....

 

[Richard Tobin]

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

 

[Stephen Sprunk]

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

 

[Ian Collins]

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.

 

[James Kuyper]

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.

 

[cr88192]

Ian Collins said:


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

 

[cr88192]

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

 

[James Kuyper]

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.

 

[cr88192]

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

 

[Stephen Sprunk]

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

 

[cr88192]

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.

 

[Richard Bos]

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

 

[Keith Thompson]

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]

Keith Thompson said:


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.

 

[Kenny McCormack]

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

 

[Richard]

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.

 

[James Kuyper]

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

Why? Windows programmers should certainly know how Windows works, as
should anyone who needs to a write a program which might need to be
ported to Windows, and might need to be modified in order to perform the
port (my own code should be compilable under Windows, but it should also
require no modification to achieve that result - however, I have no
access to any machine where I could test whether or not this is the case).

Why in the world should anyone else treat it as anything other than "a
big mystery"? I'm not saying that happening to have such knowledge is
harmful; but your use of "should" implies that people should go out of
their way to acquire this information. Why should they waste their time
in that fashion?

....

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

From what various other programmers have said on this thread, that
doesn't seem to be the case. For instance, I wouldn't expect any of the
programs I'm responsible for to require use of the __cdecl keyword if
ported to Windows. They make no use of operating system calls or GUI
interfaces, and that seems to be the main things that require it. The
only libraries my code uses are the C standard library and three
third-party libraries, all of which are supposed to be portable to
Windows, none of which have a "__cdecl" anywhere in the published
documentation of how to use them.

....

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'm making very effective use of the language without having any need to
use or even know about the __cdecl keyword. You might want to rethink
putting it into that category.