www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - GC blessed for C++ (again)

reply =?UTF-8?Q?Ali_=c3=87ehreli?= <acehreli yahoo.com> writes:
https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/

Ali
Sep 28 2016
next sibling parent Russel Winder via Digitalmars-d-announce writes:
On Wed, 2016-09-28 at 13:50 -0700, Ali =C3=87ehreli via Digitalmars-d-
announce wrote:
 https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_exp
 erimental_deferred_and_unordered/
=20
And the comments in the thread confirm why Reddit is a massive waste of time and resources. It should be garbage collected. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Sep 29 2016
prev sibling next sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli 
wrote:
 https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/

 Ali
GC is unnacceptable ! Ho ! a deferred and unordered destruction library, really cool ! Is there intelligent life in the C++ world ?
Sep 29 2016
parent finalpatch <fengli gmail.com> writes:
On Friday, 30 September 2016 at 03:42:27 UTC, deadalnix wrote:
 GC is unnacceptable !

 Ho ! a deferred and unordered destruction library, really cool !

 Is there intelligent life in the C++ world ?
I think the difference is that the solution is scoped to only those objects that you chose to use GC on, rather than GC everything by default. Because the GC is limited to a small set of objects and is done in a controlled manner, this avoids unpredictable pauses and problems with interop with external libraries.
Sep 30 2016
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli 
wrote:
 https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/

 Ali
The paragraph I like the most there is: "The other important difference is that deferred_heap meets C++'s zero-overhead principle by being opt-in and granular, not default and global" That is what I like the most about Herb's work...
Sep 30 2016
parent reply deadalnix <deadalnix gmail.com> writes:
On Friday, 30 September 2016 at 14:12:30 UTC, Dejan Lekic wrote:
 On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli 
 wrote:
 https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/

 Ali
The paragraph I like the most there is: "The other important difference is that deferred_heap meets C++'s zero-overhead principle by being opt-in and granular, not default and global" That is what I like the most about Herb's work...
We already have opt-in for the most part and I've been pushing for granular with isolated since at least 2014. So yeah, Herb's proposal is old news, but worse, it is kind of disappointing that it is anything new for the D community. I'm not sure if I or the community failed, but clearly there is a major failure here.
Oct 07 2016
next sibling parent jmh530 <john.michael.hall gmail.com> writes:
On Friday, 7 October 2016 at 21:21:43 UTC, deadalnix wrote:
 We already have opt-in for the most part and I've been pushing 
 for granular with isolated since at least 2014. So yeah, Herb's 
 proposal is old news, but worse, it is kind of disappointing 
 that it is anything new for the D community.
Something that isn't "new for the D community" can still be interesting.
Oct 07 2016
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Friday, 7 October 2016 at 21:21:43 UTC, deadalnix wrote:
 On Friday, 30 September 2016 at 14:12:30 UTC, Dejan Lekic wrote:
 On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli 
 wrote:
 [...]
The paragraph I like the most there is: "The other important difference is that deferred_heap meets C++'s zero-overhead principle by being opt-in and granular, not default and global" That is what I like the most about Herb's work...
We already have opt-in for the most part and I've been pushing for granular with isolated since at least 2014. So yeah, Herb's proposal is old news, but worse, it is kind of disappointing that it is anything new for the D community. I'm not sure if I or the community failed, but clearly there is a major failure here.
I don't know about failing - the isolated thing immediately reminded me of your proposal. Atila
Oct 09 2016
prev sibling parent reply Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli 
wrote:
 https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/

 Ali
Is it possible to have something similar as in library rather than GC in core language construct?
Apr 09
parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Monday, 10 April 2017 at 04:17:21 UTC, Swoorup Joshi wrote:
 On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli 
 wrote:
 https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/

 Ali
Is it possible to have something similar as in library rather than GC in core language construct?
Not without breaking changes.
Apr 09
parent reply Swoorup Joshi <swoorupjoshi gmail.com> writes:
On Monday, 10 April 2017 at 04:49:34 UTC, Jack Stouffer wrote:
 On Monday, 10 April 2017 at 04:17:21 UTC, Swoorup Joshi wrote:
 On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli 
 wrote:
 https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/

 Ali
Is it possible to have something similar as in library rather than GC in core language construct?
Not without breaking changes.
Breaking, you mean the standard library? or including user codebases?
Apr 11
next sibling parent Atila Neves <atila.neves gmail.com> writes:
On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote:
 On Monday, 10 April 2017 at 04:49:34 UTC, Jack Stouffer wrote:
 On Monday, 10 April 2017 at 04:17:21 UTC, Swoorup Joshi wrote:
 On Wednesday, 28 September 2016 at 20:50:28 UTC, Ali Çehreli 
 wrote:
 https://www.reddit.com/r/programming/comments/54xnbg/herb_sutters_experimental_deferred_and_unordered/

 Ali
Is it possible to have something similar as in library rather than GC in core language construct?
Not without breaking changes.
Breaking, you mean the standard library? or including user codebases?
There's nothing stopping anyone from writing something similar in D. It just wouldn't make `new` not allocate on the GC heap. Atila
Apr 11
prev sibling parent reply Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote:
 Breaking, you mean the standard library? or including user 
 codebases?
Taking the GC out of language constructs (e.g. ~=, AAs) would be a massive breaking change and would probably break the majority of D code in existence.
Apr 11
parent reply jmh530 <john.michael.hall gmail.com> writes:
On Tuesday, 11 April 2017 at 16:16:03 UTC, Jack Stouffer wrote:
 On Tuesday, 11 April 2017 at 07:02:19 UTC, Swoorup Joshi wrote:
 Breaking, you mean the standard library? or including user 
 codebases?
Taking the GC out of language constructs (e.g. ~=, AAs) would be a massive breaking change and would probably break the majority of D code in existence.
Is there a non-breaking way to do it that would increase the amount of flexibility while keeping the current behavior as a default? For instance, the equivalent of using std.experimental.allocator so that a user could switch between the default being GCAllocator or Mallocator, or something like that...
Apr 11
parent Jack Stouffer <jack jackstouffer.com> writes:
On Tuesday, 11 April 2017 at 16:50:20 UTC, jmh530 wrote:
 Is there a non-breaking way to do it that would increase the 
 amount of flexibility while keeping the current behavior as a 
 default? For instance, the equivalent of using 
 std.experimental.allocator so that a user could switch between 
 the default being GCAllocator or Mallocator, or something like 
 that...
From what I understand, the plan has always been to start to integrate std.experimental.allocator into Phobos when it stabilizes. There are some questions though: 1. How is this going to be done? Do we have the functions in Phobos allocate with theAllocator? Or, do we pass in an allocator type via template parameter? Or, do we pass in an allocator instance via function parameter? Each solution has it's own pros and cons. 2. How do you make it safe? For the GC allocator, you can make allocation safe, but not deallocation. So do you special case GCAllocator in Phobos code to not call GCAllocator.deallocate() and just let the GC collect? 3. How will safe ref-counting play in with this? Andrei has his sights set on putting all strings in their own ref-counted store in order to make them safe nogc. Is RC going to be it's own allocator? I've never seen comprehensive plans or ideas about allocator integration. I've heard rumblings about a collections library that supposed to use it, but never seen anything.
Apr 11