pointers to functions question

L

Logan Lee

#include <stdio.h>
#include <stdlib.h>

void func(int);

main(){
void (*fp)(int);

fp = func; // here when assigning a pointer, why not fp=&func; ?

(*fp)(1);
fp(2);

exit(EXIT_SUCCESS);
}

void
func(int arg){
printf("%d\n", arg);
}
 
I

Ivan Novick

#include <stdio.h>
#include <stdlib.h>

void func(int);

main(){
void (*fp)(int);

fp = func; // here when assigning a pointer, why not fp=&func; ?

(*fp)(1);
fp(2);

exit(EXIT_SUCCESS);

}

void
func(int arg){
printf("%d\n", arg);

}

I beieve the 2 options do the exact same thing ... but will leave it
to someone else to quote the relevant passage from the standard.

fp = func;
fp = &func;

Regards,
Ivan Novick
http://www.0x4849.net
 
W

WaterWalk

#include <stdio.h>
#include <stdlib.h>

void func(int);

main(){
void (*fp)(int);

fp = func; // here when assigning a pointer, why not fp=&func; ?

(*fp)(1);
fp(2);

exit(EXIT_SUCCESS);

}

void
func(int arg){
printf("%d\n", arg);

}

They are actually the same. Pick one you like.
 
K

Keith Thompson

Logan Lee said:
#include <stdio.h>
#include <stdlib.h>

void func(int);

