diffrence?

Discussion in 'C Programming' started by raashid bhatt, Aug 31, 2008.

  1. what is the diffrence between

    typedef void (__cdecl *PyClean)(void);
    void (__cdecl *PyClean)(void);
     
    raashid bhatt, Aug 31, 2008
    #1
    1. Advertising

  2. raashid bhatt

    cch@srdgame Guest

    于 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.
     
    cch@srdgame, Aug 31, 2008
    #2
    1. Advertising

  3. 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) <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, Aug 31, 2008
    #3
  4. raashid bhatt

    cr88192 Guest

    "Keith Thompson" <> 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).

    ....
     
    cr88192, Aug 31, 2008
    #4
  5. 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.
     
    Richard Tobin, Aug 31, 2008
    #5
  6. cr88192 wrote:
    > "Keith Thompson" <> 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
     
    Stephen Sprunk, Aug 31, 2008
    #6
  7. raashid bhatt

    Ian Collins Guest

    cr88192 wrote:
    > "Keith Thompson" <> 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.
     
    Ian Collins, Aug 31, 2008
    #7
  8. raashid bhatt

    James Kuyper Guest

    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.
     
    James Kuyper, Sep 1, 2008
    #8
  9. raashid bhatt

    cr88192 Guest

    "Richard Heathfield" <> wrote in message
    news:...
    > 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
     
    cr88192, Sep 1, 2008
    #9
  10. raashid bhatt

    cr88192 Guest

    "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...
     
    cr88192, Sep 1, 2008
    #10
  11. raashid bhatt

    James Kuyper Guest

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


    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.
     
    James Kuyper, Sep 1, 2008
    #11
  12. raashid bhatt

    cr88192 Guest

    "Stephen Sprunk" <> wrote in message
    news:54Auk.38851$...
    > cr88192 wrote:
    >> "Keith Thompson" <> 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.
    >


    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, Sep 1, 2008
    #12
  13. cr88192 wrote:
    > "Richard Heathfield" <> wrote in message
    > news:...
    >> 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
     
    Stephen Sprunk, Sep 1, 2008
    #13
  14. raashid bhatt

    cr88192 Guest

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

    >
    > 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.
     
    cr88192, Sep 1, 2008
    #14
  15. raashid bhatt

    Richard Bos Guest

    "cr88192" <> wrote:

    > "James Kuyper" <> wrote 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
     
    Richard Bos, Sep 1, 2008
    #15
  16. "cr88192" <> writes:
    > "Stephen Sprunk" <> wrote in message
    > news:54Auk.38851$...
    >> cr88192 wrote:
    >>> "Keith Thompson" <> 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.
    >>

    >
    > 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) <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, Sep 1, 2008
    #16
  17. Richard Heathfield <> writes:
    > 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) <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, Sep 1, 2008
    #17
  18. In article <>,
    Keith Thompson <> wrote:
    >Richard Heathfield <> writes:
    >> 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...
     
    Kenny McCormack, Sep 1, 2008
    #18
  19. raashid bhatt

    Richard Guest

    Richard Heathfield <> writes:

    > Keith Thompson said:
    >
    >> Richard Heathfield <> writes:
    >>> 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.
     
    Richard, Sep 1, 2008
    #19
  20. raashid bhatt

    James Kuyper Guest

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

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


    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.
     
    James Kuyper, Sep 1, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. mohammed rafi
    Replies:
    3
    Views:
    14,490
    Charles Bailey
    May 7, 2004
  2. mohammed rafi
    Replies:
    1
    Views:
    1,335
    ben cohen
    May 6, 2004
  3. ITpro
    Replies:
    2
    Views:
    2,621
    David N. Welton
    Oct 29, 2005
  4. vj
    Replies:
    17
    Views:
    23,688
    jessie143143
    Oct 21, 2012
  5. Luai

    Diffrence between ++i and i++

    Luai, Apr 12, 2004, in forum: C Programming
    Replies:
    12
    Views:
    11,633
    Mabden
    May 7, 2004
Loading...

Share This Page