leo@atcmp.nl (Leo Willems) (06/22/89)
I recently put a question on the net, which, i think, did not
reach many places, or the right readers.
(When re-reading this example i discovered a bug of which i'm not sure
i corrected it in my initial posting, to be sure i marked the line in this
posting. Sorry for that)
Since then, i found that my problem which (still) exists for our C++ compiler
(a version of cfront) does compile correct under G++.
So here it is again, if it's a stupid question, please e-flame anyway so
i now this message got out.
I recently made a dispatch function which calls a memberfunction from
some class B. This code is shown below
class B{
public:
void put() { puts("BBBBBB"); }
};
typedef void (B::*PF)();
void disp(B* bp, PF f)
{
(bp->*f)();
}
main()
{
B ab;
disp(&ab, &B::put);
}
That worked quit well.
After that i extended the B class with a virtual member put().
class B{
public:
virtual void put() { puts("BBBBBB"); } // BUG: the previous
// version did not
// have the word
// virtual
};
Our C++ compiler (1.2E) did not complain, but our C compiler did.
The C code generated was somewhat complex, using a ternary operator.
Sorry, to put this in, but explains the error.
void disp (_au0_bp , _au0_f )
struct B *_au0_bp ;
PF _au0_f ;
{
(*(((void (*)(/* struct B* */))(((((unsigned int )_au0_f ))& (~ 127))? _au0_f : (_au0_bp ->
_B__vptr [(((unsigned int )_au0_f ))- 1])))))( _au0_bp ) ;
}
Our C compiler is complaining that the =false= part of the ternary operator
is of the wrong pointer type, which is true i think:
true part: _au0_f is of type PF.
false part: this gives a pointer of type int (*)();
(it is one of the elements of the vtable from B:
implemented as: int (**_B__vptr)(); )
If i patch the generated code witch a cast (PF) in front of the false part
everything works fine :-(
Is there any chance that my solution (without a cast!) should work?
Or is this kind of solution not supposed to work for classes with virtuals? (it
works fine in G++)
Thanks, any reaction is welcome.
Leo Willems Internet: leo@atcmp.nl
AT Computing UUCP: mcvax!hp4nl!kunivv1!atcmpe!leo
P. O. Box 1428
6501 BK Nijmegen
The Netherlandsjss@hector.UUCP (Jerry Schwarz) (06/26/89)
In article <527@atcmpe.atcmp.nl> leo@atcmp.nl (Leo Willems) writes: > > >Since then, i found that my problem which (still) exists for our C++ compiler >(a version of cfront) does compile correct under G++. >So here it is again, if it's a stupid question, please e-flame anyway so >i now this message got out. I can't figure out what the question is. The item contains a compiler bug report. Is the question whether or not it is a bug? > >Our C++ compiler (1.2E) did not complain, but our C compiler did. >The C code generated was somewhat complex, using a ternary operator. > I post the following about once every 6 months, its been a while so here it is: A complaint from the C compiler while doing a compilation using cfront is always a bug in the compilation system. It might be a bug in cfront, in the C compiler or in the way they are put together. This is what we mean when we say that cfront is a compiler that uses C as an intermediate language rather than a preprocessor. Jerry Schwarz AT&T Bell Labs, Murray Hill
leo@atcmp.nl (Leo Willems) (06/29/89)
From article <11702@ulysses.homer.nj.att.com>, by jss@hector.UUCP (Jerry Schwarz): > In article <527@atcmpe.atcmp.nl> leo@atcmp.nl (Leo Willems) writes: >> >> >>Since then, i found that my problem which (still) exists for our C++ compiler >>(a version of cfront) does compile correct under G++. >>So here it is again, if it's a stupid question, please e-flame anyway so >>i now this message got out. > > I can't figure out what the question is. The item contains > a compiler bug report. Is the question whether or not it is a bug? > No, the question is that I wonder if the presented code is correct C++ in the given example. If it is, the compiler generates incorrect code (see the ternary operator) However, if the presented code is not correct I would like to know why. I hope this clarifies my previous posting. > > This is what we mean when we say that cfront is a compiler that uses > C as an intermediate language rather than a preprocessor. > Am I correct that in either case (bad C code generation, or bad C++ code without a warning) I should contact the compiler supplier? Leo Willems Internet: leo@atcmp.nl AT Computing UUCP: mcvax!hp4nl!kunivv1!atcmpe!leo P. O. Box 1428 6501 BK Nijmegen The Netherlands