is it really that complicated ?

Discussion in 'C Programming' started by gert, Jul 13, 2007.

  1. gert

    gert Guest

    I am trying my best here to understand the following that you will
    find in the header file of expat.h

    typedef void (XMLCALL *XML_ElementDeclHandler) (...);

    Now for starters what is XMLCALL i dont want to know what it does i
    only want to know wat it is ? pointer, integer ?

    Next questioin would be whats with all this (XMLCALL
    *XML_ElementDeclHandler) ?
    Why can it not be somthing like this ?

    typedef XMLCALL XML_ElementDeclHandler(...);

    And what about this ?

    XMLPARSEAPI (const XML_Char *)
    XML_GetBase(...);

    Why not

    XMLPARSEAPI
    XML_GetBase(...);

    Now about the example part.

    static void XMLCALL
    startElement(...){...}

    Why not like

    static XMLCALL
    startElement(...){...}
     
    gert, Jul 13, 2007
    #1
    1. Advertising

  2. gert

    user923005 Guest

    On Jul 12, 5:22 pm, gert <> wrote:
    > I am trying my best here to understand the following that you will
    > find in the header file of expat.h
    >
    > typedef void (XMLCALL *XML_ElementDeclHandler) (...);
    >
    > Now for starters what is XMLCALL i dont want to know what it does i
    > only want to know wat it is ? pointer, integer ?


    As a wild guess, I would venture:
    /* Expat tries very hard to make the API boundary very specifically
    defined. There are two macros defined to control this boundary;
    each of these can be defined before including this header to
    achieve some different behavior, but doing so it not recommended or
    tested frequently.

    XMLCALL - The calling convention to use for all calls across the
    "library boundary." This will default to cdecl, and
    try really hard to tell the compiler that's what we
    want.

    XMLIMPORT - Whatever magic is needed to note that a function is
    to be imported from a dynamically loaded library
    (.dll, .so, or .sl, depending on your platform).

    The XMLCALL macro was added in Expat 1.95.7. The only one which is
    expected to be directly useful in client code is XMLCALL.

    Note that on at least some Unix versions, the Expat library must be
    compiled with the cdecl calling convention as the default since
    system headers may assume the cdecl convention.
    */
    #ifndef XMLCALL
    #if defined(_MSC_VER)
    #define XMLCALL __cdecl
    #elif defined(__GNUC__) && defined(__i386) && !
    defined(__INTEL_COMPILER)
    #define XMLCALL __attribute__((cdecl))
    #else
    /* For any platform which uses this definition and supports more than
    one calling convention, we need to extend this definition to
    declare the convention used on that platform, if it's possible to
    do so.

    If this is the case for your platform, please file a bug report
    with information on how to identify your platform via the C
    pre-processor and how to specify the same calling convention as the
    platform's malloc() implementation.
    */
    #define XMLCALL
    #endif
    #endif /* not defined XMLCALL */


    > Next questioin would be whats with all this (XMLCALL
    > *XML_ElementDeclHandler) ?
    > Why can it not be somthing like this ?
    >
    > typedef XMLCALL XML_ElementDeclHandler(...);


    Because that would not be the same.

    > And what about this ?
    >
    > XMLPARSEAPI (const XML_Char *)
    > XML_GetBase(...);
    >
    > Why not
    >
    > XMLPARSEAPI
    > XML_GetBase(...);
    >
    > Now about the example part.
    >
    > static void XMLCALL
    > startElement(...){...}
    >
    > Why not like
    >
    > static XMLCALL
    > startElement(...){...}


    Ask the package authors about the API choices. Pull out a C manual
    and find out what these things mean. You will find that it is faster
    than asking here.

    P.S.

    int foo(void); /* this is a function prototype for a function that
    takes no arguments and returns an integer value */

    typedef int (*bar)(void); /* This is a typedef for an function pointer
    returning int. We could assign foo to an instance of it. */
     
    user923005, Jul 13, 2007
    #2
    1. Advertising

  3. gert

    gert Guest

    On Jul 13, 2:49 am, user923005 <> wrote:
    > On Jul 12, 5:22 pm, gert <> wrote:
    >
    > > I am trying my best here to understand the following that you will
    > > find in the header file of expat.h

    >
    > > typedef void (XMLCALL *XML_ElementDeclHandler) (...);

    >
    > > Now for starters what is XMLCALL i dont want to know what it does i
    > > only want to know wat it is ? pointer, integer ?

    >
    > As a wild guess, I would venture:
    > #define XMLCALL __cdecl
    > #define XMLCALL __attribute__((cdecl))


    http://www.linuxcommand.org/man_pages/cdecl1.html

    Ok and cdecl would be like a pointer, or more like a integer ?
    Come on its killing me, that's like melons and oranges, not to mention
    the ((cdecl))

    > > Next questioin would be whats with all this (XMLCALL
    > > *XML_ElementDeclHandler) ?
    > > Why can it not be somthing like this ?

    >
    > > typedef XMLCALL XML_ElementDeclHandler(...);

    >
    > Because that would not be the same.
    >
    > > And what about this ?

    >
    > > XMLPARSEAPI (const XML_Char *)
    > > XML_GetBase(...);

    >
    > > Why not

    >
    > > XMLPARSEAPI
    > > XML_GetBase(...);

    >
    > > Now about the example part.

    >
    > > static void XMLCALL
    > > startElement(...){...}

    >
    > > Why not like

    >
    > > static XMLCALL
    > > startElement(...){...}

    >
    > Ask the package authors about the API choices. Pull out a C manual
    > and find out what these things mean. You will find that it is faster
    > than asking here.
    >


    Well the manual goes like this :)
    typedef int NUMBER;

    I can still live with something like
    typedef int * NUMBER;

    And maybe if my brains are like cooled down with ice i can figure out
    a function pointer that looks like a cast but isn't a cast. But still
    i expect a name for the function pointer

    typedef int (*bar)(void) MYFUNCTION;

    There must be a other way to write the following in a more convenient
    way ?

    typedef void (XMLCALL *XML_ElementDeclHandler) (...);
     
    gert, Jul 13, 2007
    #3
  4. gert said:

    <snip>

    > Well the manual goes like this :)
    > typedef int NUMBER;
    >
    > I can still live with something like
    > typedef int * NUMBER;
    >
    > And maybe if my brains are like cooled down with ice i can figure out
    > a function pointer that looks like a cast but isn't a cast. But still
    > i expect a name for the function pointer
    >
    > typedef int (*bar)(void) MYFUNCTION;


    No, that isn't how it works.

    Start off by choosing a name.

    foo

    Now make it a function type:

    int foo(void);

    But we want a pointer to function, rather than a function:

    int (*foo)(void);

    But we want a type, rather than an object. So *now* we put typedef on
    the front.

    typedef int (*foo)(void);

    See?

    > There must be a other way to write the following in a more convenient
    > way ?
    >
    > typedef void (XMLCALL *XML_ElementDeclHandler) (...);


    Sure. Delete the spurious XMLCALL thingy which is making this so
    unreadable. Alternatively, live with it.

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
     
    Richard Heathfield, Jul 13, 2007
    #4
  5. "gert" <> wrote in message
    news:...
    >> As a wild guess, I would venture:
    >> #define XMLCALL __cdecl
    >> #define XMLCALL __attribute__((cdecl))

    >

    ....
    > Ok and cdecl would be like a pointer, or more like a integer ?


    Did you not read the part of the comments in expat.h that said "cdecl" is a
    calling convention? It's not a type.

    (And, of course, calling conventions are off-topic here, but as a general
    rule if you don't know what those are, you can safely just copy other,
    similar code and/or follow the directions.)

    > Come on its killing me, that's like melons and oranges, not to
    > mention the ((cdecl))


    That's just some screwy syntax related to GCC's __attribute__ extension.

    S

    --
    Stephen Sprunk "Those people who think they know everything
    CCIE #3723 are a great annoyance to those of us who do."
    K5SSS --Isaac Asimov


    --
    Posted via a free Usenet account from http://www.teranews.com
     
    Stephen Sprunk, Jul 13, 2007
    #5
  6. On Fri, 13 Jul 2007 00:22:03 -0000, gert <>
    wrote:

    >I am trying my best here to understand the following that you will
    >find in the header file of expat.h
    >
    >typedef void (XMLCALL *XML_ElementDeclHandler) (...);
    >
    >Now for starters what is XMLCALL i dont want to know what it does i
    >only want to know wat it is ? pointer, integer ?


    In all likelihood it is a macro that is normally #defined as null text
    or some white space. Under certain conditions (usually when certain
    other macros are defined), it will be defined as some implementation
    specific qualifier.

    Neither expat.h nor XMLCALL are part of the standard so our ability to
    answer your question is rather limited. If you really want to know,
    examine expat.h. It should be #defined there or in a prerequisite
    header that you documentation tells you expat.h needs.

    >
    >Next questioin would be whats with all this (XMLCALL
    >*XML_ElementDeclHandler) ?


    typedefs create an alias for an existing type. If you blank out the
    XMLCALL, you see that XML_ElementDeclHandler is the alias name for the
    type "pointer to function returning void and taking (...) parameters".

    >Why can it not be somthing like this ?
    >
    >typedef XMLCALL XML_ElementDeclHandler(...);


    Because this does not define a function pointer.

    >
    >And what about this ?
    >
    >XMLPARSEAPI (const XML_Char *)


    Once you add the missing semicolon, this declares XMLPARSEAPI is a
    function taking a particular pointer type as its argument and
    returning an int by implication. Implied return types have been
    removed from the current standard.

    >XML_GetBase(...);


    Another function declaration.

    >
    >Why not
    >
    >XMLPARSEAPI
    >XML_GetBase(...);


    If you are implying that the two previous declarations are a single
    statement, then it makes no sense at all.

    >
    >Now about the example part.
    >
    >static void XMLCALL
    >startElement(...){...}


    This is a function definition. It should not appear in a header.

    >
    >Why not like
    >
    >static XMLCALL
    >startElement(...){...}


    Because this changes the return type of the function from void to int
    by implication.


    Remove del for email
     
    Barry Schwarz, Jul 13, 2007
    #6
  7. gert

    gert Guest

    gert, Jul 13, 2007
    #7
  8. gert <> wrote:
    > i found the mother load of information about function pointer
    > http://gethelp.devx.com/techtips/cpp_pro/10min/10min0300.asp


    > It explains allot, but still this doesn't fit in ?


    > http://expat.cvs.sourceforge.net/expat/expat/lib/expat.h?view=markup
    > This is what is written on line 725 of expat.h ?


    > XMLPARSEAPI(const XML_Char *) XML_GetBase(XML_Parser parser);


    > Any idea what's XMLPARSEAPI(...) does ?


    It's defined as a macro in the included file 'expat_external.h'
    as

    #define XMLPARSEAPI(type) XMLIMPORT type XMLCALL

    and in that file there's also a comment saying

    XMLCALL - The calling convention to use for all calls across the
    "library boundary." This will default to cdecl, and
    try really hard to tell the compiler that's what we
    want.

    XMLIMPORT - Whatever magic is needed to note that a function is
    to be imported from a dynamically loaded library
    (.dll, .so, or .sl, depending on your platform).

    So XMLCALL and XMLIMPORT are system-specific "magic" that for a start
    you should considered to be defined to nothing, at least they aren't
    anything that is related to standard C. So

    XMLPARSEAPI(const XML_Char *) XML_GetBase(XML_Parser parser);

    gets reduced to (at least if you want to understand the C part
    of it, not the system-specific details)

    const XML_Char * XML_GetBase(XML_Parser parser);

    i.e. it declares a function that takes an argument of type 'XML_Parser'
    and returns a pointer to a 'const XML_Char'.

    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Jul 13, 2007
    #8
  9. gert

    gert Guest

    On Jul 13, 5:46 pm, (Jens Thoms Toerring) wrote:
    > gert <> wrote:
    > > i found the mother load of information about function pointer
    > >http://gethelp.devx.com/techtips/cpp_pro/10min/10min0300.asp
    > > It explains allot, but still this doesn't fit in ?
    > >http://expat.cvs.sourceforge.net/expat/expat/lib/expat.h?view=markup
    > > This is what is written on line 725 of expat.h ?
    > > XMLPARSEAPI(const XML_Char *) XML_GetBase(XML_Parser parser);
    > > Any idea what's XMLPARSEAPI(...) does ?

    >
    > It's defined as a macro in the included file 'expat_external.h'
    > as
    >
    > #define XMLPARSEAPI(type) XMLIMPORT type XMLCALL
    >
    > and in that file there's also a comment saying
    >
    > XMLCALL - The calling convention to use for all calls across the
    > "library boundary." This will default to cdecl, and
    > try really hard to tell the compiler that's what we
    > want.
    >
    > XMLIMPORT - Whatever magic is needed to note that a function is
    > to be imported from a dynamically loaded library
    > (.dll, .so, or .sl, depending on your platform).
    >
    > So XMLCALL and XMLIMPORT are system-specific "magic" that for a start
    > you should considered to be defined to nothing, at least they aren't
    > anything that is related to standard C. So
    >
    > XMLPARSEAPI(const XML_Char *) XML_GetBase(XML_Parser parser);
    >
    > gets reduced to (at least if you want to understand the C part
    > of it, not the system-specific details)
    >
    > const XML_Char * XML_GetBase(XML_Parser parser);
    >
    > i.e. it declares a function that takes an argument of type 'XML_Parser'
    > and returns a pointer to a 'const XML_Char'.
    >
    > Regards, Jens
    > --
    > \ Jens Thoms Toerring ___
    > \__________________________ http://toerring.de


    Thanks, that was exactly the c part i was looking for.
    Will the next c compiler figure out all this system magic things by
    him self ?
     
    gert, Jul 13, 2007
    #9
  10. gert <> wrote:
    > Will the next c compiler figure out all this system magic things by
    > him self ?


    At least if it's one of the compilers and systems the authors
    tested it on it should work. But if you try to compile that
    program on a completely new system there's at least a chance
    that it won't work and then you may have to delve into this
    system-specific things to repair them (or ask the authors for
    help).
    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
     
    Jens Thoms Toerring, Jul 13, 2007
    #10
    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. Amir
    Replies:
    3
    Views:
    626
  2. nc
    Replies:
    1
    Views:
    529
    nice.guy.nige
    Feb 3, 2005
  3. Replies:
    2
    Views:
    371
  4. Jeannie
    Replies:
    15
    Views:
    918
    Jeannie
    Aug 30, 2005
  5. =?Utf-8?B?TFc=?=
    Replies:
    8
    Views:
    447
    =?Utf-8?B?TFc=?=
    Apr 25, 2007
Loading...

Share This Page