Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > is it really that complicated ?

Reply
Thread Tools

is it really that complicated ?

 
 
gert
Guest
Posts: n/a
 
      07-13-2007
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(...){...}

 
Reply With Quote
 
 
 
 
user923005
Guest
Posts: n/a
 
      07-13-2007
On Jul 12, 5:22 pm, gert <(E-Mail Removed)> 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. */

 
Reply With Quote
 
 
 
 
gert
Guest
Posts: n/a
 
      07-13-2007
On Jul 13, 2:49 am, user923005 <(E-Mail Removed)> wrote:
> On Jul 12, 5:22 pm, gert <(E-Mail Removed)> 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) (...);

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      07-13-2007
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
 
Reply With Quote
 
Stephen Sprunk
Guest
Posts: n/a
 
      07-13-2007
"gert" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
>> 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

 
Reply With Quote
 
Barry Schwarz
Guest
Posts: n/a
 
      07-13-2007
On Fri, 13 Jul 2007 00:22:03 -0000, gert <(E-Mail Removed)>
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
 
Reply With Quote
 
gert
Guest
Posts: n/a
 
      07-13-2007
i found the mother load of information about function pointer
http://gethelp.devx.com/techtips/cpp.../10min0300.asp

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

http://expat.cvs.sourceforge.net/exp....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 ?

 
Reply With Quote
 
Jens Thoms Toerring
Guest
Posts: n/a
 
      07-13-2007
gert <(E-Mail Removed)> wrote:
> i found the mother load of information about function pointer
> http://gethelp.devx.com/techtips/cpp.../10min0300.asp


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


> http://expat.cvs.sourceforge.net/exp....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://www.velocityreviews.com/forums/(E-Mail Removed)
\__________________________ http://toerring.de
 
Reply With Quote
 
gert
Guest
Posts: n/a
 
      07-13-2007
On Jul 13, 5:46 pm, (E-Mail Removed) (Jens Thoms Toerring) wrote:
> gert <(E-Mail Removed)> wrote:
> > i found the mother load of information about function pointer
> >http://gethelp.devx.com/techtips/cpp.../10min0300.asp
> > It explains allot, but still this doesn't fit in ?
> >http://expat.cvs.sourceforge.net/exp....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 ___ (E-Mail Removed)
> \__________________________ 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 ?

 
Reply With Quote
 
Jens Thoms Toerring
Guest
Posts: n/a
 
      07-13-2007
gert <(E-Mail Removed)> 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 ___ (E-Mail Removed)
\__________________________ http://toerring.de
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
problem in running a basic code in python 3.3.0 that includes HTML file Satabdi Mukherjee Python 1 04-04-2013 07:48 PM
OT : But help really really needed re: Domain Name selling, hosting etc. problem nc HTML 1 02-03-2005 07:24 PM
REALLY REALLY WERID PROBLEM!!!!pls take a look Amir ASP .Net 3 01-23-2004 06:01 PM
really really mysterious IE6 problem--secure site ultraviolet353 Computer Support 7 11-22-2003 07:56 PM
MR. ED REALLY, REALLY LOVES THE D60 !!! Annika1980 Digital Photography 9 10-28-2003 04:53 PM



Advertisments