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