www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Garbage Collector?

reply Ben <ben rhysoft.com> writes:
A few days ago i was reading this topic:

https://news.ycombinator.com/item?id=14165198

And the whole GC keeps coming up as a negative ( compared to Rust 
).

 From my understanding there has been a proposal DIP1000 to 
address this issue. Is there any update on this topic?

Is it possible to run D without the GC AND the standard library?
Apr 27
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Thursday, 27 April 2017 at 15:50:56 UTC, Ben wrote:
 A few days ago i was reading this topic:

 https://news.ycombinator.com/item?id=14165198

 And the whole GC keeps coming up as a negative ( compared to 
 Rust ).
That's subjective, at best. I see most of Rust's ownership mechanics in a negative light (love the lisp-inspired syntax, though), as they incur a severe productivity decrease while providing little safety benefit for /me/ over what I already have in D. But, as always, YMMV.
 From my understanding there has been a proposal DIP1000 to 
 address this issue.
You'll have to be more specific about what issue you're referring to. People not liking garbage collection? In any case, AFAIU DIP1000 was about more mechanically verifiable memory safety features when not using the GC.
 Is it possible to run D without the GC AND the standard library?
It is possible to run a D program without the GC only if you don't allocate using the GC. If you want to see D code that does allocate using the GC, the compiler flag `-vgc` is your friend (compile Phobos with `-vgc` for kicks). Currently, not all of Phobos is free of GC allocations, most notably exceptions (refer to [1] and similar topics) [1] http://forum.dlang.org/thread/occ9kk$24va$1 digitalmars.com
Apr 27
parent reply Ben <ben rhysoft.com> writes:
On Thursday, 27 April 2017 at 16:35:57 UTC, Moritz Maxeiner wrote:
 You'll have to be more specific about what issue you're 
 referring to. People not liking garbage collection? In any 
 case, AFAIU DIP1000 was about more mechanically verifiable 
 memory safety features when not using the GC.

 Is it possible to run D without the GC AND the standard 
 library?
It is possible to run a D program without the GC only if you don't allocate using the GC. If you want to see D code that does allocate using the GC, the compiler flag `-vgc` is your friend (compile Phobos with `-vgc` for kicks). Currently, not all of Phobos is free of GC allocations, most notably exceptions (refer to [1] and similar topics) [1] http://forum.dlang.org/thread/occ9kk$24va$1 digitalmars.com
Frankly seeing in this example that the GC was in theory able to kick in 6 times in a simple 100 item loop, that is not efficient. I if did my own memory management, the variable cleanup will have been done in one go, right after the loop. Simply more efficient. Been thinking about this topic. Dlang has a destructor, does that means if you allocate on the GC and then do your own destructor, it technically counts as manual memory management? That is assuming the GC removes the memory reference when you call it. I remember seeing in some other languages ( C# possibly? ) that referring a variable to be freed only meant the GC freed the memory when it felt like it, not the exact spot when you told it. I personally think that people simple have a bad taste with GC because they kick in too much outside there control. For 90% the default behavior is good but its those 10% that leaves a bad taste with people ( GC on critical moments and hurting performance in return ).
Apr 27
next sibling parent reply ag0aep6g <anonymous example.com> writes:
On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
 Frankly seeing in this example that the GC was in theory able 
 to kick in 6 times in a simple 100 item loop, that is not 
 efficient. I if did my own memory management, the variable 
 cleanup will have been done in one go, right after the loop. 
 Simply more efficient.
You can easily disable automatic collections and trigger one manually: ---- import core.memory: GC; GC.disable(); /* disable automatic collections */ /* ... do your loop ... */ GC.collect(); /* manually trigger collection */ GC.enable(); /* enable automatic collections */ ----
 Been thinking about this topic. Dlang has a destructor, does 
 that means if you allocate on the GC and then do your own 
 destructor, it technically counts as manual memory management?
I'm not sure what role the destructor supposedly plays here. A destructor is called automatically when the object is freed, or you can call it manually with `object.destroy` [1]. Freeing happens when the object is collected, or you can use `core.memory.GC.free` [2] to free without collecting. Collecting happens automatically, or you can trigger it with `core.memory.GC.collect` [3] as shown. You can use a destructor to manage memory owned by the object. But the destructor being there doesn't affect how the object itself is managed.
 That is assuming the GC removes the memory reference when you 
 call it. I remember seeing in some other languages ( C# 
 possibly? ) that referring a variable to be freed only meant 
 the GC freed the memory when it felt like it, not the exact 
 spot when you told it.
Destroying does not imply freeing. It's the other way around. If you want to free, call `GC.free`. That does count as manual memory management.
 I personally think that people simple have a bad taste with GC 
 because they kick in too much outside there control. For 90% 
 the default behavior is good but its those 10% that leaves a 
 bad taste with people ( GC on critical moments and hurting 
 performance in return ).
You can: 1) Call `core.memory.GC.disable` [4] if you don't want the GC to collect for a while. You should make sure that you don't run out of memory during that time, of course. Use `core.memory.GC.enable` [5] to enable collections again. 2) Use the ` nogc` [6] attribute to forbid GC allocations in a function. GC collections are only triggered by allocations (or manually). So the GC won't kick in during execution of nogc code. [1] https://dlang.org/phobos/object.html#.destroy [2] https://dlang.org/phobos/core_memory.html#.GC.free [3] https://dlang.org/phobos/core_memory.html#.GC.collect [4] https://dlang.org/phobos/core_memory.html#.GC.disable [5] https://dlang.org/phobos/core_memory.html#.GC.enable [6] https://dlang.org/spec/attribute.html#nogc
Apr 27
parent Patric Dexheimer <patric.dexheimer gmail.com> writes:
GC it´s not only about some performance issues that some people 
may encounter on D, but it its a marketing problem as well.

"D is a systems programming language with..." GC(!?).

Most people that are interest in D came from c/c++ or other 
backgrounds without GC or hearing their entire life that GC "may 
be bad".

Its not a question of "how bad it is" or if it is bad at all.

People know how to program without GC. So this is just something 
in the way.

