473,322 Members | 1,538 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,322 software developers and data experts.

diffrence?

what is the diffrence between

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

Aug 31 '08 #1
24 1646
cch
于 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.
Aug 31 '08 #2
raashid bhatt <ra**********@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) ks***@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"
Aug 31 '08 #3
In article <ea***************************@saipan.com>,
cr88192 <cr*****@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.
Aug 31 '08 #4
cr88192 wrote:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>raashid bhatt <ra**********@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.

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
Aug 31 '08 #5
cr88192 wrote:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>raashid bhatt <ra**********@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.

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.
Aug 31 '08 #6
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.
>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.

--
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
Aug 31 '08 #7
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.
Sep 1 '08 #8

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:lt******************************@bt.com...
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

Sep 1 '08 #9

"James Kuyper" <ja*********@verizon.netwrote 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...

Sep 1 '08 #10
cr88192 wrote:
"James Kuyper" <ja*********@verizon.netwrote 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...
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.
Sep 1 '08 #11

"Stephen Sprunk" <st*****@sprunk.orgwrote in message
news:54*******************@nlpi061.nbdc.sbc.com...
cr88192 wrote:
>"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>>raashid bhatt <ra**********@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.

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

Sep 1 '08 #12
cr88192 wrote:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:lt******************************@bt.com...
>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...
Only Windows compilers.
>>>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).
<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
Sep 1 '08 #13

"James Kuyper" <ja*********@verizon.netwrote in message
news:VIJuk.152$Dj1.13@trnddc02...
cr88192 wrote:
>"James Kuyper" <ja*********@verizon.netwrote 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...

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.

>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.
none the less, presumably people should know how things work in windows,
rather than acting like all this stuff is a big mystery...

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

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.

Sep 1 '08 #14
"cr88192" <cr*****@NOSPAM.hotmail.comwrote:
"James Kuyper" <ja*********@verizon.netwrote in message
cr88192 wrote:
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.

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
Sep 1 '08 #15
cr88192 said:
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:lt******************************@bt.com...
<snip>
>>
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).
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
Sep 1 '08 #16
"cr88192" <cr*****@NOSPAM.hotmail.comwrites:
"Stephen Sprunk" <st*****@sprunk.orgwrote in message
news:54*******************@nlpi061.nbdc.sbc.com...
>cr88192 wrote:
>>"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
raashid bhatt <ra**********@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.

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.

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...).
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) ks***@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"
Sep 1 '08 #17
[__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
Sep 1 '08 #18
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
Sep 1 '08 #19
Richard Heathfield <rj*@see.sig.invalidwrites:
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>
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) ks***@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"
Sep 1 '08 #20
In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>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>

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

Sep 1 '08 #21
Keith Thompson said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>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>

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
Sep 1 '08 #22
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>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>

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
The problem here is that sane, sentient programmers would know where to
draw the line. Clearly you do not qualify.
Sep 1 '08 #23
Richard Heathfield <rj*@see.sig.invalidwrites:
Keith Thompson said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>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>

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.
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.
>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.
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 the suffix of the source file name;
".c" is C, ".cpp" or ".C" is C++, ".f" is Fortran, ".adb" or ".ads" is
Ada, etc. I would argue that the file suffix is effectively a
command-line option, so "gcc -c hello.c" and "gcc -c hello.f" invoke
two different implementations.

If I could take a file "hello.c" containing

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

and have an implementation accept it, then change the contents
of "hello.c" to

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

and still have the implementation accept it *with the same options*,
then I'd be willing to say that a C implementation accepts Fortran
code.
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.
I finally went back and re-read your previous statement, which I think
I misinterpreted. You said that if the use of __cdecl is *required*,
then what we're doing isn't C programming. I agree; no conforming C
implementation can require the use of __cdecl.

On the other hand, a conforming C implementation can *allow* the use
of __cdecl, and can require it if you want to achieve some goal that
can't be achieved in portable standard C.

