220 9288 article Path: news.gmane.org!not-for-mail From: xavi Newsgroups: gmane.comp.lang.c++.isocpp.proposals Subject: Re: Precise Per-Type Cyclic Garbage Collection (DRAFT 1) Date: Tue, 11 Feb 2014 20:13:45 +0100 Lines: 152 Approved: news@gmane.org Message-ID: References: Reply-To: std-proposals@isocpp.org NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bf1651c56e4e504f226416c X-Trace: ger.gmane.org 1392146020 12767 80.91.229.3 (11 Feb 2014 19:13:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 11 Feb 2014 19:13:40 +0000 (UTC) To: std-proposals Original-X-From: std-proposals+bncBCWJHYVQY4OBB2XM5GLQKGQE3CCQT6A@isocpp.org Tue Feb 11 20:13:49 2014 Return-path: Envelope-to: gclcip-std-proposals@m.gmane.org Original-Received: from mail-pa0-f70.google.com ([209.85.220.70]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WDImC-0001qA-Dx for gclcip-std-proposals@m.gmane.org; Tue, 11 Feb 2014 20:13:48 +0100 Original-Received: by mail-pa0-f70.google.com with SMTP id kq14sf18540784pab.9 for ; Tue, 11 Feb 2014 11:13:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:x-original-sender :x-original-authentication-results:reply-to:precedence:mailing-list :list-id:list-post:list-help:list-archive:list-subscribe :list-unsubscribe:content-type; bh=t9bcy9ar/OV2pezw87KQzyMYZ15D3kBLkUTccc8Nn0g=; b=f0rQv0NtgAxXmtEushxu9AdtBwU20sUuRmzd5Nv+pkR0D+mYu5h06mB8Xu2LEJf+xI pDELnFityrXCGUkM1NF0jhsygdV8qKbDOAF9B0FxWAunn3xV7V70EU94BymUt48fKS+l +0TTGG3hrMI/Ndg2cm2c1CVoxrY3Z+fvfpo2RLYOnxx7MOnqLNMkCk44le1JlJezdUTr WZGfsuiOnHFzGAz6xOQJMIUdlo65tu54q54yg3NkZCv6p/l2DYeTXuz48J9Uby9uRM83 bBtNLYAjX1nNVwBAAwa2GpKHmB3F/GUP8Jxkyz6kVo2k+UJ90iNQDgb1Xkxx7+RAw793 FZFg== X-Gm-Message-State: ALoCoQkmbV0IdUAuzQSVXbeZPcdYeqjeT8p2OjptBcBo4BrPSBKGTkxGyebFHZjQpQrIQnn2U7FY X-Received: by 10.68.197.73 with SMTP id is9mr124155pbc.0.1392146027216; Tue, 11 Feb 2014 11:13:47 -0800 (PST) X-BeenThere: std-proposals@isocpp.org Original-Received: by 10.140.96.138 with SMTP id k10ls2514008qge.66.gmail; Tue, 11 Feb 2014 11:13:46 -0800 (PST) X-Received: by 10.229.118.4 with SMTP id t4mr30718553qcq.9.1392146026117; Tue, 11 Feb 2014 11:13:46 -0800 (PST) Original-Received: from mail-qc0-x232.google.com (mail-qc0-x232.google.com [2607:f8b0:400d:c01::232]) by mx.google.com with ESMTPS id y1si3869977qce.57.2014.02.11.11.13.46 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 11:13:46 -0800 (PST) Received-SPF: pass (google.com: domain of gratal@gmail.com designates 2607:f8b0:400d:c01::232 as permitted sender) client-ip=2607:f8b0:400d:c01::232; Original-Received: by mail-qc0-f178.google.com with SMTP id m20so13574707qcx.37 for ; Tue, 11 Feb 2014 11:13:46 -0800 (PST) X-Received: by 10.224.40.130 with SMTP id k2mr60035855qae.91.1392146025733; Tue, 11 Feb 2014 11:13:45 -0800 (PST) Original-Received: by 10.96.29.67 with HTTP; Tue, 11 Feb 2014 11:13:45 -0800 (PST) In-Reply-To: X-Original-Sender: gratal@gmail.com X-Original-Authentication-Results: mx.google.com; spf=pass (google.com: domain of gratal@gmail.com designates 2607:f8b0:400d:c01::232 as permitted sender) smtp.mail=gratal@gmail.com; dkim=pass header.i=@gmail.com; dmarc=pass (p=NONE dis=NONE) header.from=gmail.com Precedence: list Mailing-list: list std-proposals@isocpp.org; contact std-proposals+owners@isocpp.org List-ID: X-Google-Group-Id: 399137483710 List-Post: , List-Help: , List-Archive: List-Subscribe: , List-Unsubscribe: , Xref: news.gmane.org gmane.comp.lang.c++.isocpp.proposals:9288 Archived-At: --047d7bf1651c56e4e504f226416c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My main concern is whether a language extension is really necessary or it could be implemented as a library. Is it possible to achieve a similar effect with something like boost::intrusive_ptr (which removes all the awkwardness of enable_shared_from_this), where all reference-counted objects inherit from a ref-counter class, and add some mechanism to detect cycles? There might be certain things missing in the language: - Being able to forbid automatic storage for certain types. - Having some mechanism so that objects can only be created inside a smart pointer. Without inheritance, it's easy, by making the constructors private and make_ptr (or something similar) a friend. With inheritance things get much more complicated, so the language might need to be changed there. - Maybe tweak virtual inheritance so that it's possible to inherit from two ref-counted classes without significant overhead. If such a solution is possible, the language changes to allow it will also be useful in other situations, and it will make it easy to develop custom garbage-collection mechanisms in user code. 2014-02-11 Klaim - Jo=EBl Lamotte : > Hi, here are a few questions about this proposal: > > 1. This proposal is about a language extension, but seems (if I didn't > miss anything) to ignore C++11 minimal garbage collection hooks > as explained by Stroustrup there: > http://www.stroustrup.com/C++11FAQ.html#gc-abi > Did you take this into account? > > 2. Acronyms are harder to interpret, even in this case. > Instead of 'gc', I would suggest 'collected' (which is the adjective > you use to describe what the keyword does to the type) > > 3. How do you expect generic algorithm developers to work with types whic= h > can't be manipulated through iterators/ranges? > > 4. Did you consider attaching the garbage collecting logic to specific > instances instead of types? > > -- > > --- > You received this message because you are subscribed to the Google Groups > "ISO C++ Standard - Future Proposals" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to std-proposals+unsubscribe@isocpp.org. > To post to this group, send email to std-proposals@isocpp.org. > Visit this group at > http://groups.google.com/a/isocpp.org/group/std-proposals/. > --=20 ---=20 You received this message because you are subscribed to the Google Groups "= ISO C++ Standard - Future Proposals" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org. To post to this group, send email to std-proposals@isocpp.org. Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa= ls/. --047d7bf1651c56e4e504f226416c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
My main concern is whether a language extension is re= ally necessary or it could be implemented as a library.=A0
Is it = possible to achieve a similar effect with something like boost::intrusive_p= tr (which removes all the awkwardness of enable_shared_from_this), where al= l reference-counted objects inherit from a ref-counter class, and add some = mechanism to detect cycles?
There might be certain things missing in the language:
=A0 = =A0- Being able to forbid automatic storage for certain types.
= =A0 =A0- Having some mechanism so that objects can only be created inside a= smart pointer. Without inheritance, it's easy, by making the construct= ors private and make_ptr (or something similar) a friend. With inheritance = things get much more complicated, so the language might need to be changed = there.
=A0 =A0- Maybe tweak virtual inheritance so that it's possible to = inherit from two ref-counted classes without significant overhead.

If such a solution is possible, the language changes to al= low it will also be useful in other situations, and it will make it easy to= develop custom garbage-collection mechanisms in user code.


2014-02= -11 Klaim - Jo=EBl Lamotte <mjklaim@gmail.com>:
Hi, here are a few questions ab= out this proposal:

1. This proposal is about a language extension, but seems (if = I didn't miss anything) to ignore C++11 minimal garbage collection hook= s
=A0 =A0 as explained by Stroustrup there:=A0ht= tp://www.stroustrup.com/C++11FAQ.html#gc-abi
=A0 =A0 Did you take th= is into account?

2. Acronyms are harder to interpret, even in this case.
=A0 =A0 Instead of 'gc', I would suggest 'collected' (which= is the adjective you use to describe what the keyword does to the type)

3. How d= o you expect generic algorithm developers to work with types which can'= t be manipulated through iterators/ranges?
=A0 =A0
4. Did y= ou consider attaching the garbage collecting logic to specific instances in= stead of types?

--
=A0
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/gro= up/std-proposals/.

--
 
---
You received this message because you are subscribed to the Google Groups &= quot;ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposals/<= /a>.
--047d7bf1651c56e4e504f226416c-- .