Anyway D is awesome.
Apr 27
prev sibling next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
 On Thursday, 27 April 2017 at 16:35:57 UTC, Moritz Maxeiner 
 wrote:
 You'll have to be more specific about what issue you're 
 referring to. People not liking garbage collection? In any 
 case, AFAIU DIP1000 was about more mechanically verifiable 
 memory safety features when not using the GC.

 Is it possible to run D without the GC AND the standard 
 library?
It is possible to run a D program without the GC only if you don't allocate using the GC. If you want to see D code that does allocate using the GC, the compiler flag `-vgc` is your friend (compile Phobos with `-vgc` for kicks). Currently, not all of Phobos is free of GC allocations, most notably exceptions (refer to [1] and similar topics) [1] http://forum.dlang.org/thread/occ9kk$24va$1 digitalmars.com
Frankly seeing in this example that the GC was in theory able to kick in 6 times in a simple 100 item loop, that is not efficient. I if did my own memory management, the variable cleanup will have been done in one go, right after the loop. Simply more efficient.
You replied to the wrong person here, seeing as I did not link to the article you're referring to, but your statement about not being efficient is, honestly, ludicrous, so I'll reply: Expanding the continuous memory region a dynamic array consists of (possibly moving it) once it overflows has absolutely nothing to do with the GC, or even the language, it's how the abstract data type "dynamic array" is defined. D just does this transparently for you by default. If you already know the exact or maximum size, you can allocate *once* (not 6 times) using `new` and `.reserve` respectively *before* entering the loop, like that article explains in depth.
 Been thinking about this topic. Dlang has a destructor, does 
 that means if you allocate on the GC and then do your own 
 destructor, it technically counts as manual memory management?
Um, what? Memory (de)allocation (in C often malloc/free) and object (de)contruction (in C usually functions with some naming conventions like `type_init`/`type_deinit`) are on two entirely different layers! Granted, they are often combined in C to functions with names like `type_new`/`type_free`, but they are conceptually two distinct things. Just to be very clear, here is a primitive diagram of how things work: make object O of type T: <OS> --(allocate N bytes)--> [memory chunk M] --(call constructor T(args) on M)--> [O] dispose of O: [O] --(call destructor ~T() on O)--> [memory chunk M] --(deallocate M)--> <OS> D's garbage collector conceptually changes this to: make object O of type T: <OS> --(GC allocates)--> [GC memory pool] --(allocate N bytes)--> [memory chunk M] --(call constructor T(args) on M)--> [O] dispose of O: [O] --(call destructor ~T() on O)--> [memory chunk M] --(deallocate M)--> [GC memory pool] --(GC deallocates)--> <OS> with the specific restriction that you have *no* control over 'GC deallocates' and only indirect control over 'GC allocates' (by allocating more memory from the GC than is available its the pool). Working on the memory chunk layer is memory management. Working on the object layer is object lifetime management. D offers you both automatic memory management and automatic lifetime management via its GC. What you describe is manual object lifetime management (which is what std.conv.emplace and object.destroy exist for) and has no effect on the automatic memory management the GC performs. You *can* do manual memory management *on top* of the GC's memory pool (using core.memory.GC.{alloc/free) or the newer, generic Alloactor interface via std.experimental.allocator.gc_allocator.GCAllocator.{allocate/deallocate}), but these operations will (generally) not yield any observable difference from the OS's perspective.
 That is assuming the GC removes the memory reference when you 
 call it. I remember seeing in some other languages ( C# 
 possibly? ) that referring a variable to be freed only meant 
 the GC freed the memory when it felt like it, not the exact 
 spot when you told it.
Again, you seem to mix object lifetime management and memory management. You cannot tell the GC to free memory back to the operating system (which is what the free syscall does and what you seem to be describing). You can *only* free memory you allocated *from* the GC *back* to the GC. The GC decides when (and if) any memory is ever being freed back to the OS (which is kinda one major point of having a GC in the first place).
 I personally think that people simple have a bad taste with GC 
 because they kick in too much outside there control.
In my experience most people's aversion to GCs can be aptly described by the German proverb "Was der Bauer nicht kennt, das frisst er nicht" (the meaning of which being that most people generally like living in comfort zones and rarely - if ever - dare to leave them of their own free will; that includes developers, sadly).
 For 90% the default behavior is good but its those 10% that 
 leaves a bad taste with people ( GC on critical moments and 
 hurting performance in return ).
Then don't allocate using the GC in such critical pieces of code? If you want automatic verification, annotate a function with nogc (also works with anonymous functions, lambdas, etc); just be aware that not everything in druntime and phobos that could (and should) be annotated currently is (if you encounter any such functions, open a bug report for it so it can be fixed).
Apr 27
next sibling parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner wrote:
 Working on the memory chunk layer is memory management.
 Working on the object layer is object lifetime management.
 D offers you both automatic memory management and automatic 
 lifetime management via its GC.
D offers sound automatic lifetime management? Since when?
Apr 27
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 28 April 2017 at 04:24:43 UTC, Ola Fosheim Grostad 
wrote:
 On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner 
 wrote:
 Working on the memory chunk layer is memory management.
 Working on the object layer is object lifetime management.
 D offers you both automatic memory management and automatic 
 lifetime management via its GC.
D offers sound automatic lifetime management? Since when?
Why are you implicitly adding adjectives to my sentence that change its meaning?
Apr 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 28 April 2017 at 08:25:01 UTC, Moritz Maxeiner wrote:
 On Friday, 28 April 2017 at 04:24:43 UTC, Ola Fosheim Grostad 
 wrote:
 On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner 
 wrote:
 Working on the memory chunk layer is memory management.
 Working on the object layer is object lifetime management.
 D offers you both automatic memory management and automatic 
 lifetime management via its GC.
