Deep question for the REAL C GURU's out there ...

[Roger Oberholtzer]

On Wed, 2005-02-23 at 23:21, Ben Duncan wrote:
> Ok, (read on thru for several other questions). I started to use typedef struct,
> but ran across a "published" paper saying 'use typedef'ing then define structure'
> paper by someone on "C" standards ..Oh well, I guess opinions are like assholes, everyone
> has one and it stinks ...

What books? This sounds very odd. The syntax I did is as common as can
be. For example, in K&R Edition 2, page 146, there is an example with
two statements to make typedefs. However, there they are making two
typedefs; one for the structure and one for a pointer to such a
structure. I did not think you were making two types of variables.

C lends itself to opinions...

> Ok, explain 'static inline' type of C function ..

Typical function calls in C are to code that is elsewhere. It is shared
by all places in the code that calls it.  This is nice. However, it does
take a speed penalty for the call as lots of things are saved and
restored for each call.

To improve this, many people write macros (e.g.,

#define z(x,y) x = x + y

This is a faster call in that the code is inserted in the place it is
called. There is no call to a function. However, these are difficult to
write when they get more involved. Just look at any lengthly #define.
People do them because they result in a sort of 'quick function call'.
But they are ugly. Just the fact that you have to escape new lines is
bad. Don't ask about local variables. Possible, but it all gets messy.
And, the biggie: side-effects. Just try passing a parameter like (++x)
to a macro. It will be incremented each time it is used in the macro -
not just when passed. Ouch.

Well, C has an additional method that is far superior. It is the static
inline function.

static inline int z (int x, int y) {

	int local_var;

	x = x + y;
}

The advantage of this is that the C compiler can do better type
checking. You call it exactly like a regular C function. No macro side
effects like the ++x example. Many compilers in fact make faster code
with the static inline than the macro because they know which registers
can be used. A macro provides no clue for this. And, anything more
complex will just be easier to maintain as a static inline.

For example, look at /usr/include/linux/signal.h to see how many common
signal related calls are really static inline for speed.

So, if you make data structures containing more structures, try to
compartmentalize the code that deals with these various data structures.
Putting the parts in 'static inline' functions should very much lessen
the function call overhead.

The only down side is that each call to a static inline makes a copy of
the code at that place. So, applications can grow. In my experience, it
is usually by a very very small amount. Depending on how you do things.


+????????????????????????????+???????????????????????????????+
? Roger Oberholtzer          ?   E-mail: roger at opq.se        ?
? OPQ Systems AB             ?      WWW: http://www.opq.se/  ?
? Nybrogatan 66 nb           ?    Phone: Int + 46 8   314223 ?
? 114 41 Stockholm           ?   Mobile: Int + 46 733 621657 ?
? Sweden                     ?      Fax: Int + 46 8   314223 ?
+????????????????????????????+???????????????????????????????+