Using private constructor with std.experimental.allocater:make

earthfront via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Sun May 1 21:19:48 PDT 2016


On Sunday, 1 May 2016 at 19:18:38 UTC, Basile B wrote:
> CT make(CT, Alloc, A...)(auto ref Alloc al, A a)

This works. Thank you. Good point about __ctor alone not being 
sufficient.

>     auto memory = al.allocate(size);
...     <snip>
>     GC.addRange(memory.ptr, size, typeid(CT));

Nit: "GC.addRange..." -- this attempts to clean memory allocated 
manually.

> The problem is that the template make and emplace() are 
> **elsewhere** so they cannot see A.this() (== A.__ctor).
>
> A common way to fix this kind of problem is to make a template 
> mixin with the template that has the visibility and to mix it 
> in the current scope

I guess this is the best workaround at the moment.

There's a discontinuity between the GC and std.allocators.
"new A(1)" works, because the GC has implicit private access to 
classes.
I would love to see allocators in wider use. Workarounds are an 
obstacle to this.

Possible solutions:
* Emulate c++'s "friend" keyword somehow. D's rationale eschew's 
this.
* Somehow designate friendship via [selective] module import?
* Secret upcoming solution from Walter/Andrei. Weren't they 
discussing some sort of built in ref counting system?



More information about the Digitalmars-d-learn mailing list