D offers sound automatic lifetime management? Since when?
Why are you implicitly adding adjectives to my sentence that change its meaning?
If it isn't sound then it isn't worth mentioning...
Apr 28
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 28 April 2017 at 08:26:28 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 08:25:01 UTC, Moritz Maxeiner wrote:
 On Friday, 28 April 2017 at 04:24:43 UTC, Ola Fosheim Grostad 
 wrote:
 On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner 
 wrote:
 Working on the memory chunk layer is memory management.
 Working on the object layer is object lifetime management.
 D offers you both automatic memory management and automatic 
 lifetime management via its GC.
D offers sound automatic lifetime management? Since when?
Why are you implicitly adding adjectives to my sentence that change its meaning?
If it isn't sound then it isn't worth mentioning...
So you claim...
Apr 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 28 April 2017 at 09:02:19 UTC, Moritz Maxeiner wrote:
 On Friday, 28 April 2017 at 08:26:28 UTC, Ola Fosheim Grøstad 
 wrote:
 If it isn't sound then it isn't worth mentioning...
So you claim...
Actually, unsound lifetime management is worse than nothing as far as correctness goes... so I guess it is worth mentioning as a warning rather than a recommendation. If D had ownership pointers then it would've been possible to sort this out, but D is perpetually locked to the current pointer/GC model for reasons that aren't particularly convincing, i.e. beliefs.
Apr 28
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 28 April 2017 at 09:12:03 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 09:02:19 UTC, Moritz Maxeiner wrote:
 On Friday, 28 April 2017 at 08:26:28 UTC, Ola Fosheim Grøstad 
 wrote:
 If it isn't sound then it isn't worth mentioning...
So you claim...
Actually, unsound lifetime management is worse than nothing as far as correctness goes... so I guess it is worth mentioning as a warning rather than a recommendation.
Actually, applying "sound" or "unsound" to D's GC lifetime management in general is worse than realizing that whether using it for a specific use case is sound or unsound is entirely dependent on that use case... so I guess it is worth mentioning as a tool a developer should read up on. Also, you seem to imply that I made a recommendation to use the GC's lifetime management. I did not.
 If D had ownership pointers then it would've been possible to 
 sort this out, but D is perpetually locked to the current 
 pointer/GC model for reasons that aren't particularly 
 convincing, i.e. beliefs.
I'm sorry, but that's just plain wrong. D does not have ownership pointers because nobody that wants them has stepped up and 1) Done the work of drafting an informal proposal that *actually deals with _all_ of the issues involved* 2) Developed that informal proposal into a DIP 3) Wrote the implementation and sent a PR Every time it comes up there are ideas, or sometimes even reasonably well formed informal proposals, but none of the proponents ever actually follows up and improves such proposals to the point where all the issues are dealt with. Claiming that D doesn't have ownership mechanics because of beliefs when none of the (vocal) proponents are willing to actually get down to it and *do the work* is, frankly, asinine; do you generally expect people to do things for you they aren't interested in without recompense?
Apr 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 28 April 2017 at 09:40:07 UTC, Moritz Maxeiner wrote:
 I'm sorry, but that's just plain wrong. D does not have 
 ownership pointers because nobody that wants them has stepped 
 up and
 1) Done the work of drafting an informal proposal that 
 *actually deals with _all_ of the issues involved*
Wrong. This has been discussed and hashed out to death over and over again. The solutions are on the table. Walter's position has always been that having more than a single pointer type is a disaster. That makes further work on it pointless. (Although, arguably, D kinda has several pointer types already).
Apr 28
parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 09:40:07 UTC, Moritz Maxeiner wrote:
 I'm sorry, but that's just plain wrong. D does not have 
 ownership pointers because nobody that wants them has stepped 
 up and
 1) Done the work of drafting an informal proposal that 
 *actually deals with _all_ of the issues involved*
Wrong. This has been discussed and hashed out to death over and over again. The solutions are on the table.
No. Every single thread I read in the last couple of years ended with Walter pointing out issues that need to be "hashed out" and then nobody doing it.
 Walter's position has always been that having more than a 
 single pointer type is a disaster.
None of the threads I've read in the last couple of years regarding that support that claim.
 That makes further work on it pointless.
What you consider worth working on is your business, of course :)
Apr 28
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 28 April 2017 at 15:43:22 UTC, Moritz Maxeiner wrote:
 On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad 
 wrote:
 Walter's position has always been that having more than a 
 single pointer type is a disaster.
None of the threads I've read in the last couple of years regarding that support that claim.
He has restated this position many many times... Random snippets: «Microsoft's Managed C++ had two pointer types, and it went over like a lead zeppelin. » http://forum.dlang.org/post/mclqt1$1e5n$1 digitalmars.com «Back in the old DOS days, there were multiple pointer types (near and far). Programmers put up with that because it was the only way, but they HATED HATED HATED it.» http://forum.dlang.org/post/mcnv9u$e8p$1 digitalmars.com You can easily find more... No point in trying to get that into the core language (but it is necessary to get proper destruction of GC managed objects in a reasonable way).
Apr 28
next sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 15:43:22 UTC, Moritz Maxeiner wrote:
 On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad 
 wrote:
 Walter's position has always been that having more than a 
 single pointer type is a disaster.
None of the threads I've read in the last couple of years regarding that support that claim.
He has restated this position many many times... Random snippets: «Microsoft's Managed C++ had two pointer types, and it went over like a lead zeppelin. » http://forum.dlang.org/post/mclqt1$1e5n$1 digitalmars.com «Back in the old DOS days, there were multiple pointer types (near and far). Programmers put up with that because it was the only way, but they HATED HATED HATED it.» http://forum.dlang.org/post/mcnv9u$e8p$1 digitalmars.com
I had not read these, thank you :) Both of these, however, show only that he doesn't seem to personally like multiple pointer types (and consequently doesn't seem to have any interest in working on them himself); that's not the same as him claiming that it "is a disaster" (in general, which is what you were implying).
 You can easily find more... No point in trying to get that into 
 the core language (but it is necessary to get proper 
 destruction of GC managed objects in a reasonable way).
What you consider not pointless is your business, again, but if you don't try to get it in the core language, you have no foundation to complain that's it's not in there.
Apr 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 28 April 2017 at 20:13:58 UTC, Moritz Maxeiner wrote:
 Both of these, however, show only that he doesn't seem to 
 personally like multiple pointer types (and consequently 
 doesn't seem to have any interest in working on them himself); 
 that's not the same as him claiming that it "is a disaster" (in 
 general, which is what you were implying).
