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