Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mit-eddie!mit-amt!peter
From: peter@mit-amt.MEDIA.MIT.EDU (Peter Schroeder)
Newsgroups: comp.lang.c++
Subject: problems in cfront 2.0 with +e[0|1] options and __ptbl__...
Keywords: cfront 2.0, virtual, pure virtual, __ptbl, __vtbl, bug/feature?
Message-ID: <1379@mit-amt.MEDIA.MIT.EDU>
Date: 11 Jan 90 15:17:39 GMT
Organization: MIT Media Lab, Cambridge, MA
Lines: 76


// I am running cfront 2.0 and have a problem with the +e[0|1] option.
// Is it a bug?

// this is `test.h'
// ***************************************
class base{
public:
	virtual	void	foobar() = 0;
};

class derived : public base{
public:
	derived() {}
	void	foobar() {}
};
// ***************************************

// this is `test.C'
// ***************************************
#include	"test.h"

void
bla()
{
	derived d;
}
// ***************************************

// If I compile `test.C' with the +e0 option I get (heavily edited)

extern struct __mptr* __ptbl__4base__test_C;
extern struct __mptr* __ptbl__7derived__test_C;

char bla__Fv ()
{ 
struct derived __1d ;

#line 6 "test.C"
( (( (( (((((struct base *)(& __1d )))|| (__nw__FUi ( sizeof (struct base)) ))?((((struct base *)(& __1d )))-> __vptr__4base = (struct
#line 6 "test.C"
__mptr *) __ptbl__4base__test_C):0 ), (((((struct base *)(& __1d )))))) ), ((& __1d )-> __vptr__4base = (struct __mptr *) __ptbl__7derived__test_C)) ), (((& __1d )))) ;
}

// the last mess is the inline constructor for derived. It makes a reference
// to the `extern struct __mptr* __ptbl__7derived__test_C', as well as
// `extern struct __mptr* __ptbl__4base__test_C' but these `struct*'
// are never defined in this file. This makes sense, since I used the +e0
// flag. But, I cannot ever hope to generate the actual definition of this
// `struct __mptr*' running +e1 on some other file because the
// filename of `test.C' is encoded in this `extern struct __mptr*'.
// Result: I get unresolved externals complaints from the linker, which
// I can only get to go away by compiling all files which include `test.h'
// with the +e1 option. The very thing I am trying to avoid.
// Interestingly enough changing base::foobar to plain virtual (from pure
// virtual) gives me this

extern struct __mptr __vtbl__4base[];
struct __mptr* __ptbl__4base__test_C = __vtbl__4base;

// so now I am only left with an unresolved external for the other one
// `__ptbl__7derived__test_C'. Better, but not good enough.


// What I generally do is that I compile all files in my system with +e0, but
// one special file (which I call `vtbl.C'), which only contains `#include's
// for all header files which have virtual functions. So far this never
// caused a problem. This is my first use of a pure virtual and that broke
// it.
//
// Am I missing something or have I stumbled upon a bug?
// Any clarification you can offer would be appreciated.

// Thank you
// Peter
// peter@media-lab.media.mit.edu