is it really that complicated ?

[gert]

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(...){...}

 

[user923005]

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

 

[gert]

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

Because that would not be the same.







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

 

[Richard Heathfield]

gert said:

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.

 

[Stephen Sprunk]

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

 

[Barry Schwarz]

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

 

[gert]

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 ?

 

[Jens Thoms Toerring]

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

 

[gert]

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

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 ?

 

[Jens Thoms Toerring]

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