Lies in education [was Re: The "loop and a half"]
Ben Bacarisse
ben.usenet at bsb.me.uk
Wed Oct 11 20:21:33 EDT 2017
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.
More information about the Python-list
mailing list