www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Possibility of non stop-the-world GC in the future?

reply "Nicholas Smith" <nmsmith65 gmail.com> writes:
I'm interested in experimenting with game development in D, but 
the only thing putting me off is D's heavy GC reliance, which at 
the moment is a stop-the-world GC.

One of the biggest killers in game development is unreliable 
performance and before I tread down the D path I'm interested in 
knowing just what it is possible to do with the GC in D.

I'm not so knowledgable in the theory behind GCs but I know that 
in natively compiled languages your options are much more 
limited. I found CDGC as an apparently abandoned attempt at a 
concurrent GC (which also uses fork(), but the way Windows is 
going I'm caring less and less about them anyway).

So, how good can D's GC get?
Feb 18 2013
next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 18 February 2013 at 08:33:41 UTC, Nicholas Smith wrote:
 I'm interested in experimenting with game development in D, but 
 the only thing putting me off is D's heavy GC reliance, which 
 at the moment is a stop-the-world GC.

 One of the biggest killers in game development is unreliable 
 performance and before I tread down the D path I'm interested 
 in knowing just what it is possible to do with the GC in D.

 I'm not so knowledgable in the theory behind GCs but I know 
 that in natively compiled languages your options are much more 
 limited. I found CDGC as an apparently abandoned attempt at a 
 concurrent GC (which also uses fork(), but the way Windows is 
 going I'm caring less and less about them anyway).

 So, how good can D's GC get?

This is technically possible. But require a lot of work. We are far away from it. You may want to talk with Manu about using for games.
Feb 18 2013
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 09:33, schrieb Nicholas Smith:
 I'm interested in experimenting with game development in D, but the only
 thing putting me off is D's heavy GC reliance, which at the moment is a
 stop-the-world GC.

 One of the biggest killers in game development is unreliable performance
 and before I tread down the D path I'm interested in knowing just what
 it is possible to do with the GC in D.

 I'm not so knowledgable in the theory behind GCs but I know that in
 natively compiled languages your options are much more limited. I found
 CDGC as an apparently abandoned attempt at a concurrent GC (which also
 uses fork(), but the way Windows is going I'm caring less and less about
 them anyway).

 So, how good can D's GC get?

I wen't down this path already and I ended up not using the GC at all: http://3d.benjamin-thaut.de/?p=20 -- Kind Regards Benjamin Thaut
Feb 18 2013
next sibling parent reply dennis luehring <dl.soluz gmx.net> writes:
Am 18.02.2013 11:35, schrieb Benjamin Thaut:
 I wen't down this path already and I ended up not using the GC at all:
 http://3d.benjamin-thaut.de/?p=20

are your speed fixes - for example the TypeInfo string creation etc. part of current druntime?
Feb 18 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 13:48, schrieb dennis luehring:
 Am 18.02.2013 11:35, schrieb Benjamin Thaut:
 I wen't down this path already and I ended up not using the GC at all:
 http://3d.benjamin-thaut.de/?p=20

are your speed fixes - for example the TypeInfo string creation etc. part of current druntime?

Some of the problems have already been fixed since I wrote the article, but not all of them. About your particular question: I'm currently in the progress of getting it ready to be merged (d-style and other nitpicking stuff and some problems in phobos) https://github.com/D-Programming-Language/druntime/pull/370 -- Kind Regards Benjamin Thaut
Feb 18 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 15:14, schrieb John Colvin:
 On Monday, 18 February 2013 at 12:56:33 UTC, Benjamin Thaut wrote:
 Am 18.02.2013 13:48, schrieb dennis luehring:
 Am 18.02.2013 11:35, schrieb Benjamin Thaut:
 I wen't down this path already and I ended up not using the GC at all:
 http://3d.benjamin-thaut.de/?p=20

are your speed fixes - for example the TypeInfo string creation etc. part of current druntime?

Some of the problems have already been fixed since I wrote the article, but not all of them. About your particular question: I'm currently in the progress of getting it ready to be merged (d-style and other nitpicking stuff and some problems in phobos) https://github.com/D-Programming-Language/druntime/pull/370

Have you already done the nitpicking corrections and not pushed them to github or would you be interested in a pull request fixing them.

I'm currently in the progress of doing so. I had exams and thus not that much time. But they are over now and I can continue to work on this pull request. I tend to only push when all currently known issues are fixed. Thats why there are no new commits yet. -- Kind Regards Benjamin Thaut
Feb 18 2013
prev sibling next sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 13:40, schrieb Joseph Rushton Wakeling:
 On 02/18/2013 11:35 AM, Benjamin Thaut wrote:
 I wen't down this path already and I ended up not using the GC at all:

 http://3d.benjamin-thaut.de/?p=20

But reading your blog post, it seems that the main problem was not GC in the general sense, but the fact that for various functionality druntime makes unnecessary allocations. Deal with those, and with-GC D ought to speed up a lot. Or have I misunderstood what you wrote?

The main problem is that programming with a GC encourages programming with memory leaks. As the gc will take care of any leaked memory and you don't get any feedback about how much memory you actually allocate. Also even if you do manual pooling and use a GC you still pay a big performance impact because the GC will scan the pooled memory without actually freeing anything. But scanning takes time too. And those interrupts by the GC will be long enough to interrupt regular gameplay. D would at least need a incremental Mark & Sweep to be usable in games. But in my opinion a GC is not needed at all when developing games, it makes a lot of sense for other fields though. -- Kind Regards Benjamin Thaut
Feb 18 2013
parent Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 15:38, schrieb deadalnix:
 On Monday, 18 February 2013 at 12:54:24 UTC, Benjamin Thaut wrote:
 The main problem is that programming with a GC encourages programming
 with memory leaks. As the gc will take care of any leaked memory and
 you don't get any feedback about how much memory you actually allocate.

You can apply the same reasoning to any language feature. Bound checking encourage lazy buffer overflow checking. OOP and functional encourage indirect branching. And I can go on and on.

Of course. I'm just saing that in the field of game programming beeing aware of the memory layout and beeing aware in what way memory is used is the key factor for good performance. Having a GC makes it way to easy to just ignore all the memory related issues, which is why I don't like programming with a GC in the field of games.
 Everything that help a programmer is generally good, as long as getting
 performances back is allowed with extra work (what GC.free allows you to
 do). In other terms, if you free what you allocate you get back to
 manual memory management (well, expect some runtime weirdness).

 Also even if you do manual pooling and use a GC you still pay a big
 performance impact because the GC will scan the pooled memory without
 actually freeing anything. But scanning takes time too. And those
 interrupts by the GC will be long enough to interrupt regular gameplay.
 D would at least need a incremental Mark & Sweep to be usable in
 games. But in my opinion a GC is not needed at all when developing
 games, it makes a lot of sense for other fields though.

You'll find that in term of memory management, no magic solution exists. Sometime GC is faster, sometime relying on manual memory management is the best. Most of a the time an hybrid approach between several techniques best results.

Agreed. But as long as D does not have a Garbage Collector that is as powerfull as the GC of the .NET 4 runtime you will be better of (performance wise) not using a GC at all when programming performance critical parts of game engines. -- Kind Regards Benjamin Thaut
Feb 18 2013
prev sibling next sibling parent reply JoeCoder <dnewsgroup2 yage3d.net> writes:
On 2/18/2013 5:35 AM, Benjamin Thaut wrote:
 I wen't down this path already and I ended up not using the GC at all:

 http://3d.benjamin-thaut.de/?p=20

I very much enjoyed this article. Hopefully your changes can be applied upstream. A couple of my own ideas, in hopes that those with more knowledge can comment: 1. A nogc attribute. This would work similarly to pure/safe/nothrow and would check at compile time that annotated functions or any they call allocate any memory enforced by the GC. Then phobos would no longer be a "landmine" for those with realtime requirements. 2. GC.collect(timeout). This would run a collection only until timeout is reached. It could be called with timeout=remaining frame time, and would allow expensive collections to span multiple frames.
Feb 18 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 18:49, schrieb JoeCoder:
 1.  A  nogc attribute.  This would work similarly to pure/safe/nothrow
 and would check at compile time that annotated functions or any they
 call allocate any memory enforced by the GC.  Then phobos would no
 longer be a "landmine" for those with realtime requirements.

I really would love to have that too. The problem with this still would be exceptions because D throws by reference and not by value like C++. To make this work there would be the need to add a special Exception allocator and make the compiler emit delete calls in case the exception is caught and not rethrown or something similar. Kind Regards Benjamin Thaut
Feb 18 2013
parent JoeCoder <dnewsgroup2 yage3d.net> writes:
On 2/19/2013 7:46 AM, bearophile wrote:
 There is some discussion here:
 http://d.puremagic.com/issues/show_bug.cgi?id=5219

 Bye,
 bearophile

Thanks for the heads-up. I added a vote. Is it possible/permissible to vote for an issue more than once?
Feb 19 2013
prev sibling parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 18.02.2013 16:08, schrieb Sergei Nosov:
 On Monday, 18 February 2013 at 10:35:59 UTC, Benjamin Thaut wrote:
 I wen't down this path already and I ended up not using the GC at all:

 http://3d.benjamin-thaut.de/?p=20

http://dlang.org/garbage.html has a list of features that rely on GC and I would say everything in this list is something you cannot (simply) do without dynamic allocation. And as far as I'm concerned, you don't want to use even dynamic allocation in a game due to real-time constraints, since any dynamic allocation is non-deterministic. I don't know any "serious" project that doesn't use pre-allocation and stuff.

Well games are only soft-realtime. So you can afford having dynamic allocations. But you are correct. For dynamic allocations it is usually tried to use custom allocators which are backed by preallocated memory blocks. But still its a lot less of a problem to use malloc a free on a even during the simulation compared to a stop the world mark & sweep.
 Do I understand it correctly, that you pointed out the parts in
 druntime/phobos that "overrely" on GC (could be done without it, but
 done otherwise)?

Yes correct. But if you would do them otherwise you wouldn't need a GC in the first place. The whole point of the GC is that you can be more productive by not caring about this stuff.
 Cause if not - avoiding everything from that list should make GC present
 almost unnoticeable. And that's what you want to do anyways, whether GC
 is present or not, if you're really targeting real-time.

Correct. Still I rather have a system that gives me errors when I make hidden runtime allocations then having the GC clean them up for me. Coding by convetion never works out well, especially in lager teams. Kind Regards Benjamin Thaut
Feb 18 2013
parent reply Benjamin Thaut <code benjamin-thaut.de> writes:
Am 19.02.2013 17:45, schrieb Minas Mina:
  nogc sounds nice, but how could someone use classes(OOP) with this?

The same way you do in c++. Manual memory management.
Feb 19 2013
parent Dmitry Olshansky <dmitry.olsh gmail.com> writes:
23-Feb-2013 14:25, Minas Mina пишет:
 On Tuesday, 19 February 2013 at 18:45:00 UTC, Benjamin Thaut wrote:
 Am 19.02.2013 17:45, schrieb Minas Mina:
  nogc sounds nice, but how could someone use classes(OOP) with this?

The same way you do in c++. Manual memory management.

But I guess you would like to have OOP as well. Would that be possible with nogc?

std.conv.emplace It has some bugs presently though I haven't hit a single one but there is. See e.g. this pull: https://github.com/D-Programming-Language/phobos/pull/1082 Vote up. Or was that only for bugzilla ? :) -- Dmitry Olshansky
Feb 23 2013
prev sibling next sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 02/18/2013 11:35 AM, Benjamin Thaut wrote:
 I wen't down this path already and I ended up not using the GC at all:

 http://3d.benjamin-thaut.de/?p=20

But reading your blog post, it seems that the main problem was not GC in the general sense, but the fact that for various functionality druntime makes unnecessary allocations. Deal with those, and with-GC D ought to speed up a lot. Or have I misunderstood what you wrote?
Feb 18 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 18 February 2013 at 12:56:33 UTC, Benjamin Thaut wrote:
 Am 18.02.2013 13:48, schrieb dennis luehring:
 Am 18.02.2013 11:35, schrieb Benjamin Thaut:
 I wen't down this path already and I ended up not using the 
 GC at all:
 http://3d.benjamin-thaut.de/?p=20

are your speed fixes - for example the TypeInfo string creation etc. part of current druntime?

Some of the problems have already been fixed since I wrote the article, but not all of them. About your particular question: I'm currently in the progress of getting it ready to be merged (d-style and other nitpicking stuff and some problems in phobos) https://github.com/D-Programming-Language/druntime/pull/370

Have you already done the nitpicking corrections and not pushed them to github or would you be interested in a pull request fixing them.
Feb 18 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 18 February 2013 at 12:54:24 UTC, Benjamin Thaut wrote:
 The main problem is that programming with a GC encourages 
 programming with memory leaks. As the gc will take care of any 
 leaked memory and you don't get any feedback about how much 
 memory you actually allocate.

You can apply the same reasoning to any language feature. Bound checking encourage lazy buffer overflow checking. OOP and functional encourage indirect branching. And I can go on and on. Everything that help a programmer is generally good, as long as getting performances back is allowed with extra work (what GC.free allows you to do). In other terms, if you free what you allocate you get back to manual memory management (well, expect some runtime weirdness).
 Also even if you do manual pooling and use a GC you still pay a 
 big performance impact because the GC will scan the pooled 
 memory without actually freeing anything. But scanning takes 
 time too. And those interrupts by the GC will be long enough to 
 interrupt regular gameplay.
 D would at least need a incremental Mark & Sweep to be usable 
 in games. But in my opinion a GC is not needed at all when 
 developing games, it makes a lot of sense for other fields 
 though.

You'll find that in term of memory management, no magic solution exists. Sometime GC is faster, sometime relying on manual memory management is the best. Most of a the time an hybrid approach between several techniques best results.
Feb 18 2013
prev sibling next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Monday, 18 February 2013 at 10:35:59 UTC, Benjamin Thaut wrote:
 I wen't down this path already and I ended up not using the GC 
 at all:

 http://3d.benjamin-thaut.de/?p=20

http://dlang.org/garbage.html has a list of features that rely on GC and I would say everything in this list is something you cannot (simply) do without dynamic allocation. And as far as I'm concerned, you don't want to use even dynamic allocation in a game due to real-time constraints, since any dynamic allocation is non-deterministic. I don't know any "serious" project that doesn't use pre-allocation and stuff. Do I understand it correctly, that you pointed out the parts in druntime/phobos that "overrely" on GC (could be done without it, but done otherwise)? Cause if not - avoiding everything from that list should make GC present almost unnoticeable. And that's what you want to do anyways, whether GC is present or not, if you're really targeting real-time.
Feb 18 2013
prev sibling next sibling parent "Nicholas Smith" <nmsmith65 gmail.com> writes:
It sounds like it's too easy to leak memory with the GC off at 
the moment. I'd love a  nogc attribute as well, if it can be done.
Feb 18 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Monday, 18 February 2013 at 22:29:39 UTC, Nicholas Smith wrote:
 It sounds like it's too easy to leak memory with the GC off at 
 the moment. I'd love a  nogc attribute as well, if it can be 
 done.

I'd love to have that too. The other area where the GC can get in the way is with systems level programming. Rob
Feb 18 2013
prev sibling next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Monday, 18 February 2013 at 17:58:56 UTC, Benjamin Thaut wrote:
 Yes correct. But if you would do them otherwise you wouldn't 
 need a GC in the first place. The whole point of the GC is that 
 you can be more productive by not caring about this stuff.

Well, that's kind of strange. I guess std library is not the place where you want to care about productivity over performance. Is there anything preventing fixing those? Did you brought that up to the developers? Or may be you know their attitude?
 Correct. Still I rather have a system that gives me errors when 
 I make hidden runtime allocations then having the GC clean them 
 up for me. Coding by convetion never works out well, especially 
 in lager teams.

Then I guess you would rather use C++ than D. =) It's more of "idiomatic" subject than anything else. One of the ways C++ and D differs is the answer to the question "what should happen if you do something *fancy*?". The C++ answer is "the program should crash (go to the undefined behavior area)". And the D answer is "the program should sacrifice performance/memory, but remain in a well-defined state and *do the right thing*".
Feb 18 2013
prev sibling next sibling parent "Dicebot" <m.strashun gmail.com> writes:
On Tuesday, 19 February 2013 at 07:19:06 UTC, Sergei Nosov wrote:
 Then I guess you would rather use C++ than D. =) It's more of 
 "idiomatic" subject than anything else. One of the ways C++ and 
 D differs is the answer to the question "what should happen if 
 you do something *fancy*?".

 The C++ answer is "the program should crash (go to the 
 undefined behavior area)". And the D answer is "the program 
 should sacrifice performance/memory, but remain in a 
 well-defined state and *do the right thing*".

