By cutting and pasting another definition and changing it until it works.
My general belief that the whole thing is fundamentally broken is reinforced by the fact that you can insert extraneous *s in certain places without it actually making any difference to the meaning.
I think I'd use void (*bob) (...) but I rarely use pointers to functions[1] so I might've remembered the syntax slightly wrong.
[1] Or rather I crib a typedef from the last time I had to, this dates all the way back to the first typedef I cribbed from GNU chess when porting it to RISC OS.
I tend to typedef the function type, e.g. typedef int fun(int); which then means you can declare function pointers in either style. However the actual reason for that form of typedef is so that I can declare functions that will be used with the associated pointer type with fun foo.
That's the sort of thing I mean, yes (I can't remember if that particular example actually does work, but it's being able to put random *s or not by the function name that always confuses me).
No, they are perfectly well placed in my mental model; they are notations for totally different things. int* x is "int-pointer x" and int (*x)() is "magic rune".
Don't you object to the 'int' being the type in the former case and the return type in the latter? Don't you object that it isn't int function(...) *x?
That works, yes. Why does being able to put in random extra operators confuse you? The language (like many others) allows you to name all your variables in really stupid ways, if you're so inclined, but that doesn't generate complaints.
No. My mental model of C is that declaration matches use. This has the advantage that it is always correct, because it's the model the language uses, and doesn't need to resort to lameness like "magic rune".
Funny that, my mental model is to just have well defined areas of ignorance coupled with knowledge of where to find answers. This tends to leave more room for useful things. Bit like a cache :).
Which is superior depends on how often one runs up against the areas of ignorance I suspect. This rarely happens in any of my code. Of course we could get into a slanging match or realise that, like many religious wars, each side has the solution that is right for them.
Geeks generally have this sadly mistaken notion that there is always a global optimum which applies to everyone rather than a succession of local maxima which suffice for the people which are standing on that particular hill :).
* converts a pointer to a function to a function designator.
Function designators, including both function names and the result of *, are always converted to pointers to functions unless sizeof or & are involved - the same idea as array objects.
The function call operator always applies to pointers to functions, even when there's no explicit use of function pointers going on.
Still, you don't have to take advantage of any of this stuff to write bizarro code with extra asterisks if you don't want to - many people get by without knowing it. So unless you're specifically looking into how the language works I don't see how it leads to confusion.
OK, so in some cases * has an effect which is then silently undone by the context.
In normal (non-function pointer) use, * has a clear meaning, convert foo* to foo by dereferencing, and it doesn't get randomly undone.
It's confusing because a casual user can't tell whether the * matters or not. By experiment one can tell that in that particular place it doesn't seem to, but why? It matters pretty much everywhere else one might put it. I was left wondering things like "Is there some subtle semantic difference that means it would matter in certain situations?"
I agree this is a bit annoying. When I teach people about C pointer syntax my usual approach is to start by pretending ("lies-to-children") that functions and function pointers are clearly distinct, so that you have to explicitly dereference a function pointer as (*f)(args) when calling it and explicitly use & when taking the address of a function, and so that the "declaration mimics use" maxim continues to make sense even in the case of function pointers. After I'm confident they understand it all on that level, then I mention that there's an additional layer of syntactic sugar which allows you to miss out most of the tedious punctuation when using function pointers. This usually works.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
(no subject)
Date: 2006-04-11 09:31 am (UTC)My general belief that the whole thing is fundamentally broken is reinforced by the fact that you can insert extraneous *s in certain places without it actually making any difference to the meaning.
(no subject)
Date: 2006-04-11 09:34 am (UTC)(no subject)
Date: 2006-04-11 09:36 am (UTC)(no subject)
Date: 2006-04-11 09:39 am (UTC)[1] Or rather I crib a typedef from the last time I had to, this dates all the way back to the first typedef I cribbed from GNU chess when porting it to RISC OS.
(no subject)
Date: 2006-04-11 09:39 am (UTC)Declaring pointers to functions
Date: 2006-04-11 09:41 am (UTC)is how I generally do it; or
double inverse(double(*f)(void*, double*), double g);
if for some reason I want my code to be unclear and bracket-ridden.
(no subject)
Date: 2006-04-11 09:50 am (UTC)(no subject)
Date: 2006-04-11 09:58 am (UTC)(no subject)
Date: 2006-04-11 09:58 am (UTC)(no subject)
Date: 2006-04-11 10:03 am (UTC)Don't you object to the 'int' being the type in the former case and the return type in the latter? Don't you object that it isn't int function(...) *x?
(no subject)
Date: 2006-04-11 10:03 am (UTC)(no subject)
Date: 2006-04-11 10:05 am (UTC)(no subject)
Date: 2006-04-11 10:07 am (UTC)(no subject)
Date: 2006-04-11 10:08 am (UTC)(no subject)
Date: 2006-04-11 10:13 am (UTC)Which is superior depends on how often one runs up against the areas of ignorance I suspect. This rarely happens in any of my code. Of course we could get into a slanging match or realise that, like many religious wars, each side has the solution that is right for them.
Geeks generally have this sadly mistaken notion that there is always a global optimum which applies to everyone rather than a succession of local maxima which suffice for the people which are standing on that particular hill :).
(no subject)
Date: 2006-04-11 10:17 am (UTC)* converts a pointer to a function to a function designator.
Function designators, including both function names and the result of *, are always converted to pointers to functions unless sizeof or & are involved - the same idea as array objects.
The function call operator always applies to pointers to functions, even when there's no explicit use of function pointers going on.
Still, you don't have to take advantage of any of this stuff to write bizarro code with extra asterisks if you don't want to - many people get by without knowing it. So unless you're specifically looking into how the language works I don't see how it leads to confusion.
(no subject)
Date: 2006-04-11 10:25 am (UTC)In normal (non-function pointer) use, * has a clear meaning, convert foo* to foo by dereferencing, and it doesn't get randomly undone.
It's confusing because a casual user can't tell whether the * matters or not. By experiment one can tell that in that particular place it doesn't seem to, but why? It matters pretty much everywhere else one might put it. I was left wondering things like "Is there some subtle semantic difference that means it would matter in certain situations?"
(no subject)
Date: 2006-04-11 11:23 am (UTC)(no subject)
Date: 2006-04-11 11:30 am (UTC)void (*signal(int, void (*)(int)))(int);Not a declaration, but...
Date: 2006-04-11 02:56 pm (UTC)handler = (void(*(*)())())(*handler)(&input[i],&output[i],TTY);