Came up a while ago: http://forum.dlang.org/post/komuednbngkbeirrrptq@forum.dlang.org

On Sunday, 26 October 2014 at 14:14:43 UTC, Maxime Chevalier-Boisvert wrote:
> I'll do that if I have to, but it's cleaner with an override of new as it makes it impossible to mistakenly allocate the object outside of the pool. It's also nicer if you can pass arguments to your constructor.

Such thing are not very appreciated. But if you really want it, you can declare one disabled constructor, it will deny construction of an object, and declare a normal member function, which can serve as an initializer. Also emplace passes arguments to constructor, it can be done for any function, you can just copy emplace's source and tweak to your liking (if you're going to disable the constructor). If you think, simple type inference is not enough and want a real signature copy, you can look at the BlackHole template.

On Sunday, 26 October 2014 at 14:13:25 UTC, Maxime Chevalier-Boisvert wrote:
> What I'm trying to do is have some specific classes be pool-allocated though, not completely circumvent the GC.
>

The method I proposed just overrides `new` (i.e. _d_newclass).  What goes inside of `new` is up to you, including allocating from GC memory by calling the default via `__real__d_newclass` (The linker takes care of translating the symbol names). And since you have a `ClassInfo` object you can selectively choose which types are allocated from a pool, and which are allocated by the GC.

extern (C) Object __real__d_newclass(const ClassInfo ci)

extern (C) Object __wrap__d_newclass(const ClassInfo ci)
{
    if (ci.ClassName == "MyPoolAllocatedClass")
    {
        return allocateFromPool(ci);
    }
    else
    {
        retun __real__d_newclass(ci);
    }
}

This method is somewhat hackish, but I think it's the only way to override `new`.  Language support for this kind of thing would be nice. `@weak` attribute[1] perhaps, or `virtual`/`final` module methods anyone? `final` by default please. :)

Mike

[1] - https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Function-Attributes.html#Function-Attributes

On Sunday, 26 October 2014 at 23:20:21 UTC, Mike wrote:
> Language support for this kind of thing would be nice. `@weak` attribute[1] perhaps, or `virtual`/`final` module methods anyone? `final` by default please. :)
>
> [1] - https://gcc.gnu.org/onlinedocs/gcc-4.9.1/gcc/Function-Attributes.html#Function-Attributes

This is turning into a fun little exploration.  After reading this issue [1], I discovered that DMD already compiles all the runtime hooks as weak references, so you only need to declare a new `_d_newclass` implementation anywhere in your source code to override `new`.

version(DigitalMars)
{
    extern (C) Object _d_newclass(const ClassInfo ci)
    {
        // add your own `new` implementation here
    }
}

void main(string[] args)
{ }

Compile with:
dmd test.d

No special compiler/linker flags or symbol names. Cool!

LDC has support for decorating functions with LLVM attributes [2] that could potentially include creating `weak` symbols, but LDC will have to decorate `_d_newclass` this way in druntime before overriding with this technique will be possible.

GDC also has infrastructure for supporting such attributes [3], but the `weak` attribute will have to be added to the list, and decorations added to `_d_newclass` in the same way.

Maybe I'll submit some pull requests and see how they're received.

I still don't know how to call the default implementation, using this technique, without copying the source code from druntime.  That's not a deal-breaker, but it stinks.

The only way I was able to override `destroy` was to copy the entire object.di from druntime to my project folder and modify the code there.  That also stinks.

This little skirmish has opened up a few possibilities for my work.  Very interesting.

Mike

[1] - https://github.com/ldc-developers/ldc/issues/405
[2] - https://github.com/redstar/ldc/commit/69f231f48f355b6399d67950f057bea72f0a64c3
[3] - http://wiki.dlang.org/GDC/Using_GDC#Attributes

On 10/25/14 8:37 PM, Maxime Chevalier-Boisvert wrote:
> Hello,
>
> I was wondering if there have been updates regarding Andrei's
> announcement that he would rewrite the D garbage collector. Is there any
> kind of timeline for when a new version of the GC can be expected?

There is no timeline as of now. I'd need a good contiguous hunk of time to dedicate to this, and the opportunity hasn't shown itself so far. But I am optimistic I'll have the opportunity in the near future.

You should also know about the experimental Sociomantic GC for D2 which has been recently announced: http://goo.gl/lOvttC

> I also wanted to ask if there was an implementation of an object pool in
> the standard library. If not, I'm wondering what the best way to
> implement this is. Is there any way to overload new and destroy?
>
> I was thinking of using the templated emplace operator from std.conv to
> allocate class objects into a large flat array, and to derive
> pool-allocated classes from a PoolObject base class. This base class
> would contain linked list pointers to implement a free list, as well as
> templated static methods to allocate and free the objects. Any advice
> welcome.

My allocator (which has been mentioned) is a low-level backend for such stuff. It's of good quality (i.e. fast) but very primitive in the sense it has no porcelain on it - you need to instantiate the desired combination yourself, call directly methods such as allocate() and deallocate(), and traffic in void[].


Andrei