There are other threads. This is a recurring topic...
 What you consider not pointless is your business, again, but if 
 you don't try to get it in the core language, you have no 
 foundation to complain that's it's not in there.
There are no example I know of where something has gone into the D language that is going against the aesthetics Walter value... Which isn't surprising. There are also few examples of new features going in at the language level based on external DIPs. Do you have any good examples? (Not standard lib, but language features).
Apr 28
next sibling parent Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 28 April 2017 at 20:21:34 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 20:13:58 UTC, Moritz Maxeiner wrote:
 Both of these, however, show only that he doesn't seem to 
 personally like multiple pointer types (and consequently 
 doesn't seem to have any interest in working on them himself); 
 that's not the same as him claiming that it "is a disaster" 
 (in general, which is what you were implying).
There are other threads. This is a recurring topic...
I am aware...
 What you consider not pointless is your business, again, but 
 if you don't try to get it in the core language, you have no 
 foundation to complain that's it's not in there.
There are no example I know of where something has gone into the D language that is going against the aesthetics Walter value... Which isn't surprising. There are also few examples of new features going in at the language level based on external DIPs. Do you have any good examples? (Not standard lib, but language features).
I myself know of no examples where people have actually done the work up to and including the point where there were no technical issues left and were then rejected.
Apr 28
prev sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 28 April 2017 at 20:21:34 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 20:13:58 UTC, Moritz Maxeiner wrote:
 Both of these, however, show only that he doesn't seem to 
 personally like multiple pointer types (and consequently 
 doesn't seem to have any interest in working on them himself); 
 that's not the same as him claiming that it "is a disaster" 
 (in general, which is what you were implying).
There are other threads. This is a recurring topic...
To be fair, C++ effectively has multiple pointer types too with raw pointers, unique_ptr, shared_ptr, and weak_ptr. However, each of the extra ones has a unique purpose and are opt-in. As a result, people happily use them when it makes their lives easier. By contrast, C++/CLI (I'm more familiar with that than managed C++) has pointer to managed heap and pointer to unmanaged heap. The concepts overlap more.
Apr 28
parent Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Friday, 28 April 2017 at 21:21:13 UTC, jmh530 wrote:
 To be fair, C++ effectively has multiple pointer types too with 
 raw pointers, unique_ptr, shared_ptr, and weak_ptr. However, 
 each of the extra ones has a unique purpose and are opt-in. As 
 a result, people happily use them when it makes their lives 
 easier.
Yes, they are not language types though, so no special effect on the compiler or runtime. The language types are pointers, &references and &&references.
 By contrast, C++/CLI (I'm more familiar with that than managed 
 C++) has pointer to managed heap and pointer to unmanaged heap. 
 The concepts overlap more.
Yes, and I assume those are language types so that the compiler and runtime can take advantage of it?
Apr 28
prev sibling parent reply Atila Neves <atila.neves gmail.com> writes:
On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad 
 wrote:
 «Back in the old DOS days, there were multiple pointer types 
 (near and far). Programmers put up with that because it was the 
 only way, but they HATED HATED HATED it.»
It's true, we did. It was awful. Atila
Apr 28
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 28, 2017 at 09:50:49PM +0000, Atila Neves via Digitalmars-d wrote:
 On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grstad wrote:
 On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grstad wrote:
 Back in the old DOS days, there were multiple pointer types (near
 and far). Programmers put up with that because it was the only way,
 but they HATED HATED HATED it.
It's true, we did. It was awful.
[...] I remember working with that. It was a royal PITA. T -- Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at it. -- Pete Bleackley
Apr 28
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 28.04.2017 23:52, H. S. Teoh via Digitalmars-d wrote:
 On Fri, Apr 28, 2017 at 09:50:49PM +0000, Atila Neves via Digitalmars-d wrote:
 On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grstad wrote:
 On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grstad wrote:
 Back in the old DOS days, there were multiple pointer types (near
 and far). Programmers put up with that because it was the only way,
 but they HATED HATED HATED it.
It's true, we did. It was awful.
[...] I remember working with that. It was a royal PITA. T
I don't doubt that, but the implicit generalization is "multiple pointer types are necessarily always a royal PITA". Not true. scope has worse usability than a scoped pointer type.
Apr 29
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 29 April 2017 at 07:26:45 UTC, Timon Gehr wrote:
 I don't doubt that, but the implicit generalization is 
 "multiple pointer types are necessarily always a royal PITA". 
 Not true. scope has worse usability than a scoped pointer type.
Yes. In this context it is was more about the GC lifetime management which requires: 1. The ability to tell the GC about explicit parent-child relationships so that the GC destruction order becomes deterministic. 2. Precise collection.
Apr 29
prev sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 29 April 2017 at 07:26:45 UTC, Timon Gehr wrote:
 On 28.04.2017 23:52, H. S. Teoh via Digitalmars-d wrote:
 On Fri, Apr 28, 2017 at 09:50:49PM +0000, Atila Neves via 
 Digitalmars-d wrote:
 On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim Grøstad 
 wrote:
 On Friday, 28 April 2017 at 19:41:15 UTC, Ola Fosheim 
 Grøstad wrote:
 «Back in the old DOS days, there were multiple pointer types 
 (near
 and far). Programmers put up with that because it was the 
 only way,
 but they HATED HATED HATED it.»
It's true, we did. It was awful.
[...] I remember working with that. It was a royal PITA. T
I don't doubt that, but the implicit generalization is "multiple pointer types are necessarily always a royal PITA".
The "implicit generalization" is your interpretation, though.
Apr 29
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 29 April 2017 at 08:45:26 UTC, Moritz Maxeiner wrote:
 On Saturday, 29 April 2017 at 07:26:45 UTC, Timon Gehr wrote:
 I don't doubt that, but the implicit generalization is 
 "multiple pointer types are necessarily always a royal PITA".
The "implicit generalization" is your interpretation, though.
No, it was brought up in a thread as an argument against having multiple pointer types. The thread was not about near/far pointers or segmented memory models.
Apr 29
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 29 April 2017 at 09:24:35 UTC, Ola Fosheim Grøstad 
wrote:
 On Saturday, 29 April 2017 at 08:45:26 UTC, Moritz Maxeiner 
 wrote:
 On Saturday, 29 April 2017 at 07:26:45 UTC, Timon Gehr wrote:
 I don't doubt that, but the implicit generalization is 
 "multiple pointer types are necessarily always a royal PITA".
The "implicit generalization" is your interpretation, though.
No, it was brought up in a thread as an argument against having multiple pointer types.
It was brought up in that thread as an example of multiple pointer types having (I assume unintended) negative consequences. That's not the same as implying that *all* occurrences of multiple pointer types *will* have such negative consequences; at most, it implies that you have to be very careful when designing them, so as to avoid such consequences (and this latter part is *my* interpretation).
 The thread was not about near/far pointers or segmented memory 
 models.
I am aware; it was originally about the viability of automatic reference counting in D, and its potential benefits/drawbacks compared to garbage collection.
Apr 29
prev sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 28.04.2017 17:43, Moritz Maxeiner wrote:
 On Friday, 28 April 2017 at 14:59:46 UTC, Ola Fosheim Grøstad wrote:
 On Friday, 28 April 2017 at 09:40:07 UTC, Moritz Maxeiner wrote:
 I'm sorry, but that's just plain wrong. D does not have ownership
 pointers because nobody that wants them has stepped up and
 1) Done the work of drafting an informal proposal that *actually
 deals with _all_ of the issues involved*
Wrong. This has been discussed and hashed out to death over and over again. The solutions are on the table.
No. Every single thread I read in the last couple of years ended with Walter pointing out issues that need to be "hashed out" and then nobody doing it.
This is not the full story though. Among Walter's constraints for an acceptable solution always were: 1. cannot add new syntax 2. cannot add polymorphism to the type system (because it is "hard to understand") 1. is inconvenient and I think what we get with 'scope' is approximately the best one can do given 2.
Apr 29
parent Moritz Maxeiner <moritz ucworks.org> writes:
On Saturday, 29 April 2017 at 07:15:36 UTC, Timon Gehr wrote:
 On 28.04.2017 17:43, Moritz Maxeiner wrote:
 [...]

 No. Every single thread I read in the last couple of years 
 ended with
 Walter pointing out issues that need to be "hashed out" and 
 then nobody
 doing it.
This is not the full story though. Among Walter's constraints for an acceptable solution always were: 1. cannot add new syntax
I've dug through what records I know of surrounding these discussions [1][2][3][4][5] and could not come up with a statement of his that supports this hard-line claim. You may be right, considering that adding new syntax is a non-trivial change, but I'd need the citation.
 2. cannot add polymorphism to the type system (because it is 
 "hard to understand")
Same as above. [1] http://lists.puremagic.com/pipermail/dlang-study/ [2] https://forum.dlang.org/thread/kpgilxyyrrluxpepepcg forum.dlang.org [3] https://forum.dlang.org/post/kluaojijixhwigoujeip forum.dlang.org [4] http://forum.dlang.org/thread/oboaa2$17oa$1 digitalmars.com [5] http://forum.dlang.org/thread/nu00a6$t5i$1 digitalmars.com
Apr 29
prev sibling parent reply Ben <ben rhysoft.com> writes:
On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner wrote:
 You replied to the wrong person here, seeing as I did not link 
 to the article you're referring to,
Sorry...
 so I'll reply:
 Expanding the continuous memory region a dynamic array consists 
 of (possibly moving it) once it overflows has absolutely 
 nothing to do with the GC, or even the language, it's how the 
 abstract data type "dynamic array" is defined. D just does this 
 transparently for you by default. If you already know the exact 
 or maximum size, you can allocate *once* (not 6 times) using 
 `new` and `.reserve` respectively *before* entering the loop, 
 like that article explains in depth.
You seem to be missing the fact that i pointed this out. The fact that the GC might have done up to 6 collection rounds in that loop is "ludicrous".
 Um, what? Memory (de)allocation (in C often malloc/free) and 
 object (de)contruction (in C usually functions with some naming 
 conventions like `type_init`/`type_deinit`) are on two entirely 
 different layers! Granted, they are often combined in C to 
 functions with names like `type_new`/`type_free`, but they are 
 conceptually two distinct things. Just to be very clear, here 
 is a primitive diagram of how things work:
 make object O of type T:
 <OS> --(allocate N bytes)--> [memory chunk M] --(call 
 constructor T(args) on M)--> [O]
 dispose of O:
 [O] --(call destructor ~T() on O)--> [memory chunk M] 
 --(deallocate M)--> <OS>

 D's garbage collector conceptually changes this to:
 make object O of type T:
 <OS> --(GC allocates)--> [GC memory pool] --(allocate N 
 bytes)--> [memory chunk M] --(call constructor T(args) on M)--> 
 [O]
 dispose of O:
 [O] --(call destructor ~T() on O)--> [memory chunk M] 
 --(deallocate M)--> [GC memory pool] --(GC deallocates)--> <OS>
 with the specific restriction that you have *no* control over 
 'GC deallocates' and only indirect control over 'GC allocates' 
 (by allocating more memory from the GC than is available its 
 the pool).

 Working on the memory chunk layer is memory management.
 Working on the object layer is object lifetime management.
 D offers you both automatic memory management and automatic 
 lifetime management via its GC.
 What you describe is manual object lifetime management (which 
 is what std.conv.emplace and object.destroy exist for) and has 
 no effect on the automatic memory management the GC performs.
 You *can* do manual memory management *on top* of the GC's 
 memory pool (using core.memory.GC.{alloc/free) or the newer, 
 generic Alloactor interface via 
 std.experimental.allocator.gc_allocator.GCAllocator.{allocate/deallocate}),
but these operations will (generally) not yield any observable difference from
the OS's perspective.

 That is assuming the GC removes the memory reference when you 
 call it. I remember seeing in some other languages ( C# 
 possibly? ) that referring a variable to be freed only meant 
 the GC freed the memory when it felt like it, not the exact 
 spot when you told it.
Again, you seem to mix object lifetime management and memory management. You cannot tell the GC to free memory back to the operating system (which is what the free syscall does and what you seem to be describing). You can *only* free memory you allocated *from* the GC *back* to the GC. The GC decides when (and if) any memory is ever being freed back to the OS (which is kinda one major point of having a GC in the first place).
I know, i do not express myself very well in English.
 In my experience most people's aversion to GCs can be aptly 
 described by the German proverb "Was der Bauer nicht kennt, das 
 frisst er nicht" (the meaning of which being that most people 
 generally like living in comfort zones and rarely - if ever - 
 dare to leave them of their own free will; that includes 
 developers, sadly).
Unfortunately i do have plenty of experience with GC kicking in on the wrong moments ( or not at the right moments, people forget that one ). I am sure that the amount of people who develop in GC languages is much bigger these days then manual managed languages ( what is more or less a rarity these days among the new languages ). Even Rust still has some background management going on ( like the byte counter ). Maybe its my opinion only but a good language will not put anything in the way of the developer but will point out mistakes. The Rust compiler is not a bad example but it can be taken a step more. Is it so hard for developers when you declare a variable, to later also clean it up??? var x = 1; // Do work x.free; Easy ... Sure, it becomes a little bit more tricky with ownership but that is where the compiler can help and simply state: "Hey, you forgot this variable, it does not seem to be used beyond this point". Just calling the x.free seem to be too much work for developers these days. Up to now i found very few languages that did this correctly. But this is a offtopic discussion.
Apr 28
next sibling parent Mike Parker <aldacron gmail.com> writes:
On Friday, 28 April 2017 at 07:35:00 UTC, Ben wrote:

 so I'll reply:
 Expanding the continuous memory region a dynamic array 
 consists of (possibly moving it) once it overflows has 
 absolutely nothing to do with the GC, or even the language, 
 it's how the abstract data type "dynamic array" is defined. D 
 just does this transparently for you by default. If you 
 already know the exact or maximum size, you can allocate 
 *once* (not 6 times) using `new` and `.reserve` respectively 
 *before* entering the loop, like that article explains in 
 depth.
You seem to be missing the fact that i pointed this out. The fact that the GC might have done up to 6 collection rounds in that loop is "ludicrous".
How is it ludicrous? The fact that you know the GC will only run during an allocation, and only if it needs to, allows you to control when those opportunities to collect arise. That's a much more palatable situation than if it were sitting in the background, constantly checking if it needs to collect, then doing so without any input from you. There, you'd have no control at all. In the context of an actual program, the example would only have made 6 collections if you were putting putting heavy pressure on the GC heap, which is an extremely naive way of programming for anyone concerned about performance. D allows you several options to relieve that pressure and assert some control over when the GC can run. Even in a non-GC language, you wouldn't be allocating like that in a performance-critical loop -- you would preallocate before you entered the loop.
Apr 28
prev sibling parent reply Moritz Maxeiner <moritz ucworks.org> writes:
On Friday, 28 April 2017 at 07:35:00 UTC, Ben wrote:
 On Thursday, 27 April 2017 at 22:43:56 UTC, Moritz Maxeiner 
 wrote:
 D just does this transparently for you by default. If you 
 already know the exact or maximum size, you can allocate 
 *once* (not 6 times) using `new` and `.reserve` respectively 
 *before* entering the loop, like that article explains in 
 depth.
You seem to be missing the fact that i pointed this out. The fact that the GC might have done up to 6 collection rounds in that loop is "ludicrous".
You wrote:
 I if did my own memory management, the variable cleanup will 
 have been done in one go, right after the loop. Simply more 
 efficient.
You wrote about cleaning up *after* the loop, *not* about allocating *before* the loop. They are semantically related (as allocating with the GC *might* kick off a collection cycle), but not the same thing.
 In my experience most people's aversion to GCs can be aptly 
 described by the German proverb "Was der Bauer nicht kennt, 
 das frisst er nicht" (the meaning of which being that most 
 people generally like living in comfort zones and rarely - if 
 ever - dare to leave them of their own free will; that 
 includes developers, sadly).
