In article <347o3s$m4i@hpsystem1.informatik.tu-muenchen.de> schuenem@Informatik.TU-Muenchen.DE (Ulf Schuenemann) writes:
>
>> ... An expression which evaluates to a
>> function is replaced by its address, and the type becomes pointer-to-function.
>...
>Toying with C++ 'gcc version 2.4.3' I got the following complaints (shown
>as comments) that raised some questions I couldn't find an answer for:
>
> int f();
> typedef int(*Intproc)();
> Intproc fp;
>
> fp = f;
> fp = &f;
> *fp = f; // invalid lvalue in assignment
> *fp = &f; // invalid lvalue in assignment
>
>*fp looks like a function-object, so it gets turned into a pointer.
>But this pointer is a temporary, that can't be a lvalue. Okay.
>
> f==fp;
> f==*fp;
> &f==fp;
> &f==*fp;
> f==&f;  // not enough type information
>
>f looks like a function-object, so it gets turned into its address.
>&f surely is the address of a function. So is it a bug that gcc can't
>compare them?

Yes.  It's a bug.

>> When you use the function-call operator "()", it assumes the operand on the
>> left is a pointer to a function, and calls the function at that address.
>
> fp();
> (*fp)();
> (***fp)();
>
> (         &f)(); // called object is not a function
> ((Intproc)&f)();
> (*(         &f))(); // invalid type argument of `unary *'
> (*((Intproc)&f))();
>
>&f surely is the address of a function, but why does it make if difference
>with/without cast? Does this mean that the type of (&f) IS NOT automatically
>Intproc? What type is it then? Or is this a bug?

It's a bug.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- domain addr: rfg@netcom.com ----------- Purveyors of Compiler Test ----
---- uucp addr: ...!uunet!netcom!rfg ------- Suites and Bullet-Proof Shoes -

In article <3405bt$pvp@engnews2.Eng.Sun.COM>, clamage@Eng.Sun.COM (Steve Clamage) writes:
[#10002 Re: Changing qualifier a.b to a->b and back]
> ... An expression which evaluates to a
> function is replaced by its address, and the type becomes pointer-to-function.
> ... We can also write "(****************fp)()"
> because at each stage of evaluating the pointer dereferences, the dereference
> has a function type, which is replaced by the address of the function.
> ... It means that you can never have a function object, since
> anything that looks like a function gets turned immediately into its address.

Toying with C++ 'gcc version 2.4.3' I got the following complaints (shown
as comments) that raised some questions I couldn't find an answer for:

 int f();
 typedef int(*Intproc)();
 Intproc fp;

 fp = f;
 fp = &f;
 *fp = f; // invalid lvalue in assignment
 *fp = &f; // invalid lvalue in assignment

*fp looks like a function-object, so it gets turned into a pointer.
But this pointer is a temporary, that can't be a lvalue. Okay.

 f==fp;
 f==*fp;
 &f==fp;
 &f==*fp;
 f==&f;  // not enough type information

f looks like a function-object, so it gets turned into its address.
&f surely is the address of a function. So is it a bug that gcc can't
compare them?

> ...
> When you use the function-call operator "()", it assumes the operand on the
> left is a pointer to a function, and calls the function at that address.

 fp();
 (*fp)();
 (***fp)();

 (         &f)(); // called object is not a function
 ((Intproc)&f)();
 (*(         &f))(); // invalid type argument of `unary *'
 (*((Intproc)&f))();

&f surely is the address of a function, but why does it make if difference
with/without cast? Does this mean that the type of (&f) IS NOT automatically
Intproc? What type is it then? Or is this a bug?

Though not a novice in C/C++ I always have to concentrate hard
when using function pointers, and some questions still remain open...
(Please sent answers and enlightment per e-mail as I'm going on
holiday - old articles are thrown out quite fast in this newsgroup)


Ulf Schuenemann

--------------------------------------------------------------------
Ulf Sch   nemann
Institut f   r Informatik, Technische Universit   t M   nchen.
email: schuenem@informatik.tu-muenchen.de