Arguments and Functions

[Marc]

Dear Group,

I am attempting to modify a portion of the source code for the global
illumination raytracer, RADIANCE. Specifically, I am trying to
implement a different ray/triangle intersection algorithm. My C
programming skills are laymen at best but I have successfully
implemented this algorithm for triangle polygons (the source code that
I am trying to modify is for a triangular mesh) previously. I have a
question concerning passing arguments on to functions. For all that I
have read and experienced, if there is a function that requires two
arguments, then those arguments must be with the function call (i.e.
function(arg1,arg2)) and the argument types must match the types in the
declared function. In the source code that I am modifying, I have come
across an instance wherein a function that is being called, which
requires two arguments, is being called without any arguments. In the
following file:

http://www.radiance-online.org/cgi-bin/viewcvs.cgi/*checkout*/ray/src/rt/o_mesh.c?


on line 167, it appears to me that the function mesh_hit is being
called but no arguments are being passed to it. The function mesh_hit
requires two arguments (oset, r). This code does successfully execute
but I do not know how it works. I have searched through all of my C
books and I have searched the web and usenet but I can not find any
answers. Can anyone explain this to me?

BTW

For anyone who wishes to tackle this issues, here is the address to
download ray.h (for the RAY type):

http://www.radiance-online.org/cgi-bin/viewcvs.cgi/*checkout*/ray/src/rt/ray.h?

and object.h (for the OBJECT type):

http://www.radiance-online.org/cgi-...mon/object.h?rev=2.18&content-type=text/plain



Thanks

Marcus

 

[Richard Heathfield]

Marc said:

http://www.radiance-online.org/cgi-bin/viewcvs.cgi/*checkout*/ray/src/rt/o_mesh.c?


on line 167, it appears to me that the function mesh_hit is being
called but no arguments are being passed to it.

You mean this?

rcont.hitf = mesh_hit;

If so, then no, this is not a function call. It is an assignment of a
function pointer value to a function pointer object.

In ray.h, you'll find the following structure member:

void (*hitf)(OBJECT *, struct ray *);

This is a pointer to a function that takes two parameters (of types OBJECT *
and struct ray *) and returns no value.

rcont.hitf = mesh_hit; means that you're pointing the hitf member of rcont
at the mesh_hit function. This does not involve a call to that function.
What it does imply, however, is that later on you can call the function
through the pointer, rather than by its actual name. The syntax for that
would be something like:

(*rcont.hitf)(&myobj, &myray);

although, perversely:

rcont.hitf(&myobj, &myray);

would also be legal. The exact syntax (ampersands, object names, and so on)
obviously depends on the types and names of the objects in question.

 

[Micah Cowan]

rcont.hitf = mesh_hit; means that you're pointing the hitf member of rcont
at the mesh_hit function. This does not involve a call to that function.
What it does imply, however, is that later on you can call the function
through the pointer, rather than by its actual name. The syntax for that
would be something like:

(*rcont.hitf)(&myobj, &myray);

although, perversely:

rcont.hitf(&myobj, &myray);

would also be legal. The exact syntax (ampersands, object names, and so on)
obviously depends on the types and names of the objects in question.

Considering the verbage used by the standard, it's the first one that
I would see more as a perversion. A function call is /always/ done
through a pointer-to-function; it's just that function designators are
implicitly converted to pointer-to-function.

The first invocation is a bit strange because, from the viewpoint of
the Standard, it's a pointer-to-function that, by virtue of your
dereference, is converted to function type and subsequently, since it
is not the operand of the & or sizeof operators, gets converted back
into a pointer-to-function before being called.

 

[Richard Heathfield]

Micah Cowan said:

The syntax
for that would be something like:

(*rcont.hitf)(&myobj, &myray);

although, perversely:

rcont.hitf(&myobj, &myray);

would also be legal. [...]

Considering the verbage used by the standard, it's the first one that
I would see more as a perversion.

<shrug> Can we agree to differ? I find that the * is most helpful in
deciphering the code on a first reading.

 

[Jordan Abel]

Considering the verbage used by the standard, it's the first one that
I would see more as a perversion. A function call is /always/ done
through a pointer-to-function; it's just that function designators are
implicitly converted to pointer-to-function.

This seems to me along the same lines as saying that an array name is
converted to the pointer when used as the operand to [].

That is to say: It's technically correct... but is it art?

 

[Chris Dollin]

Considering the verbage used by the standard, it's the first one that
I would see more as a perversion. A function call is /always/ done
through a pointer-to-function; it's just that function designators are
implicitly converted to pointer-to-function.

This seems to me along the same lines as saying that an array name is
converted to the pointer when used as the operand to [].

(And as an operand to + and - and == and ...)

That is to say: It's technically correct... but is it art?

Does it matter if it's art?

 

[Keith Thompson]

Considering the verbage used by the standard, it's the first one that
I would see more as a perversion. A function call is /always/ done
through a pointer-to-function; it's just that function designators are
implicitly converted to pointer-to-function.

This seems to me along the same lines as saying that an array name is
converted to the pointer when used as the operand to [].

That is to say: It's technically correct... but is it art?

The phrase "technically correct" is often used for facts that are
considered inconvenient for some reason.

IMHO, it's sufficient to say simply that it's correct. Yes, function
calls are usually used with function names, and array indexing is
usually used with array names, but understanding that they really work
with pointers is important to understanding the language.

 

[Ben Pfaff]

That is to say: It's technically correct... but is it art?

I believe that Peter "Shaggy" Haywood can provide a relevant
quote here.

 

[Micah Cowan]

Micah Cowan said:

The syntax
for that would be something like:

(*rcont.hitf)(&myobj, &myray);

although, perversely:

rcont.hitf(&myobj, &myray);

would also be legal. [...]

Considering the verbage used by the standard, it's the first one that
I would see more as a perversion.

<shrug> Can we agree to differ? I find that the * is most helpful in
deciphering the code on a first reading.

Hey, what do i care what you want to use? I can read either just fine,
and would be quite at home messing with someone's code that uses
either style.

I was only trying to point out that, from the Standard's point of
view, you're /always/ invoking with a function pointer, and never a
function type. That certainly doesn't mean anyone else needs to see it
that way. But it may mean that you'll need a bit more justification
before calling your latter example a "perversity". ;-)

-Micah

 

[Micah Cowan]

Considering the verbage used by the standard, it's the first one that
I would see more as a perversion. A function call is /always/ done
through a pointer-to-function; it's just that function designators are
implicitly converted to pointer-to-function.

This seems to me along the same lines as saying that an array name is
converted to the pointer when used as the operand to [].

It's converted to a pointer always (except when an operand of & or
sizeof). You can't possibly tell me you've never used code like:

char ary[] = "string value";
char *p = ary; /* <--- */

even if you might prefer

char *p = &ary[0];

(as I frequently do).

The fact has a strong semantic meaning. The function -> function
pointer, despite the fact that it works the same way, may have less
impact on programming, since you nearly always are using them in
invocations, anyway. I was just trying to point out that RH had little
reason to call it a perversion, given the way it's discussed in the
Standard.

-Micah

 

[Richard Heathfield]

Micah Cowan said:

But it may mean that you'll need a bit more justification
before calling your latter example a "perversity". ;-)

I presume I can get some on eBay?

 

[Micah Cowan]

Micah Cowan said:


I presume I can get some on eBay?

I dunno... but TeX provides it quite well...

 

[Dave Thompson]

Micah Cowan said:


I presume I can get some on eBay?

I don't know about the justification, but, at least judging from the
spam I receive, you can certainly get the perversity. <GGG>

- David.Thompson1 at worldnet.att.net