r...@zedat.fu-berlin.de (Stefan Ram) writes: > Ben Bacarisse <ben.use...@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. -- https://mail.python.org/mailman/listinfo/python-list