Unfortunately i do have plenty of experience with GC kicking in on the wrong moments ( or not at the right moments, people forget that one ).
In which language(s)? Because in D it's both easy and simple to avoid that (Use nogc or compile with `-vgc` and inspect).
 Maybe its my opinion only but a good language will not put 
 anything in the way of the developer but will point out 
 mistakes.
Safety properties may be what you're looking for. See safe, that's an area of D a lot of work is currently being done on.
 The Rust compiler is not a bad example but it can be taken a 
 step more. Is it so hard for developers when you declare a 
 variable, to later also clean it up???

 var x = 1;
 // Do work
 x.free;
If you write it like that, yes, because often it's not just one such make/dispose pair per scope, but multiple, possibly overlapping ones and people make mistakes. And the more complex a piece of code gets the harder it becomes to decipher such pairs and/or decide if the "closing" dispose is missing. This is one of the reasons why scope guards are good: var x = 1; scope (exit) x.free // Do work This, as code becomes more complex, allows for much easier reading (and understanding) of lifetimes.
 Easy ... Sure, it becomes a little bit more tricky with 
 ownership but that is where the compiler can help and simply 
 state: "Hey, you forgot this variable, it does not seem to be 
 used beyond this point".
Since the GC is memory safe by definition (sans bugs) you'd only need this for where you aren't using it. And for the rest I'm not sure it can be done sanely: How's the compiler to know, e.g., which functions from a C API (or C++) you call into allocate or deallocate memory? Introduce yet another keyword or property to signal cross-language memory management? If you ignore cross-language calls and only remain within D, I suppose it might be viable to write a semantic pass for it, but from my perspective, the cross-language calls are the *much* bigger threat to memory safety.
 Just calling the x.free seem to be too much work for developers 
 these days.
