Lies in education [was Re: The "loop and a half"]

[Ben Bacarisse]

ram at zedat.fu-berlin.de (Stefan Ram) writes:

> Ben Bacarisse <ben.usenet at bsb.me.uk> writes:
>>That's a different type.  I think you mean that a human writing C
>>(rather than bartc's code generator) would probably design the code to
>>use tokenrec ** then I agree, but the latter is not just a different way
>>to write the former.
>
>   That most difficult thing in C in the realm of type
>   declarations for me is:
>
>   Define a function »g« with a parameter »x« of type »int«, so
>   that this function »g« returns a pointer to another function.
>   This other function has a parameter of type »char« and returns
>   a double value.
>
>   /Without/ a typedef.

You read a C type from the "inside out", going right if you can and left
when you can't.  That rule can be reversed to built up the type:

You know it has (read "g is a function taking an int")

  g(int x)

and since g returns a pointer you will have

  *g(int x)

But it returns a pointer to a function taking a char so we must add
(char) on the right but the brackets can't go here:

  *g(int x)(char)

because then you would be read "function taking a char" before the
pointer to.  We need extra brackets to stop us reading right until we've
read left:

  (*g(int x))(char)

This forces "g is a function taking int returning a pointer to...".
Finally, we just need the type of the function whose pointer is being
returned:

  double (*g(int x))(char)

Check with you finger on the name and reading right when you can and
left when you can't (because of brackets).

And then you re-write it using a typedef.  Knowing how is simply
interesting, not useful.

-- 
Ben.