This is unreasonable. D targets itself as a system programming language, among the others usage cases, and thus request to have a compiler-enforced memory usage guard is perfectly valid. What shall it do if something "fancy" is attempted in nogc? Issue a compile-time error, profit!
Feb 18 2013
prev sibling next sibling parent "Don" <don nospam.com> writes:
On Monday, 18 February 2013 at 08:33:41 UTC, Nicholas Smith wrote:
 I'm interested in experimenting with game development in D, but 
 the only thing putting me off is D's heavy GC reliance, which 
 at the moment is a stop-the-world GC.

 One of the biggest killers in game development is unreliable 
 performance and before I tread down the D path I'm interested 
 in knowing just what it is possible to do with the GC in D.

 I'm not so knowledgable in the theory behind GCs but I know 
 that in natively compiled languages your options are much more 
 limited. I found CDGC as an apparently abandoned attempt at a 
 concurrent GC (which also uses fork(), but the way Windows is 
 going I'm caring less and less about them anyway).

 So, how good can D's GC get?

CDGC is not abandoned. We've been using it in production code for a very long time, in an extremely demanding environment. Luca is presenting a talk about it at the D conference.
Feb 19 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Monday, 18 February 2013 at 17:49:28 UTC, JoeCoder wrote:
 On 2/18/2013 5:35 AM, Benjamin Thaut wrote:
 I wen't down this path already and I ended up not using the GC 
 at all:

 http://3d.benjamin-thaut.de/?p=20

I very much enjoyed this article. Hopefully your changes can be applied upstream. A couple of my own ideas, in hopes that those with more knowledge can comment: 1. A nogc attribute. This would work similarly to pure/safe/nothrow and would check at compile time that annotated functions or any they call allocate any memory enforced by the GC. Then phobos would no longer be a "landmine" for those with realtime requirements. 2. GC.collect(timeout). This would run a collection only until timeout is reached. It could be called with timeout=remaining frame time, and would allow expensive collections to span multiple frames.

Maybe a DIP should be written up to get this idea on the radar. Some means to safely disable the GC without fear of using features that perform hidden allocations is a real necessity. Even with a better GC, there will still be a requirement to disable it for some applications. --rt
Feb 19 2013
prev sibling next sibling parent "Sergei Nosov" <sergei.nosov gmail.com> writes:
On Tuesday, 19 February 2013 at 07:36:43 UTC, Dicebot wrote:
 This is unreasonable. D targets itself as a system programming 
 language, among the others usage cases, and thus request to 
 have a compiler-enforced memory usage guard is perfectly valid. 
 What shall it do if something "fancy" is attempted in  nogc? 
 Issue a compile-time error, profit!

I have nothing against nogc. It seems to be a nice idea. I would like to see a way to "talk to GC" in D. What I'm saying is things seem not to be that bad right now.
Feb 19 2013
prev sibling next sibling parent "Nicholas Smith" <nmsmith65 gmail.com> writes:
On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:
 CDGC is not abandoned. We've been using it in production code 
 for a very long time, in an extremely demanding environment. 
 Luca is presenting a talk about it at the D conference.

Is that so? What state is it in? It appears not to have been spoken of or worked on for quite a while now.
Feb 19 2013
prev sibling next sibling parent "John Colvin" <john.loughran.colvin gmail.com> writes:
On Monday, 18 February 2013 at 18:00:58 UTC, Benjamin Thaut wrote:
 Am 18.02.2013 18:49, schrieb JoeCoder:
 1.  A  nogc attribute.  This would work similarly to 
 pure/safe/nothrow
 and would check at compile time that annotated functions or 
 any they
 call allocate any memory enforced by the GC.  Then phobos 
 would no
 longer be a "landmine" for those with realtime requirements.

I really would love to have that too. The problem with this still would be exceptions because D throws by reference and not by value like C++. To make this work there would be the need to add a special Exception allocator and make the compiler emit delete calls in case the exception is caught and not rethrown or something similar. Kind Regards Benjamin Thaut

perhaps a nogc attribute that forbade everything *except* exceptions to use the GC would be still useful. After all, exceptions probably aren't going to be used in the normal execution path of high performance code.
Feb 19 2013
prev sibling next sibling parent "simendsjo" <simendsjo gmail.com> writes:
On Tuesday, 19 February 2013 at 10:41:38 UTC, Nicholas Smith 
wrote:
 On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:
 CDGC is not abandoned. We've been using it in production code 
 for a very long time, in an extremely demanding environment. 
 Luca is presenting a talk about it at the D conference.

Is that so? What state is it in? It appears not to have been spoken of or worked on for quite a while now.

It's quite strange. Seems it was included in an experimental branch back in 2010: http://www.dsource.org/projects/druntime/changeset/418
Feb 19 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
On Tuesday, 19 February 2013 at 08:11:10 UTC, Don wrote:
 CDGC is not abandoned. We've been using it in production code 
 for a very long time, in an extremely demanding environment. 
 Luca is presenting a talk about it at the D conference.

I wish you Sociomantic guys could be a bit more open about your use of D. It would be great for advertising and having more feedback from real-world production environments would be good for development. But I guess company policy prevents that? David
Feb 19 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
John Colvin:

 perhaps a  nogc attribute that forbade everything *except* 
 exceptions to use the GC would be still useful. After all, 
 exceptions probably aren't going to be used in the normal 
 execution path of high performance code.

There is some discussion here: http://d.puremagic.com/issues/show_bug.cgi?id=5219 Bye, bearophile
Feb 19 2013
prev sibling next sibling parent "Paulo Pinto" <pjmlp progtools.org> writes:
On Monday, 18 February 2013 at 08:33:41 UTC, Nicholas Smith wrote:
 ...

 I'm not so knowledgable in the theory behind GCs but I know 
 that in natively compiled languages your options are much more 
 limited.

 ...

It is always a question of what semantics a given language has, not how it is implemented. -- Paulo
Feb 19 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Monday, 18 February 2013 at 17:58:56 UTC, Benjamin Thaut wrote:
 Yes correct. But if you would do them otherwise you wouldn't 
 need a GC in the first place. The whole point of the GC is that 
 you can be more productive by not caring about this stuff.

That a very limited view of things. GC avoid many bookeping that you would have done with manual memory management, and depending on the code, granted you can tolerate some floating garbage, it can even be faster. Coupled with immutability, GC allow to get rid of ownership. It allow to avoid many copies and allocation you'd have done with other memory management systems. GC is surely not the magic tool that solve all problems, but it does way more that what you claim. It does open new doors.
Feb 19 2013
prev sibling next sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
 nogc sounds nice, but how could someone use classes(OOP) with 
this?
Feb 19 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Tuesday, 19 February 2013 at 18:45:00 UTC, Benjamin Thaut 
wrote:
 Am 19.02.2013 17:45, schrieb Minas Mina:
  nogc sounds nice, but how could someone use classes(OOP) with 
 this?

The same way you do in c++. Manual memory management.

Yeah, it would basically reduce memory management of D down to the level of C++, but it would still be much better than C++ and we can target localized sections of code to be nogc only where needed, so we can get the best out of both worlds. For nogc sections of code, it would be very useful if Phobos had smart pointers, similar to what have in C++11. --rt
Feb 19 2013
prev sibling next sibling parent "Nicholas Smith" <nmsmith65 gmail.com> writes:
On Monday, 18 February 2013 at 14:47:19 UTC, Benjamin Thaut wrote:
 Agreed. But as long as D does not have a Garbage Collector that 
 is as powerfull as the GC of the .NET 4 runtime you will be 
 better of (performance wise) not using a GC at all when 
 programming performance critical parts of game engines.

.NET's GC is really nice for games, as far as GCs go. Something like that would make a memory-managed D acceptable. I'm happy for a nogc D though, and in many ways it's a better option (and it's easier to make happen). This is what I need to consider D viable for me. Notify me when this is integrated into D! I think a lack of support for purely manual memory management in D is what causes a lot of C and C++ programmers to turn their nose up at it. It sure is a beautiful language and I'm excited to see it grow. Pure MMM could widen its appeal.
Feb 22 2013
prev sibling next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
JoeCoder:

 Is it possible/permissible to vote for an issue more than once?

I don't think so. Bye, bearophile
Feb 22 2013
prev sibling parent "Minas Mina" <minas_mina1990 hotmail.co.uk> writes:
On Tuesday, 19 February 2013 at 18:45:00 UTC, Benjamin Thaut 
wrote:
 Am 19.02.2013 17:45, schrieb Minas Mina:
  nogc sounds nice, but how could someone use classes(OOP) with 
 this?

The same way you do in c++. Manual memory management.

But I guess you would like to have OOP as well. Would that be possible with nogc?
Feb 23 2013