In my experience reading about such occurences, this usually happens when the lifetime of the object the memory is used for has become unclear.
 Up to now i found very few languages that did this correctly.
I don't share your assessment of what's correct, but yes, we digress.
Apr 28
parent reply "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 28, 2017 at 09:01:03AM +0000, Moritz Maxeiner via Digitalmars-d
wrote:
 On Friday, 28 April 2017 at 07:35:00 UTC, Ben wrote:
[...]
 Is it so hard for developers when you declare a variable, to later
 also clean it up???
 
 var x = 1;
 // Do work
 x.free;
If you write it like that, yes, because often it's not just one such make/dispose pair per scope, but multiple, possibly overlapping ones and people make mistakes. And the more complex a piece of code gets the harder it becomes to decipher such pairs and/or decide if the "closing" dispose is missing. This is one of the reasons why scope guards are good: var x = 1; scope (exit) x.free // Do work This, as code becomes more complex, allows for much easier reading (and understanding) of lifetimes.
[...] Elephant in the room: D lets you call the C library's malloc() and free(). If you absolute insist that you don't want to use the GC, go right ahead and import core.c.stdlib, and malloc and free away. As mentioned above, D's scope guards will even help you avoid mistakes by keeping allocation and free in the same scope together, i.e., instead of writing: auto x = malloc(...); // do stuff // and more stuff // and more stuff // so many pages of stuff you forgot about x free(x); // very likely you'll forget this by now you could save yourself the bug by writing: auto x = malloc(...); scope(exit) free(x); // ... however many pages of stuff you want, you don't have to // remember to write free() afterwards! Yes, D comes with a GC... doesn't mean you have to use it if you don't want to, though! T -- Doubt is a self-fulfilling prophecy.
Apr 28
parent reply bachmeier <no spam.net> writes:
On Friday, 28 April 2017 at 15:23:18 UTC, H. S. Teoh wrote:

 you could save yourself the bug by writing:

 	auto x = malloc(...);
 	scope(exit) free(x);
 	// ... however many pages of stuff you want, you don't have to
 	// remember to write free() afterwards!

 Yes, D comes with a GC... doesn't mean you have to use it if 
 you don't want to, though!
