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-b...c/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-b.../src/rt/ray.h?

and object.h (for the OBJECT type):

http://www.radiance-online.org/cgi-b...ype=text/plain

Thanks

Marcus

[Richard Heathfield]

Marc said:

<snip>

http://www.radiance-online.org/cgi-b...c/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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Micah Cowan]

Richard Heathfield <in*****@invalid.invalid> writes:

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:

Richard Heathfield <in*****@invalid.invalid> writes:

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Jordan Abel]

On 2006-03-10, Micah Cowan <mi***@cowan.name> wrote:

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]

Jordan Abel wrote:

On 2006-03-10, Micah Cowan <mi***@cowan.name> wrote:

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?

--
Chris "truth is stranger than friction" Dollin
"Who do you serve, and who do you trust?"

[Keith Thompson]

Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-10, Micah Cowan <mi***@cowan.name> wrote:

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.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Pfaff]

Jordan Abel <ra*******@gmail.com> writes:

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

I believe that Peter "Shaggy" Haywood can provide a relevant
quote here.
--
"I'm not here to convince idiots not to be stupid.
They won't listen anyway."
--Dann Corbit

[Micah Cowan]

Richard Heathfield <in*****@invalid.invalid> writes:

Micah Cowan said:

Richard Heathfield <in*****@invalid.invalid> writes:

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]

Jordan Abel <ra*******@gmail.com> writes:

On 2006-03-10, Micah Cowan <mi***@cowan.name> wrote:

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?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Micah Cowan]

Richard Heathfield <in*****@invalid.invalid> writes:

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?

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

[Dave Thompson]

On Fri, 10 Mar 2006 19:19:08 +0000 (UTC), Richard Heathfield
<in*****@invalid.invalid> wrote:

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?

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