🚀 go-pugleaf

I'm  interested in the issue of setting all those vtable related
hidden pointers, whilst 'bringing  in the sheaves'. Especiallly for
virtual bases, there can be a number of compiler-specific 
schemes, so attempts at redoing what the compiler does will
be difficult, requiring a per-os-per-compiler-per-option knowledge
table.

I have a dec 1993 article from the software- practice and experience
journal, entitled  'Making C++ Object Persistent: the Hidden Pointers'
by A. Biliris, S. Dar, and N. H. Gehani, all of AT&T Bell labs.

Now in that paper they suggest that the new operator can be spilt
  1) memory allocation
  2) hidden pointer setup
  3) call whatever constructor

One scheme (which they abandon due to the necessity of rewritting
the frequently-used parameterless constructor function),  involves
placing the object in mem from disk (skipping step 1),  step 2 is
performed, and a do-nothing parameterless constructor in step 3 is
called.   

My query is whether the new operator can indeed be split up like this.
Are they using a non-conforming C++ system?  I thought that if you 
overide the new operator, you don't get any of steps 1 or 2.