I usually use the GC, so I have limited knowledge in this area. How common is this pattern in D code? Is it better than using reference counted structs? Is there any advantage to using the GC in this scenario? I would like to add this info to the wiki (I don't seen it there).
Apr 28
next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
On Friday, 28 April 2017 at 16:03:18 UTC, bachmeier wrote:
 I usually use the GC, so I have limited knowledge in this area. 
 How common is this pattern in D code? Is it better than using 
 reference counted structs? Is there any advantage to using the 
 GC in this scenario?

 I would like to add this info to the wiki (I don't seen it 
 there).
You can also use automem https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/
Apr 28
parent reply bachmeier <no spam.net> writes:
On Friday, 28 April 2017 at 17:06:51 UTC, jmh530 wrote:
 On Friday, 28 April 2017 at 16:03:18 UTC, bachmeier wrote:
 I usually use the GC, so I have limited knowledge in this 
 area. How common is this pattern in D code? Is it better than 
 using reference counted structs? Is there any advantage to 
 using the GC in this scenario?

 I would like to add this info to the wiki (I don't seen it 
 there).
You can also use automem https://dlang.org/blog/2017/04/28/automem-hands-free-raii-for-d/
I'm hoping to put all information in one place. Then when someone on Reddit or HN or here starts making claims about the GC, I can give them one link that shows all of their options. There's this page: https://wiki.dlang.org/Memory_Management but that isn't comprehensive or as to-the-point as it needs to be.
Apr 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 28 April 2017 at 17:42:18 UTC, bachmeier wrote:
 I'm hoping to put all information in one place. Then when 
 someone on Reddit or HN or here starts making claims about the 
 GC, I can give them one link that shows all of their options.
That's nice. Just get your hopes up for it having an effect. One of the key points of having it in the core distribution (compiler) is for library interoperability. Using multiple solutions ends up in chaos in real world projects...
Apr 28
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Friday, 28 April 2017 at 17:48:47 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 17:42:18 UTC, bachmeier wrote:
 I'm hoping to put all information in one place. Then when 
 someone on Reddit or HN or here starts making claims about the 
 GC, I can give them one link that shows all of their options.
That's nice. Just get your hopes up for it having an effect.
Typo, I meant "don't"... Sloppy of me. Documentation is nice, but: 1. People will complain that it isn't possible. 2. When possible people will complain that it isn't in the standard library. 3. When in "std" people will complain that not enough libraries use it. 4. When libraries use it people will complain that it doesn't work with older libs. 5. When older libs have been rewritten to support it they will complain that it is better in Rust and C++ and not compatible with Rust and C++. Anyway, my main point is that programmers coming from such languages will most certainly complain if it isn't in the standard library because of interoperability between libraries, but that is basically just the bottom of the hill that you have to climb to get to a level where people stop complaining.
Apr 28
parent reply bachmeier <no spam.net> writes:
On Friday, 28 April 2017 at 19:49:35 UTC, Ola Fosheim Grøstad 
wrote:
 On Friday, 28 April 2017 at 17:48:47 UTC, Ola Fosheim Grøstad 
 wrote:
 On Friday, 28 April 2017 at 17:42:18 UTC, bachmeier wrote:
 I'm hoping to put all information in one place. Then when 
 someone on Reddit or HN or here starts making claims about 
 the GC, I can give them one link that shows all of their 
 options.
That's nice. Just get your hopes up for it having an effect.
Typo, I meant "don't"... Sloppy of me. Documentation is nice, but: 1. People will complain that it isn't possible. 2. When possible people will complain that it isn't in the standard library. 3. When in "std" people will complain that not enough libraries use it. 4. When libraries use it people will complain that it doesn't work with older libs. 5. When older libs have been rewritten to support it they will complain that it is better in Rust and C++ and not compatible with Rust and C++. Anyway, my main point is that programmers coming from such languages will most certainly complain if it isn't in the standard library because of interoperability between libraries, but that is basically just the bottom of the hill that you have to climb to get to a level where people stop complaining.
Many invested in Rust and C++ will look for arguments to support staying with their language. I've come to the conclusion that the D community is mostly to blame for not making a good case to the other group that are open to D, but for technical reasons or simply personal preference don't like GC, that D is still an option. There's no excuse for not making it easy to evaluate one's options for GC-less programming if we support that style of programming.
Apr 29
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Saturday, 29 April 2017 at 10:54:02 UTC, bachmeier wrote:
 Many invested in Rust and C++ will look for arguments to 
 support staying with their language. I've come to the 
 conclusion that the D community is mostly to blame for not 
 making a good case to the other group that are open to D, but 
 for technical reasons or simply personal preference don't like 
 GC, that D is still an option. There's no excuse for not making 
 it easy to evaluate one's options for GC-less programming if we 
 support that style of programming.
Of course. It is useful for D-users who are looking for alternatives to the GC if written for that group. Finding complete and up to date information is always the biggest challenge for newbies. Just don't expect it to have an effect on reddit users...
Apr 29
prev sibling parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Fri, Apr 28, 2017 at 04:03:18PM +0000, bachmeier via Digitalmars-d wrote:
 On Friday, 28 April 2017 at 15:23:18 UTC, H. S. Teoh wrote:
 
 you could save yourself the bug by writing:
 
 	auto x = malloc(...);
 	scope(exit) free(x);
 	// ... however many pages of stuff you want, you don't have to
 	// remember to write free() afterwards!
 
 Yes, D comes with a GC... doesn't mean you have to use it if you
 don't want to, though!
I usually use the GC, so I have limited knowledge in this area. How common is this pattern in D code? Is it better than using reference counted structs? Is there any advantage to using the GC in this scenario?
To be honest, in my own D code I'm not overly concerned with the GC, and even when I am, and want to control when / how often the GC collects, I usually just use GC.disable() and then GC.collect() explicitly. I've seen performance gains of about 30-40% just by carefully reducing the frequency of GC collections (IMO the default is a bit too eager), but of course that depends on exactly what your application is doing. In my case, that was in the context of batch-oriented, CPU-intensive computations that allocate often and mostly keeps live data. YMMV if your program is doing something else or has other patterns of memory access. But my point was that, if you really wanted to, you *could* use C-style memory management in D code. D won't stop you from doing that. The malloc heap is distinct from the GC heap so you won't run into conflicts. Of course, that also means you can't use D features that currently require the GC, such as closures and dynamic arrays. But if you're doing C-style memory management you probably already want to implement your own way of handling array allocations and closure functionality anyway. You can still pass slices of things around to things like Phobos range algorithms (excepting the few that might allocate -- hence marking your code with nogc for the compiler to enforce this), so generally a decent chunk of Phobos should still be usable. Even Phobos itself uses malloc/free directly in several places, for various reasons, so I wouldn't say it's exactly a foreign thing to do in D code.
 I would like to add this info to the wiki (I don't seen it there).
That would be very nice, thanks! T -- Give a man a fish, and he eats once. Teach a man to fish, and he will sit forever.
Apr 28
prev sibling next sibling parent Mike Parker <aldacron gmail.com> writes:
On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
 Frankly seeing in this example that the GC was in theory able 
 to kick in 6 times in a simple 100 item loop, that is not 
 efficient. I if did my own memory management, the variable 
 cleanup will have been done in one go, right after the loop.
Please reread that bit. "there were six total GC allocations in the loop. That means there were six opportunities for the GC to collect garbage." Keyword: opportunities. There were six allocations, not six collections. The GC only "kicks in" when it needs to reclaim memory. In this case, the six allocations are made by the array management in DRuntime. It's the same as you allocating with `new` six times. In all of those cases, as long as the GC has room in its pool from which to allocate, there will be no collections. Preallocate as much as possible and minimize the number of GC allocations (allocate on the stack where possible and through malloc where necessary) and the GC is not going to get in the way for most D programs you write.
Apr 27
prev sibling parent Era Scarecrow <rtcvb32 yahoo.com> writes:
On Thursday, 27 April 2017 at 19:36:44 UTC, Ben wrote:
 Frankly seeing in this example that the GC was in theory able 
 to kick in 6 times in a simple 100 item loop, that is not 
 efficient. I if did my own memory management, the variable 
 cleanup will have been done in one go, right after the loop. 
 Simply more efficient.
I find myself trying to use the stack as much as possible for buffers and structs so i can control and throw them away properly without worrying about the GC. The downside is they have to be fairly small (at least under windows without forcing it using a new thread or fiber).
Apr 27
prev sibling parent reply bachmeier <no spam.net> writes:
On Thursday, 27 April 2017 at 15:50:56 UTC, Ben wrote:
 A few days ago i was reading this topic:

 https://news.ycombinator.com/item?id=14165198

 And the whole GC keeps coming up as a negative ( compared to 
 Rust ).

 From my understanding there has been a proposal DIP1000 to 
 address this issue. Is there any update on this topic?

 Is it possible to run D without the GC AND the standard library?
You might find this blog post relevant: http://dlang.org/blog/2017/03/20/dont-fear-the-reaper/ There is opposition to the GC from a small but vocal group of mostly C++ developers. Sometimes they even make valid arguments. You can find many threads on the topic here.
Apr 27
parent Jerry <hurricane hereiam.com> writes:
On Thursday, 27 April 2017 at 17:31:42 UTC, bachmeier wrote:
 On Thursday, 27 April 2017 at 15:50:56 UTC, Ben wrote:
 A few days ago i was reading this topic:

 https://news.ycombinator.com/item?id=14165198

 And the whole GC keeps coming up as a negative ( compared to 
 Rust ).

 From my understanding there has been a proposal DIP1000 to 
 address this issue. Is there any update on this topic?

 Is it possible to run D without the GC AND the standard 
 library?
There is opposition to the GC from a small but vocal group of mostly C++ developers. Sometimes they even make valid arguments. You can find many threads on the topic here.
Citation needed.
Apr 27