The discussion then moved to the question of whether C with extensions
is still C. That's within the fuzzy boundary you mentioned -- but I
still say that a program that uses __cdecl, though it certainly isn't
portable C, may nevertheless be (non-portable) C.

I'll also say that not all things that are C are appropriate for
discussion in this newsgroup.

--
Keith Thompson (The_Other_Keith) ks***@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"
Sep 1 '08 #24
Keith Thompson said:

<snip>
I finally went back and re-read your previous statement, which I think
I misinterpreted. You said that if the use of __cdecl is *required*,
then what we're doing isn't C programming. I agree; no conforming C
implementation can require the use of __cdecl.
Right, and...
On the other hand, a conforming C implementation can *allow* the use
of __cdecl, and can require it if you want to achieve some goal that
can't be achieved in portable standard C.
....right again.
The discussion then moved to the question of whether C with extensions
is still C. That's within the fuzzy boundary you mentioned -- but I
still say that a program that uses __cdecl, though it certainly isn't
portable C, may nevertheless be (non-portable) C.
Because it is in the fuzzy (and I certainly agree that it is), we can argue
about terminology until we're blue in the face and not get anywhere. I
doubt very much whether you wish to bother, and I certainly don'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
Sep 1 '08 #25

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

4
by: rubbersoul | last post by:
I have a table with 3 colums: Date (datetime) End (datetime) Sys_id (INT) What I need to do is write a query that will do a calculation and return the diffrence in hours between date and...
7
by: ranjeet.gupta | last post by:
Dear All, What is the diffrence between the below two notation; char bytes; char bytes; both are one bytes, It may be odd to ask question like above, But does it matter if i allocate like...
3
by: | last post by:
is there any performance diffrence between MC++ 2003 ,other .NET languages and MC++ 2005 (cause of an optimization) ???
5
by: dost | last post by:
can u tell me the diffrence between...... private public and protected .........in........these.......which one...is access modifier....and which one..is specifier....... and....the diffrence...
8
by: Vijay | last post by:
Can you tell me what is the diffrence between structure and union.
1
by: jitender164 | last post by:
hello all pls help me to explore the diffrence b/w c and c++ by using a program example code that can illustrate the diffrence between the structure programing and object oriented programing....
3
by: raju123 | last post by:
what is diffrence between c# and vb.net
0
by: MALIK771 | last post by:
write now i am using SQL7 with .net 2002. on XP. and SQL server with .net 2002 on server2000 but i don't have idea about MYSQL. could u tell me the diffrence between them.
12
by: trysenthil | last post by:
hi all., i want to know the diffrence between the decode and case function that is available in oracle....help me ya...
0
parshupooja
by: parshupooja | last post by:
Hey All, I have a 5 textboxes on my asp.net C# page First texbox has 06:15 AM value second textbox has 09:15AM value. third texbox has 03:30 PM fourth has 5.30 PM I want to calculate...
0
by: DolphinDB | last post by:
Tired of spending countless mintues downsampling your data? Look no further! In this article, you’ll learn how to efficiently downsample 6.48 billion high-frequency records to 61 million...
0
by: ryjfgjl | last post by:
ExcelToDatabase: batch import excel into database automatically...
0
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
1
isladogs
by: isladogs | last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM). In this month's session, we are pleased to welcome back...
0
by: Vimpel783 | last post by:
Hello! Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
0
by: ArrayDB | last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
1
by: Defcon1945 | last post by:
I'm trying to learn Python using Pycharm but import shutil doesn't work
0
by: af34tf | last post by:
Hi Guys, I have a domain whose name is BytesLimited.com, and I want to sell it. Does anyone know about platforms that allow me to list my domain in auction for free. Thank you
0
by: Faith0G | last post by:
I am starting a new it consulting business and it's been a while since I setup a new website. Is wordpress still the best web based software for hosting a 5 page website? The webpages will be...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.