main(){

Better:
int main(void) {
void (*fp)(int);

fp = func; // here when assigning a pointer, why not fp=&func; ?

(*fp)(1);
fp(2);

exit(EXIT_SUCCESS);
}

void
func(int arg){
printf("%d\n", arg);
}

See questions 4.12 and 1.34 in the comp.lang.c FAQ,
<http://c-faq.com/>.

A function call actually requires a function pointer value before the
parentheses. In a typical "direct" function call, this pointer value
is obtained from the name of the function.

A function name (more generally, any expression of function type) is
implicitly converted to a pointer to the function in most contexts.
(The exceptions are when it's the operand of a sizeof operator, which
is illegal rather than yielding a pointer size, and when it's the
operand of a unary "&", which yields the address of the function.)

So, in
fp = func;
the expression ``func'', which is of function type, decays to a
pointer-to-function; the result is assigned to fp.

In
(*fp)(1);
fp is of pointer-to-function type. Applying unary "*" deferences the
pointer, yielding a result of pointer type, which immediately decays
to a pointer-to-function -- which is what's required for the function
call.

In
fp(2);
fp is already of pointer-to-function type; the result is used
directly for the function call.

Note also that either
func(3);
or
(*func)(3);
is legal. (Exercise: Trace what happens in each case.)
 
R

Richard Heathfield

Keith Thompson said:
Better:
int main(void) {

It's not just *better* - it's a *requirement*, if he wishes to use
BCPL-style comments (which he does later in the code). He will also
require a C99-conforming implementation.

<snip>
 
B

Ben Bacarisse

Keith Thompson said:
<about function pointers and calls>

In
(*fp)(1);
fp is of pointer-to-function type. Applying unary "*" deferences the
pointer, yielding a result of pointer type, which immediately decays
You meant to write: ^^^^^^^ function
to a pointer-to-function -- which is what's required for the function
call.

(Tiny correction, but the text is confusing without it.)
 
K

Keith Thompson

Ben Bacarisse said:
<about function pointers and calls>


You meant to write: ^^^^^^^ function

(Tiny correction, but the text is confusing without it.)

Right, thanks.
 
K

Keith Thompson

Richard Heathfield said:
Keith Thompson said:

It's not just *better* - it's a *requirement*, if he wishes to use
BCPL-style comments (which he does later in the code). He will also
require a C99-conforming implementation.
[...]

Or a mostly-C90-conforming implementation that supports "//" comments
as an extension.

Suggestion: '"//" comments' is clearer than "BCPL-style comments";
most people aren't familiar with BCPL, and C probably got them from
C++ anyway (presumably C++ got them from BCPL).
 
C

CBFalconer

Keith said:
.... snip ...
It's not just *better* - it's a *requirement*, if he wishes to
use BCPL-style comments (which he does later in the code). He
will also require a C99-conforming implementation.
[...]

Or a mostly-C90-conforming implementation that supports "//"
comments as an extension.

Suggestion: '"//" comments' is clearer than "BCPL-style
comments"; most people aren't familiar with BCPL, and C
probably got them from C++ anyway (presumably C++ got them
from BCPL).

However normal /* .. */ comments remain clear and portable :)
 
R

Richard Heathfield

Keith Thompson said:
Richard Heathfield said:
Keith Thompson said:

It's not just *better* - it's a *requirement*, if he wishes to use
BCPL-style comments (which he does later in the code). He will also
require a C99-conforming implementation.
[...]

Or a mostly-C90-conforming implementation that supports "//" comments
as an extension.

....and diagnoses the syntax error.
 
J

Joachim Schmitz

Richard said:
Keith Thompson said:
Richard Heathfield said:
Keith Thompson said:

main(){

Better:
int main(void) {

It's not just *better* - it's a *requirement*, if he wishes to use
BCPL-style comments (which he does later in the code). He will also
require a C99-conforming implementation.
[...]

Or a mostly-C90-conforming implementation that supports "//" comments
as an extension.

...and diagnoses the syntax error.
Unless call with something like "-Wallows_cplusplus_comments"

Which then makes them non-C90 conforming...

Bye, Jojo
 
M

Mark F. Haigh

Richard Heathfield said:
Keith Thompson said:
It's not just *better* - it's a *requirement*, if he wishes to use
BCPL-style comments (which he does later in the code). He will also
require a C99-conforming implementation.

[...]

Or a mostly-C90-conforming implementation that supports "//" comments
as an extension.

Suggestion: '"//" comments' is clearer than "BCPL-style comments";
most people aren't familiar with BCPL, and C probably got them from
C++ anyway (presumably C++ got them from BCPL).
<snip>

That's correct. C++ (and transitively, C99) did get them from BCPL.
Chapter and verse, BCPL Reference Manual, Memorandum M-352, July 1967:

2.1.2 Hardware Conventions and Preprocessor Rules
[...]
(b) A user's comment may be included between a double slash
'//' and the end of the line. [...]


For those of you keeping score at home, that's a chapter-and-versing
of Keith Thompson, in comp.lang.c, from a non-C standard from the
60's, mentioning C++ in passing, that is technically accurate but 100%
unhelpful, and pertains to C99, which is somewhat controversial but
yet completely on-topic.

So I suppose I should say "Bingo". What's the prize?

Mark F. Haigh
(e-mail address removed)
 
N

Nick Keighley

Or a mostly-C90-conforming implementation that supports "//" comments
as an extension.
Suggestion: '"//" comments' is clearer than "BCPL-style comments";
most people aren't familiar with BCPL, and C probably got them from
C++ anyway (presumably C++ got them from BCPL).

That's correct.  C++ (and transitively, C99) did get them from BCPL.
Chapter and verse, BCPL Reference Manual, Memorandum M-352, July 1967:

2.1.2 Hardware Conventions and Preprocessor Rules
[...]
    (b)  A user's comment may be included between a double slash
         '//' and the end of the line.  [...]

I think that only shows that BCPL had // comments not that C++
got them from BCPL


<snip>
 
R

Richard Heathfield

Joachim Schmitz said:
Richard said:
Keith Thompson said:
Keith Thompson said:

main(){

Better:
int main(void) {

It's not just *better* - it's a *requirement*, if he wishes to use
BCPL-style comments (which he does later in the code). He will also
require a C99-conforming implementation.
[...]

Or a mostly-C90-conforming implementation that supports "//" comments
as an extension.

...and diagnoses the syntax error.
Unless call with something like "-Wallows_cplusplus_comments"

Which then makes them non-C90 conforming...

....and thus off-topic here.
 
R

Richard Heathfield

Mark F. Haigh said:

For those of you keeping score at home, that's a chapter-and-versing
of Keith Thompson, in comp.lang.c, from a non-C standard from the
60's, mentioning C++ in passing, that is technically accurate but 100%
unhelpful, and pertains to C99, which is somewhat controversial but
yet completely on-topic.

So I suppose I should say "Bingo". What's the prize?

You've won the First Prize! A weekend writing C code as a "pair programmer"
with Dan Pop.

(Second Prize is two such weekends.)
 
M

Mark F. Haigh

Mark F. Haigh said:




You've won the First Prize! A weekend writing C code as a "pair programmer"
with Dan Pop.

(Second Prize is two such weekends.)
<snip>

LOL!!!

Also included in our "Get to Know C" orientation is our new course
"Mastering Diplomacy", which is jointly presented by Kaz Kylheku and
Martin Ambuhl.

Mark F. Haigh
(e-mail address removed)
 
M

Mark F. Haigh

That's correct. C++ (and transitively, C99) did get them from BCPL.
Chapter and verse, BCPL Reference Manual, Memorandum M-352, July 1967:
2.1.2 Hardware Conventions and Preprocessor Rules
[...]
(b) A user's comment may be included between a double slash
'//' and the end of the line. [...]

I think that only shows that BCPL had // comments not that C++
got them from BCPL
<snip>

C++ descended from "C with Classes", which inherited the double slash
comment style from BCPL around 1980.

Nobody was sure in the early 80's whether "C with Classes" would be
another programming language dead-end or not. That's in direct
contrast to C, which had already been in production use for nearly a
decade.

Mark F. Haigh
(e-mail address removed)
 
R

Randy Howard

Mark F. Haigh said:



You've won the First Prize! A weekend writing C code as a "pair programmer"
with Dan Pop.

If the project is a treatise on "All you ever wanted to know about
scanf() but were afraid to ask", it might be worthwhile.
 
B

Barry Schwarz

#include <stdio.h>
#include <stdlib.h>

void func(int);

main(){

int main(void) please
void (*fp)(int);

fp = func; // here when assigning a pointer, why not fp=&func; ?

For want of a better word, it is a quirk of the language. Either form
is acceptable.
(*fp)(1);
fp(2);

Basically the same quirk. (*******fp)(3) also works
exit(EXIT_SUCCESS);
}

void
func(int arg){
printf("%d\n", arg);
}

If you google through the archives, someone did provide a "logical"
rational several months ago.


Remove del for email
 
R

ram

int main(void) please



For want of a better word, it is a quirk of the language. Either form
is acceptable.




Basically the same quirk. (*******fp)(3) also works





If you google through the archives, someone did provide a "logical"
rational several months ago.

Remove del for email

Are all these quirks, i.e. fp(1), (*fp)(1), (****fp)(1), all existed
in the original K&R C, or are they quirks of ANSI C?
--thanks
--ram
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,772
Messages
2,569,588
Members
45,100
Latest member
MelodeeFaj
Top