On Monday, 30 December 2013 at 00:08:10 UTC, Ola Fosheim Grøstad wrote:
> On Sunday, 29 December 2013 at 23:58:34 UTC, Andrei Alexandrescu wrote:
>> Then don't use the GC.
>
> I agree!
>
> Thus: any language that makes it hard to not use the GC is not competing with C++ as a performant language. ;-]

Good job D isn't that language :-)

On Monday, 30 December 2013 at 11:23:22 UTC, JN wrote:
> The best you can do in those
> languages usually is to just not allocate stuff during the game.

Yeah. The techniques to accomplish this in GC-only languages surprisingly mirror some of the techniques where malloc is available, though. For instance, the object pool pattern has the object already allocated and what you do is just ask for an object from the pool and set it up for your needs. When you're done, you just give it back to the pool to be recycled. It's very similar to what you'd do in any other language, but a little more restricted (other languages, like D, might just treat the memory as untyped bytes and the "object pool" would be more flexible and could support any number of types of objects).

On Monday, 30 December 2013 at 14:59:49 UTC, Peter Alexander
wrote:
> Good job D isn't that language :-)

Yes, that would be great!! :-o

But... new isn't listed among overloadable operators, and I don't want to set allocators per class. I want to allocate the same class from different pools. How?

Segmented GC would be neat though. (GC limited to a set of
objects and other mechanisms like ref counting for pointers into
the segment.)

Region pools with reference counting to the region
would be nice too (you release the entire region and do ref
counting to the region rather than the objects in it)

On Monday, 30 December 2013 at 12:20:56 UTC, develop32 wrote:
> As far as I know, Unreal Engine 3 has its own GC implemention for its scripting system.

Yes, for heavy weight objects with complex relationships. So it closer to segmented GC.

On Monday, 30 December 2013 at 17:17:06 UTC, Ola Fosheim Grøstad wrote:
> But... new isn't listed among overloadable operators, and I don't want to set allocators per class. I want to allocate the same class from different pools. How?

See emplace:
http://dlang.org/phobos/std_conv.html#.emplace

On Monday, 30 December 2013 at 17:26:30 UTC, Chris Cain wrote:
>
> See emplace:
> http://dlang.org/phobos/std_conv.html#.emplace

Thanks. I guess that is the equivalent of c++ in-place new expression.

I hoped for solution that is a bit more transparent than creating my own new syntax though, a solution which makes replacing allocators across projects less work. *shrug*

On Monday, 30 December 2013 at 17:36:56 UTC, Ola Fosheim Grøstad wrote:
> Thanks. I guess that is the equivalent of c++ in-place new expression.

No problem and yes, that pretty much is the equivalent of C++'s in-place new.

> I hoped for solution that is a bit more transparent than creating my own new syntax though, a solution which makes replacing allocators across projects less work. *shrug*

I'm confused by this. Could you rephrase and/or explain?

On Monday, 30 December 2013 at 17:52:33 UTC, Chris Cain wrote:
> I'm confused by this. Could you rephrase and/or explain?

In cpp you transparently replace new gobally and through a hack (include files) map it to different pools for different sections of your code if you wish. Although explicit allocation from pools using regular new-syntax would be nice too.

On Monday, 30 December 2013 at 18:02:26 UTC, Ola Fosheim Grøstad wrote:
> In cpp you transparently replace new gobally and through a hack (include files) map it to different pools for different sections of your code if you wish. Although explicit allocation from pools using regular new-syntax would be nice too.

Sounds pretty dangerous to me. I wouldn't really describe that as "transparent" either. If it's working for you in C++, that's great. I wouldn't count on D adopting such an approach, however.

I think in the near future there's going to be a standard "allocator interface" (std.allocator) which will allow you to easily use different allocation schemes depending on what you're doing. I'm not sure how well this will work in practice (I'll need to play around with it some to see how well it works before I make a firm judgement), but I have good reason to believe it'll work well and it'll likely cover your use-cases pretty well too.

On Monday, 30 December 2013 at 18:22:22 UTC, Chris Cain wrote:
> Sounds pretty dangerous to me. I wouldn't really describe that as "transparent" either. If it's working for you in C++, that's great. I wouldn't count on D adopting such an approach, however.

Well, either that or using a thread local variable setting the current pool, I assume objective-c does that.

> I think in the near future there's going to be a standard "allocator interface" (std.allocator) which will allow you to easily use different allocation schemes depending on what you're doing.

Ok. :) as long as I don't have to pass the allocator around,mwhich is tedious.