This is a proposal for a language addition to C++. It provides users a
way to initialize the internal pointers (virtual function table, and
virtual base class pointers), in a way that does not depend on the
implementation of the language constructs, or on a particular
compiler's formatting of the object.


Need for the feature:

We are storing objects to disk.  When we read them back into memory, we need
an implementation independent way of restoring any internal structure built
by the C++ compiler/runtime mechanisms, without altering any user data.


Proposed language syntax:

We suggest that the desired behavior is that already supplied by the default
void constructor, and overloaded "new" operator:

 new (someAddr) Foo();

In fact, this is how we have implemented our persistent object store's
ability to reestablish the C++ internal structure.  Unfortunately, this
removes the void constructor from application use.  We would like to
obtain the same behavior even if the programmer has redefined the default
constructor, and propose the following syntax:

 new (someAddr) ::Foo();

This is very analogous to the usage of "::new" when the programmer has
overriden the standard "new" operator.

Gary Randolph
Eastman Kodak Company

I'll need some more time to think about the reasonability of the proposed
syntax, but I'll second the need for something that allows *complete*
static initialization of an object in a compiler-independent way.  I want
to be able to put an object in ROM on an embedded computer, and right now I
have to tapdance very fast with compiler-dependent naming schemes to do it.
--
------------------------------------------------------------------------
Speaker-to-managers, aka
Bruce Cohen, Computer Research Lab        email: brucec@tekchips.labs.tek.com
Tektronix Laboratories, Tektronix, Inc.                phone: (503)627-5241
M/S 50-662, P.O. Box 500, Beaverton, OR  97077

In article <1990Nov21.152532.5147@ssd.kodak.com> randolph@ssd.kodak.com (Gary L. Randolph) writes:

> new (someAddr) ::Foo();

as a proposed 'extension' to C++.  It must be noted that this already has a
valid meaning in C++.  It is interpretted as the creation of an instance of
the global type 'Foo' (as opposed to any nested type 'Foo') with a placement
argument 'someAddr' and using the default constructor for the global type
'Foo'.  This is not a free hole in the C++ syntax.

There are other reasons why this is a dangerous idea.  The C++ language does
not imply the existance of these tables, or the pointers to them.  They are
in fact a manifestation of typical implementations of the C++ language.

In a system which can resolve apparently polymorphic calls into monomorphic
calls, virtual function tables, and their corresponding pointers may be
eliminated.  Systems which support 'Tagged' hardware architectures may be
able to manage polymorphic behaviour using associative hardware mechanism,
thus eliminating the need for these pointers altogether.

I am all for being able to describe highly flexible persistant mechanisms,
but they must be described by language proscribed methods, and not using
"under-the-hood" techniques.

Currently proposals for supporting MetaClasses in C++ are starting to appear.
Indeed I have been doing this kind of thing myself for nearly five years
in C++.  These metaclasses will have either a language interface, or a
standard library interface, and will allow the polymorphic serialisation
mechanisms you need to describe persistant models very well.

Martin O'Riordan
C++ Development Lead, Microsoft