Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!munnari!otc!mikem From: mikem@otc.OZ (Michael Mowbray) Newsgroups: comp.lang.c++ Subject: Re: explicit initializations Message-ID: <58@otc.OZ> Date: Sun, 14-Dec-86 02:47:05 EST Article-I.D.: otc.58 Posted: Sun Dec 14 02:47:05 1986 Date-Received: Tue, 16-Dec-86 01:31:11 EST References: <340@inria.UUCP> Organization: O.T.C. Systems Development, Australia Lines: 229 In article <340@inria.UUCP>, shapiro@inria.UUCP (Marc Shapiro) writes: > > This base class declares a private, virtual initializer > "initialize()". The constructor for the base class calls "initialize()" > which is re-declared in all the subclasses to do whatever is needed. > Unluckily, this does not work: even though "initialize()" is a virtual, it > is always base::initialize which is called, as demonstrated by the > following program: > > [ .. deleted .. ] > > I find it odd that the call to virtual 'sz' has a different semantics > within the constructor for base (call base::sz) and within > procedure 'size' (call this->sz). Is this a bug or a feature? > When I first came across this occurrence, it seemed like a bug to me. I mailed Bjarne about it some time ago. The following is a condensed version of what I said: ************************************************************************* When a derived class's constructor calls its base class's constructor, it ought to initialize the derived class's vptr first, just in case the base class constructor uses it in some way. Currently what happens in the derived class's ctor is: struct Derived *_Derived__ctor( _auto_this, ..... ) struct Derived *_auto_this; { if (_auto_this == 0) /* allocate space */ _auto_this = (struct Derived *) _new((long)...); _auto_this = _Base__ctor(_auto_this, .... ); /* But vptr not yet set! */ _auto_this->_Base__vptr = _Derived__vptr; .... etc.... return _auto_this; } /* and a declaration of an instance of Derived would generate: */ struct Derived d; _Derived__ctor(&d); So if the Base ctor wanted to use a virtual function, it would make a mistake. Perhaps more correct code would be: struct Derived *_Derived__ctor( _auto_this, _auto_Base__vptr, ..... ) struct Derived *_auto_this; int (**_auto_Base__vptr)(); { if (_auto_this == 0) _auto_this = (struct Derived *) _new((long)...); _auto_this = _Base__ctor(_auto_this, _auto_Base__vptr, .... ); ...etc... return _auto_this; } struct Base *_Base__ctor(_auto_this, _auto_Base__vptr, ....) struct Base *_auto_this; int (**_auto_Base__vptr)(); { if (_auto_this == 0) _auto_this = (struct Base *) _new((long)...); _auto_this->_Base__vptr = _auto_Base__vptr; ...etc... return _auto_this; } /* Declarations of instances of Base and Derived would */ /* have to generate: */ struct Base b; _Base__ctor(&b, _Base__vtbl); struct Derived d; _Derived__ctor(&d, _Derived__vtbl); I.e: Leave it to the Base ctor to set the vptr, based on what is passed to it. ******************************************************************** The essence of Bjarne's reply was that a Base constructor must establish an environment for whatever happens later. I believe he's RIGHT. When you're writing the code for the Derived class's virtual function, you tend to assume that everything's ok, but if the above were implemented, you could only be sure of that if you had the code for the Base class's virtual function and constructor to look at and made sure you haven't forgotten anything. Therefore, doing things along the lines above is probably a recipe for a time-bomb. So, in answer to the question "Is it a bug or a feature?" I think the answer is "it's a feature". - One shouldn't expect virtual functions to work as normal until the instance has been properly constructed, because a derived class shouldn't be allowed to alter how the base class is constructed, apart from passing appropriate arguments to the base class constructor. Also, the only reason for wanting to do the above is to enable explicit initialisation of an instance. (This was also my reason for initially wanting to do the above.) > Conclusion: there exists a need for a syntax to express explicit > initialization of an instance. I'm having difficulty estimating just how often such a thing is needed. There are certainly times when you DO need it (e.g: if you're doing low-level stuff, and a particular instance MUST reside at a certain location.) But I have difficulty imagining where else it's essential. See Below. > This need would be filled by a syntax to get the address of the > constructor. Superficially, it could be done this way: class SomeClass { ...... public: SomeClass(); ~SomeClass(); }; SomeClass::* ctor_ptr() = &SomeClass::SomeClass; SomeClass::* dtor_ptr() = &SomeClass::~SomeClass; or something like that. This would also need some way to express that it's a pointer to a constructor rather than, say, a pointer to a void member fn. In any case, how would you use this? main() { int buf[.....]; (((SomeClass*)buf)->*ctor_ptr)(); ????? ..... do whatever ..... (((SomeClass*)buf)->*dtor_ptr)(); } This wouldn't work correctly, because the translator has no way of knowing whether to actually free space when the dtor_ptr is called. Allowing constructors/destructors to be called in the normal syntax as per the following isn't good enough either: int buf[.....]; // assuming alignment is correct. ((SomeClass*)buf)->SomeClass(); // perform whatever initialisations // are needed, using buf as 'this'. Once again, the destructor can't be called properly. This is a reason to be wary of providing a feature for taking addresses of constructors. The mechanism I posted earlier: class SomeClass { ..... public: SomeClass( ...args...); ~SomeClass(); }; struct Aux_SomeClass : public SomeClass { Aux_SomeClass(void* buf, ...args...) : (...args...) { this = (this==0) ? (Aux_SomeClass*)buf : this; } }; main() { int buf[......]; SomeClass *sc = (SomeClass*) new Aux_SomeClass(buf, ...args...); } isn't good enough either, for the same reason. There doesn't seem to be any way of arranging for ~SomeClass() to be called correctly for buf at the end of main(). (``delete sc;'' wouldn't work correctly because buf is an automatic variable.) My Conclusion: Explicit initialisation and tidy-up of instances has uses but probably not that many. The obvious syntax for taking addresses of constructors doesn't seem to have any chance of working in the case of destructors. To achieve the desired aim, maybe you'd need a syntax like: main() { int buf[.....]; SomeClass sc(...args...) : buf; } I.e: something that let's the translator know exactly what you're doing. This sort of thing obviously involves work and the net gain to the language overall is probably not that great. > Such an addition would leave room for the future > enhancement of dynamic linking (that's why my group needs it). Marc, would you explain your need for this in more detail? Mike Mowbray Systems Development Overseas Telecommunications Commission (Australia) UUCP: {seismo,mcvax}!otc.oz!mikem ACSnet: mikem@otc.oz