C++ pimpl

[Robert Caravani]

On Monday, January 23, 2012 02:19:35 AM Timon Gehr wrote:
> On 01/23/2012 01:49 AM, Martin Nowak wrote:
> > On Mon, 23 Jan 2012 01:33:47 +0100, Timon Gehr <timon.gehr at gmx.ch> wrote:
> >> On 01/23/2012 01:07 AM, so wrote:
> >>> On Mon, 23 Jan 2012 01:39:23 +0200, so <so at so.so> wrote:
> >>>> I have been asking that for some time now, i am afraid you won't
> >>>> get
> >>>> much of an audience.
> >>>> You can get rid of both additional allocation and indirection but
> >>>> it
> >>>> is not pretty. We could definitely use some help/sugar on this.
> >>>> 
> >>>> http://www.artima.com/cppsource/backyard3.html
> >>> 
> >>> http://www.digitalmars.com/d/archives/digitalmars/D/Implementation_h
> >>> iding_139625.html
> >>> 
Thanks for the links, it was a good read.
> >>> 
> >>> 
> >>> There is another issue Walter forgot to mention in the article.
> >>> I think there might be a way but looks like we also loose the
> >>> "destructor".
> >>> Which means we are all the way back to the
> >>> http://en.wikipedia.org/wiki/Opaque_pointer.
> >>> 
> >>> Walter, is there a way to get around destructor limitation?
What's the destructor limitation?
> >> 
> >> This seems to work.
> >> 
> >> a.di:
> >> 
> >> final class A{
> >> private this();
> >> static A factory();
> >> T1 publicMember1(int x);
> >> T2 publicMember2(float y);
> >> T3 publicField;
> >> // ...
> >> }
> >> 
> >> a.d:
> >> 
> >> class A{
> >> static A factory(){return new A;}
> >> T1 publicMember1(int x){ ... }
> >> T2 publicMember2(float y){ ... }
> >> T3 publicField;
> >> // ...
> >> private:
> >> T1 field1;
> >> T2 field2;
> >> }
> > 
> > This will even work with plain new/this, as the allocation is done
> > in the constructor. The difficulty is that you can't build inheritable
> > pimpls.
Hmm, I see some problems with this approach: It is not only impossible to 
derive from this class without using the di file with the full implementation 
(which might be acceptable)but you can't even use derived classes by an A 
reference, because the compiler would not use the vtbl because it assumes 
there are no derived classes. Which is not acceptable, in my opinion.

> 
> Ah, good to know. One solution would be to just add some dummy space to
> the class declaration (private void[256] dummy=void) so that the
> implementation can use it for private members. (union{void[256] dummy;
> struct{/*private_members*/}}) Of course, this is potentially wasteful.

I also thought of such variants, but as you already noted, they are either 
wasteful, or limited, or both.

The simplest and most efficient variant I could think of, was the one I 
already explained, but I am illustrating it here with some code, to make it 
more clear:
// base.d
import std.container;
class Base {
	this() {
	// ...
	}
	SList!int overrideMe() {
		//....
	}
@private_impl:
	int foo;
	float bar;
}

//////

Generate two .di files, with --private-impl compiler switch:
dmd -H -c --private-impl base.d

The --private-impl switch would cause the following:
 1. It creates two ".di" files, see below.
 2. It creates a hidden static "size" field in the object file:

If you don't pass the --private-impl switch, just one standard .di file is 
generated and the "@private_impl:" is interpreted as plain "private:".

// base.d generated code:
import std.container;
class Base {
	this() {
	// ...
	}
	SList!int overrideMe() {
		//....
	}
@private_impl:
	int foo;
	float bar;
	static size_t __size_of_object=actual_base_object_size;
}

// base.d -- This is the public interface:
import std.container;
//Non public imports are still necessary, because the compiler needs to check 
//that client code uses the same SList implementation.
// but imports only needed by method bodies, should be omitted, but how to 
tell this the compiler?
class Base {
	this(); // No inline, we are hiding the implementation!
	SList!int overrideMe(); 
@private_impl: // Omit private data, just a hint to the compiler that there 
are private hidden fields (and that there exists a hidden size field)
}

// base_private.di -- the second .di file, just the normally generated one.

If I want to create a derived class and I want to be independent of the base 
class implementation, I would simple import the public base.di file:

// derived.d
import base;
class D : Base {
	SList!int overrideMe() {
		// override it with something
		// access  my_field:
		my_field=2;
		// compiler would generate:
		int* p=cast(int*)
((cast(void*)this)+Base.__size_of_object+offset_of_my_field);
		*p=2;
		// instead of:
		int* p=cast(int*)
((cast(void*)this)+offset_of_my_field_including_statically_known_base_size);
		*p=2;
		// A class deriving from D, would also have to add Ds size and so on, 
but as these offsets don't change during the life time of a program, the 
calculated offsets could easily be cached. 
	}
@private_impl:
	int my_field;
}

 If I don't care about implementation hiding, I would simple import the 
base_private.di file, and I would have statically calculated offsets. Derived 
classes in the same library would usually do that.

// main.d

import derived;
import std.container;

void main() {
	D d=new D;
	// I am using the public .di file, thus new has to look up the objects size 
at runtime in the library and allocate the needed space, then it triggers the 
now non inlined initialization sequence:
	// - initialize all base members
	// - initialize all derived members
	// - call base class constructor
	// - call derived class constructor
	// -> can be optimized if derived class uses the non public interface.

	// use d.
	// d gets destroyed, simply call the destructors, and free the used space.
}

If you don't rename the private implementations, but simply use another module 
lookup path, you can switch implementations by no code change at all, simply 
comple main.d with the private module search path and you get the old 
behaviour.
--> client code can choose, without a code change in the library, if you don't 
mind the static size fields, not even a recompile of the library is necessary.

I hope it is now more clear what my basic approach is. I think the benefits 
are overwhelming and it seems to be easy, maybe too easy. So I am pretty sure 
it is not that simple, but what is it I am missing?

Best regards,

Robert