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 2017
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 2017
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 

) 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 2017
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 

 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 2017
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 2017
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 

 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 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

-- 
Those who've learned LaTeX swear by it. Those who are learning LaTeX swear at
it. -- Pete Bleackley
Apr 28 2017
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 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". Not true. scope has worse 
usability than a scoped pointer type.
Apr 29 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 

 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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017
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 2017