------=_Part_2503_26488091.1392127407450
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



Hey guys, this is a design I've been toying with (in the abstract for some=
=20
time actually).  It needs a bunch of work, but I would appreciate your=20
feedback on this short draft.  Also, if you are aware of any overlapping=20
past proposals that would be great.


Thanks,

Andrew.


Precise Per-Type Cyclic Garbage Collection (DRAFT 1)

Introduction / Summary

We propose a core language feature that allows objects of user-selected=20
class types to be cyclically garbage collected.  Constraints on the usage=
=20
of class types so selected, and pointers to such class types, are imposed=
=20
to enable the implementation of fast safe precise collection.

Motivation

Many C++ programs can be decomposed into (a) low-level components for which=
=20
the performance and timing control of manual memory management and value=20
layout are of great benefit; and (b) higher-level organizational components=
=20
for which the benefit is dominated and negligble - and the convenience of=
=20
safe automatic cyclic garbage collection would be worth the tradeoff.

It would be great to be able to get the best of both worlds in one program.=
=20
 That is, to be able to specify certain classes as being garbage collected=
=20
and others to be manually managed - and to only pay for what you use.

Comparison

With Boehm Demers Weiser Collector

The Boehm Collector can only be used either program-wide or not-at-all.=20
 What we propose isolates garbage collection only to certain user-selected=
=20
types.  Also, what we propose is precise garbage collection like in the=20
managed languages, as opposed to conservative collection.  The reachability=
=20
graph is tracked explicitly through instrumenting the type system.  That=20
is, rather than scanning entire memory areas for all potential pointers to=
=20
any dynamic memory, only the pointers to collected types are tracked - and=
=20
they are tracked as they are initialized, assigned and destroyed.  This=20
gives it a radically different performance profile, and makes it=20
proportional only to the use of collected types in the program, and not=20
proportional to all dynamic memory use.

With shared_ptr<T>

Shared pointers cannot deal with cycles.  weak_ptr often does not have a=20
sensible place where it can be applied to break cycles, and when it does it=
=20
is awkward to use.  Shared pointer are also awkward to use with this=20
through enable_shared_from_this.  What we propose is much cleaner and=20
easier to use, at the cost of the added implementation complexity of=20
compiler support.  Under the proposed feature, the user can just use=20
regular pointer syntax to work with collected types, and doesn=E2=80=99t ne=
ed to=20
worry about any of these issues.

With ownership and memory pools

Ownership schemes are many times artificial.  In many object models,=20
objects do not have natural owners, and it can be challenging to impose=20
one.  When an owner is selected the programmer must be careful to make sure=
=20
the lifetime of the owner encloses uses of the owned object.  This=20
implementation overhead and constraint is many times not worth the effort=
=20
compared to automatic memory management.

Memory pools, which are just artificial owners, are not feasible in many=20
long-running programs.  In many such programs the memory pool can never be=
=20
cleared, so they are no different than simply leaking into the heap and=20
waste and exhaust memory.

Specification

Introduce a context-sensitive keyword gc that can appear in the head of a=
=20
class specifier:

   class foo gc

   {

       ...

   };

If a class type is marked with gc, it is called a collected type.  A=20
subclass of a collected type is also a collected type, whether or not=20
marked with gc.  A collected type may not have any base classes that are=20
not also collected types.  It follows that all base classes and all=20
subclasses of a collected type are collected types.

An object of collected type is called a collected object. A collected=20
object may only be a complete object or a base class subobject, it may not=
=20
be a member subobject or an array element:

   foo x[10]; // ill-formed

   struct bar { foo x; } // ill-formed

You can use pointers instead:

   foo* x[10]; // ok

   struct bar { foo* x; } // ok

=20

A collected type may only be allocated with dynamic storage duration.  It=
=20
may not be allocated with automatic, static or thread local storage=20
duration.  Again, you can use pointers instead:

   auto s =3D new foo;

   thread_local auto t =3D new foo;

   void f()

   {

       auto a =3D new foo;

   }

An object of type pointer to a collected type, is called a collecting=20
pointer.  A collecting pointer cannot participate in pointer arithmetic.=20
 That is, there is no builtin meaning for addition, subtraction, increment=
=20
or decrement of a collected pointer.  It may also not be converted or cast=
=20
to or from void*, and it may not be the subject or result of a reinterpret=
=20
cast.  It may only be initialized or assigned a null pointer constant or=20
another collected pointer (possibly dynamic or static cast from a base=20
class or subclass).

If a complete collected object is destroyed, any pointers to it or its base=
=20
class subobjects are assigned the null pointer value by the implementation.

Given a time point at run-time of the program, we will describe a directed=
=20
graph as follows.  There is a root node.  For each complete object of=20
collected type there is a node.  For each non-null collecting pointer that=
=20
is not a member subobject of an object of collected type, there is an edge=
=20
from the root node to the complete object of the subject of the pointer.=20
 For each remaining non-null collecting pointer, there is an edge from the=
=20
collected object of which it is a member to the complete object that is the=
=20
subject of the pointer.  If there is no path from the root node to a=20
collected objects node, we say the collected object is unreachable.

The implementation shall automatically destroy collected objects, at some=
=20
point between when it first was unreachable and the end of the program, or=
=20
at the end of the program if they never become unreachable.  (As a quality=
=20
of implementation issue this should be as soon as reasonably possible given=
=20
reasonable resources.)

Implementation

If a program contains a collected type, a garbage collector is linked into=
=20
the program by the implementation. The constructor and destructor of both=
=20
collected types and collecting pointers are generated to talk to the=20
garbage collector.   The garbage collector uses this information to track=
=20
the graph.  Periodically the garbage collector searches the graph using a=
=20
generational or other garbage collection algorithm, deleting objects as=20
appropriate.

Outstanding Issues

How do references to collected types work?  References are much like=20
constrained pointers so the specification of a reference to collected type=
=20
would be similar to collecting pointers.

Are the restrictions on storage duration necessary?  Couldn=E2=80=99t colle=
cted=20
objects of non-dynamic storage duration simply be ignored by the collector?=
=20
 What about the subobject restriction?  It was initially felt that this=20
would simplify usage and make it safer - as well as easing implementation.

Is the assignment of null to pointers on delete necessary or helpful?=20
 Again this was a safety feature.  We wanted collecting pointers if=20
non-null to always be pointing to a collected object.  If they are deleted=
=20
manually, which would be unusual - we thought this would be because of=20
destructor timing, and not resources - given that the performance profile=
=20
of these high-level objects is most likely not paramount.


--=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/.

------=_Part_2503_26488091.1392127407450
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><span id=3D"docs-internal-guid-604495e8-212e-a8e1-f916-9b7=
a9204ad87"><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-b=
ottom:0pt;">Hey guys, this is a design I've been toying with (in the abstra=
ct for some time actually). &nbsp;It needs a bunch of work, but I would app=
reciate your feedback on this short draft. &nbsp;Also, if you are aware of =
any overlapping past proposals that would be great.</p><p dir=3D"ltr" style=
=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><br></p><p dir=3D"l=
tr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;">Thanks,</p=
><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;=
">Andrew.</p><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin=
-bottom:0pt;"><br></p><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0=
pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; =
color: rgb(0, 0, 0); background-color: transparent; font-weight: bold; whit=
e-space: pre-wrap;">Precise Per-Type Cyclic Garbage Collection (DRAFT 1)</s=
pan></p><br><span style=3D"font-size: 15px; font-family: Arial; color: rgb(=
0, 0, 0); background-color: transparent; font-weight: bold; white-space: pr=
e-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;mar=
gin-bottom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; color:=
 rgb(0, 0, 0); background-color: transparent; font-weight: bold; white-spac=
e: pre-wrap;">Introduction / Summary</span></p><br><span style=3D"font-size=
: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transpar=
ent; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.1=
5;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-f=
amily: Arial; color: rgb(0, 0, 0); background-color: transparent; white-spa=
ce: pre-wrap;">We propose a core language feature that allows objects of us=
er-selected class types to be cyclically garbage collected. &nbsp;Constrain=
ts on the usage of class types so selected, and pointers to such class type=
s, are imposed to enable the implementation of fast safe precise collection=
..</span></p><br><span style=3D"font-size: 15px; font-family: Arial; color: =
rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"></span=
><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;=
"><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); =
background-color: transparent; font-weight: bold; white-space: pre-wrap;">M=
otivation</span></p><br><span style=3D"font-size: 15px; font-family: Arial;=
 color: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;=
"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bot=
tom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0,=
 0, 0); background-color: transparent; white-space: pre-wrap;">Many C++ pro=
grams can be decomposed into (a) low-level components for which the perform=
ance and timing control of manual memory management and value layout are of=
 great benefit; and (b) higher-level organizational components for which th=
e benefit is dominated and negligble - and the convenience of safe automati=
c cyclic garbage collection would be worth the tradeoff.</span></p><br><spa=
n style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); backgr=
ound-color: transparent; white-space: pre-wrap;"></span><p dir=3D"ltr" styl=
e=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"fon=
t-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: tr=
ansparent; white-space: pre-wrap;">It would be great to be able to get the =
best of both worlds in one program. &nbsp;That is, to be able to specify ce=
rtain classes as being garbage collected and others to be manually managed =
- and to only pay for what you use.</span></p><br><span style=3D"font-size:=
 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transpare=
nt; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15=
;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-fa=
mily: Arial; color: rgb(0, 0, 0); background-color: transparent; font-weigh=
t: bold; white-space: pre-wrap;">Comparison</span></p><br><span style=3D"fo=
nt-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: t=
ransparent; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-hei=
ght:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px;=
 font-family: Arial; color: rgb(0, 0, 0); background-color: transparent; fo=
nt-weight: bold; white-space: pre-wrap;">With Boehm Demers Weiser Collector=
</span></p><br><span style=3D"font-size: 15px; font-family: Arial; color: r=
gb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"></span>=
<p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"=
><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); b=
ackground-color: transparent; white-space: pre-wrap;">The Boehm Collector c=
an only be used either program-wide or not-at-all. &nbsp;What we propose is=
olates garbage collection only to certain user-selected types. &nbsp;Also, =
what we propose is </span><span style=3D"font-size: 15px; font-family: Aria=
l; color: rgb(0, 0, 0); background-color: transparent; font-style: italic; =
white-space: pre-wrap;">precise</span><span style=3D"font-size: 15px; font-=
family: Arial; color: rgb(0, 0, 0); background-color: transparent; white-sp=
ace: pre-wrap;"> garbage collection like in the managed languages, as oppos=
ed to </span><span style=3D"font-size: 15px; font-family: Arial; color: rgb=
(0, 0, 0); background-color: transparent; font-style: italic; white-space: =
pre-wrap;">conservative</span><span style=3D"font-size: 15px; font-family: =
Arial; color: rgb(0, 0, 0); background-color: transparent; white-space: pre=
-wrap;"> collection. &nbsp;The reachability graph is tracked explicitly thr=
ough instrumenting the type system. &nbsp;That is, rather than scanning ent=
ire memory areas for all potential pointers to any dynamic memory, only the=
 pointers to collected types are tracked - and they are tracked as they are=
 initialized, assigned and destroyed. &nbsp;This gives it a radically diffe=
rent performance profile, and makes it proportional only to the use of coll=
ected types in the program, and not proportional to all dynamic memory use.=
</span></p><br><span style=3D"font-size: 15px; font-family: Arial; color: r=
gb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"></span>=
<p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"=
><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); b=
ackground-color: transparent; font-weight: bold; white-space: pre-wrap;">Wi=
th shared_ptr&lt;T&gt;</span></p><br><span style=3D"font-size: 15px; font-f=
amily: Arial; color: rgb(0, 0, 0); background-color: transparent; white-spa=
ce: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0=
pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; =
color: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"=
>Shared pointers cannot deal with cycles. &nbsp;weak_ptr often does not hav=
e a sensible place where it can be applied to break cycles, and when it doe=
s it is awkward to use. &nbsp;Shared pointer are also awkward to use with t=
his through enable_shared_from_this. &nbsp;What we propose is much cleaner =
and easier to use, at the cost of the added implementation complexity of co=
mpiler support. &nbsp;Under the proposed feature, the user can just use reg=
ular pointer syntax to work with collected types, and doesn=E2=80=99t need =
to worry about any of these issues.</span><span style=3D"font-size: 15px; f=
ont-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font=
-weight: bold; white-space: pre-wrap;"></span></p><br><span style=3D"font-s=
ize: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: trans=
parent; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; fon=
t-family: Arial; color: rgb(0, 0, 0); background-color: transparent; font-w=
eight: bold; white-space: pre-wrap;">With ownership and memory pools</span>=
</p><br><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0=
, 0); background-color: transparent; white-space: pre-wrap;"></span><p dir=
=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span=
 style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); backgro=
und-color: transparent; white-space: pre-wrap;">Ownership schemes are many =
times artificial. &nbsp;In many object models, objects do not have natural =
owners, and it can be challenging to impose one. &nbsp;When an owner is sel=
ected the programmer must be careful to make sure the lifetime of the owner=
 encloses uses of the owned object. &nbsp;This implementation overhead and =
constraint is many times not worth the effort compared to automatic memory =
management.</span></p><br><span style=3D"font-size: 15px; font-family: Aria=
l; color: rgb(0, 0, 0); background-color: transparent; white-space: pre-wra=
p;"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-b=
ottom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; color: rgb(=
0, 0, 0); background-color: transparent; white-space: pre-wrap;">Memory poo=
ls, which are just artificial owners, are not feasible in many long-running=
 programs. &nbsp;In many such programs the memory pool can never be cleared=
, so they are no different than simply leaking into the heap and waste and =
exhaust memory.</span></p><br><span style=3D"font-size: 15px; font-family: =
Arial; color: rgb(0, 0, 0); background-color: transparent; white-space: pre=
-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;marg=
in-bottom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; color: =
rgb(0, 0, 0); background-color: transparent; font-weight: bold; white-space=
: pre-wrap;">Specification</span></p><br><span style=3D"font-size: 15px; fo=
nt-family: Arial; color: rgb(0, 0, 0); background-color: transparent; white=
-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-t=
op:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-family: Ari=
al; color: rgb(0, 0, 0); background-color: transparent; white-space: pre-wr=
ap;">Introduce a context-sensitive keyword </span><span style=3D"font-size:=
 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transpare=
nt; font-weight: bold; white-space: pre-wrap;">gc</span><span style=3D"font=
-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: tra=
nsparent; white-space: pre-wrap;"> that can appear in the head of a class s=
pecifier:</span></p><br><span style=3D"font-size: 15px; font-family: Arial;=
 color: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;=
"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bot=
tom:0pt;"><span style=3D"font-size: 15px; font-family: 'Courier New'; color=
: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"> &nb=
sp;&nbsp;&nbsp;class foo gc</span></p><p dir=3D"ltr" style=3D"line-height:1=
..15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font=
-family: 'Courier New'; color: rgb(0, 0, 0); background-color: transparent;=
 white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;{</span></p><p dir=3D"ltr" styl=
e=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"fon=
t-size: 15px; font-family: 'Courier New'; color: rgb(0, 0, 0); background-c=
olor: transparent; white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;&nbsp;...</span></p><p dir=3D"ltr" style=3D"line-height:1.15;margin-to=
p:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-family: 'Cou=
rier New'; color: rgb(0, 0, 0); background-color: transparent; white-space:=
 pre-wrap;"> &nbsp;&nbsp;&nbsp;};</span></p><br><span style=3D"font-size: 1=
5px; font-family: Arial; color: rgb(0, 0, 0); background-color: transparent=
; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15;m=
argin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-fami=
ly: Arial; color: rgb(0, 0, 0); background-color: transparent; white-space:=
 pre-wrap;">If a class type is marked with gc, it is called a </span><span =
style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); backgrou=
nd-color: transparent; font-style: italic; white-space: pre-wrap;">collecte=
d type</span><span style=3D"font-size: 15px; font-family: Arial; color: rgb=
(0, 0, 0); background-color: transparent; white-space: pre-wrap;">. &nbsp;A=
 subclass of a collected type is also a collected type, whether or not mark=
ed with gc. &nbsp;A collected type may not have any base classes that are n=
ot also collected types. &nbsp;It follows that all base classes and all sub=
classes of a collected type are collected types.</span></p><br><span style=
=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-co=
lor: transparent; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"li=
ne-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size:=
 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transpare=
nt; white-space: pre-wrap;">An object of collected type is called a collect=
ed object. A collected object may only be a complete object or a base class=
 subobject, it may not be a member subobject or an array element:</span></p=
><br><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0=
); background-color: transparent; white-space: pre-wrap;"></span><p dir=3D"=
ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span sty=
le=3D"font-size: 15px; font-family: 'Courier New'; color: rgb(0, 0, 0); bac=
kground-color: transparent; white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;foo =
x[10]; // ill-formed</span></p><p dir=3D"ltr" style=3D"line-height:1.15;mar=
gin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-family=
: 'Courier New'; color: rgb(0, 0, 0); background-color: transparent; white-=
space: pre-wrap;"> &nbsp;&nbsp;&nbsp;struct bar { foo x; } // ill-formed</s=
pan></p><br><span style=3D"font-size: 15px; font-family: Arial; color: rgb(=
0, 0, 0); background-color: transparent; white-space: pre-wrap;"></span><p =
dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><s=
pan style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); back=
ground-color: transparent; white-space: pre-wrap;">You can use pointers ins=
tead:</span></p><br><span style=3D"font-size: 15px; font-family: Arial; col=
or: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"></=
span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:=
0pt;"><span style=3D"font-size: 15px; font-family: 'Courier New'; color: rg=
b(0, 0, 0); background-color: transparent; white-space: pre-wrap;"> &nbsp;&=
nbsp;&nbsp;foo* x[10]; // ok</span></p><p dir=3D"ltr" style=3D"line-height:=
1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; fon=
t-family: 'Courier New'; color: rgb(0, 0, 0); background-color: transparent=
; white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;struct bar { foo* x; } // ok</=
span></p><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bot=
tom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0,=
 0, 0); background-color: transparent; white-space: pre-wrap;"> &nbsp;</spa=
n></p><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom=
:0pt;"><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0,=
 0); background-color: transparent; white-space: pre-wrap;">A collected typ=
e may only be allocated with dynamic storage duration. &nbsp;It may not be =
allocated with automatic, static or thread local storage duration. &nbsp;Ag=
ain, you can use pointers instead:</span></p><br><span style=3D"font-size: =
15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transparen=
t; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15;=
margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-fam=
ily: 'Courier New'; color: rgb(0, 0, 0); background-color: transparent; whi=
te-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;auto s =3D new foo;</span></p><br><=
span style=3D"font-size: 15px; font-family: 'Courier New'; color: rgb(0, 0,=
 0); background-color: transparent; white-space: pre-wrap;"></span><p dir=
=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span=
 style=3D"font-size: 15px; font-family: 'Courier New'; color: rgb(0, 0, 0);=
 background-color: transparent; white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;=
thread_local auto t =3D new foo;</span></p><br><span style=3D"font-size: 15=
px; font-family: 'Courier New'; color: rgb(0, 0, 0); background-color: tran=
sparent; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height=
:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; fo=
nt-family: 'Courier New'; color: rgb(0, 0, 0); background-color: transparen=
t; white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;void f()</span></p><p dir=3D"=
ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span sty=
le=3D"font-size: 15px; font-family: 'Courier New'; color: rgb(0, 0, 0); bac=
kground-color: transparent; white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;{</s=
pan></p><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bott=
om:0pt;"><span style=3D"font-size: 15px; font-family: 'Courier New'; color:=
 rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"> &nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;auto a =3D new foo;</span></p><p dir=
=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span=
 style=3D"font-size: 15px; font-family: 'Courier New'; color: rgb(0, 0, 0);=
 background-color: transparent; white-space: pre-wrap;"> &nbsp;&nbsp;&nbsp;=
}</span></p><br><span style=3D"font-size: 15px; font-family: Arial; color: =
rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"></span=
><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;=
"><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); =
background-color: transparent; white-space: pre-wrap;">An object of type po=
inter to a collected type, is called a collecting pointer. &nbsp;A collecti=
ng pointer cannot participate in pointer arithmetic. &nbsp;That is, there i=
s no builtin meaning for addition, subtraction, increment or decrement of a=
 collected pointer. &nbsp;It may also not be converted or cast to or from v=
oid*, and it may not be the subject or result of a reinterpret cast. &nbsp;=
It may only be initialized or assigned a null pointer constant or another c=
ollected pointer (possibly dynamic or static cast from a base class or subc=
lass).</span></p><br><span style=3D"font-size: 15px; font-family: Arial; co=
lor: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"><=
/span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom=
:0pt;"><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0,=
 0); background-color: transparent; white-space: pre-wrap;">If a complete c=
ollected object is destroyed, any pointers to it or its base class subobjec=
ts are assigned the null pointer value by the implementation.</span></p><br=
><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); b=
ackground-color: transparent; white-space: pre-wrap;"></span><p dir=3D"ltr"=
 style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=
=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-co=
lor: transparent; white-space: pre-wrap;">Given a time point at run-time of=
 the program, we will describe a directed graph as follows. &nbsp;There is =
a root node. &nbsp;For each complete object of collected type there is a no=
de. &nbsp;For each non-null collecting pointer that is not a member subobje=
ct of an object of collected type, there is an edge from the root node to t=
he complete object of the subject of the pointer. &nbsp;For each remaining =
non-null collecting pointer, there is an edge from the collected object of =
which it is a member to the complete object that is the subject of the poin=
ter. &nbsp;If there is no path from the root node to a collected objects no=
de, we say the collected object is unreachable.</span></p><br><span style=
=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-co=
lor: transparent; white-space: pre-wrap;"></span><p dir=3D"ltr" style=3D"li=
ne-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font-size:=
 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: transpare=
nt; white-space: pre-wrap;">The implementation shall automatically destroy =
collected objects, at some point between when it first was unreachable and =
the end of the program, or at the end of the program if they never become u=
nreachable. &nbsp;(As a quality of implementation issue this should be as s=
oon as reasonably possible given reasonable resources.)</span></p><br><span=
 style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); backgro=
und-color: transparent; white-space: pre-wrap;"></span><p dir=3D"ltr" style=
=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=3D"font=
-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-color: tra=
nsparent; font-weight: bold; white-space: pre-wrap;">Implementation</span><=
/p><br><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0,=
 0); background-color: transparent; white-space: pre-wrap;"></span><p dir=
=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span=
 style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); backgro=
und-color: transparent; white-space: pre-wrap;">If a program contains a col=
lected type, a garbage collector is linked into the program by the implemen=
tation. The constructor and destructor of both collected types and collecti=
ng pointers are generated to talk to the garbage collector. &nbsp;&nbsp;The=
 garbage collector uses this information to track the graph. &nbsp;Periodic=
ally the garbage collector searches the graph using a generational or other=
 garbage collection algorithm, deleting objects as appropriate.</span></p><=
br><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0);=
 background-color: transparent; white-space: pre-wrap;"></span><p dir=3D"lt=
r" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt;"><span style=
=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background-co=
lor: transparent; font-weight: bold; white-space: pre-wrap;">Outstanding Is=
sues</span></p><br><span style=3D"font-size: 15px; font-family: Arial; colo=
r: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"></s=
pan><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0=
pt;"><span style=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0=
); background-color: transparent; white-space: pre-wrap;">How do references=
 to collected types work? &nbsp;References are much like constrained pointe=
rs so the specification of a reference to collected type would be similar t=
o collecting pointers.</span></p><br><span style=3D"font-size: 15px; font-f=
amily: Arial; color: rgb(0, 0, 0); background-color: transparent; white-spa=
ce: pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0=
pt;margin-bottom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; =
color: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;"=
>Are the restrictions on storage duration necessary? &nbsp;Couldn=E2=80=99t=
 collected objects of non-dynamic storage duration simply be ignored by the=
 collector? &nbsp;What about the subobject restriction? &nbsp;It was initia=
lly felt that this would simplify usage and make it safer - as well as easi=
ng implementation.</span></p><br><span style=3D"font-size: 15px; font-famil=
y: Arial; color: rgb(0, 0, 0); background-color: transparent; white-space: =
pre-wrap;"></span><p dir=3D"ltr" style=3D"line-height:1.15;margin-top:0pt;m=
argin-bottom:0pt;"><span style=3D"font-size: 15px; font-family: Arial; colo=
r: rgb(0, 0, 0); background-color: transparent; white-space: pre-wrap;">Is =
the assignment of null to pointers on delete necessary or helpful? &nbsp;Ag=
ain this was a safety feature. &nbsp;We wanted collecting pointers if non-n=
ull to always be pointing to a collected object. &nbsp;If they are deleted =
manually, which would be unusual - we thought this would be because of dest=
ructor timing, and not resources - given that the performance profile of th=
ese high-level objects is most likely not paramount.</span></p><br><span st=
yle=3D"font-size: 15px; font-family: Arial; color: rgb(0, 0, 0); background=
-color: transparent; white-space: pre-wrap;"></span></span><div><span><br><=
/span></div></div>

<p></p>

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

------=_Part_2503_26488091.1392127407450--

.

------=_Part_770_19298154.1392129828012
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, February 11, 2014 8:03:27 AM UTC-6, Andrew Tomazos wrote:
>
> Hey guys, this is a design I've been toying with (in the abstract for som=
e=20
> time actually).  It needs a bunch of work, but I would appreciate your=20
> feedback on this short draft.  Also, if you are aware of any overlapping=
=20
> past proposals that would be great.
>
>
> Thanks,
>
> Andrew.
>
>
> Precise Per-Type Cyclic Garbage Collection (DRAFT 1)
>
> Introduction / Summary
>
> We propose a core language feature that allows objects of user-selected=
=20
> class types to be cyclically garbage collected.  Constraints on the usage=
=20
> of class types so selected, and pointers to such class types, are imposed=
=20
> to enable the implementation of fast safe precise collection.
>
> Motivation
>
> Many C++ programs can be decomposed into (a) low-level components for=20
> which the performance and timing control of manual memory management and=
=20
> value layout are of great benefit; and (b) higher-level organizational=20
> components for which the benefit is dominated and negligble - and the=20
> convenience of safe automatic cyclic garbage collection would be worth th=
e=20
> tradeoff.
>
> It would be great to be able to get the best of both worlds in one=20
> program.  That is, to be able to specify certain classes as being garbage=
=20
> collected and others to be manually managed - and to only pay for what yo=
u=20
> use.
>
> Comparison
>
> With Boehm Demers Weiser Collector
>
> The Boehm Collector can only be used either program-wide or not-at-all.=
=20
>  What we propose isolates garbage collection only to certain user-selecte=
d=20
> types.  Also, what we propose is precise garbage collection like in the=
=20
> managed languages, as opposed to conservative collection.  The=20
> reachability graph is tracked explicitly through instrumenting the type=
=20
> system.  That is, rather than scanning entire memory areas for all=20
> potential pointers to any dynamic memory, only the pointers to collected=
=20
> types are tracked - and they are tracked as they are initialized, assigne=
d=20
> and destroyed.  This gives it a radically different performance profile,=
=20
> and makes it proportional only to the use of collected types in the=20
> program, and not proportional to all dynamic memory use.
>
> With shared_ptr<T>
>
> Shared pointers cannot deal with cycles.  weak_ptr often does not have a=
=20
> sensible place where it can be applied to break cycles, and when it does =
it=20
> is awkward to use.  Shared pointer are also awkward to use with this=20
> through enable_shared_from_this.  What we propose is much cleaner and=20
> easier to use, at the cost of the added implementation complexity of=20
> compiler support.  Under the proposed feature, the user can just use=20
> regular pointer syntax to work with collected types, and doesn=E2=80=99t =
need to=20
> worry about any of these issues.
>
> With ownership and memory pools
>
> Ownership schemes are many times artificial.  In many object models,=20
> objects do not have natural owners, and it can be challenging to impose=
=20
> one.  When an owner is selected the programmer must be careful to make su=
re=20
> the lifetime of the owner encloses uses of the owned object.  This=20
> implementation overhead and constraint is many times not worth the effort=
=20
> compared to automatic memory management.
>
> Memory pools, which are just artificial owners, are not feasible in many=
=20
> long-running programs.  In many such programs the memory pool can never b=
e=20
> cleared, so they are no different than simply leaking into the heap and=
=20
> waste and exhaust memory.
>
> Specification
>
> Introduce a context-sensitive keyword gc that can appear in the head of a=
=20
> class specifier:
>
>    class foo gc
>
>    {
>
>        ...
>
>    };
>
> If a class type is marked with gc, it is called a collected type.  A=20
> subclass of a collected type is also a collected type, whether or not=20
> marked with gc.  A collected type may not have any base classes that are=
=20
> not also collected types.  It follows that all base classes and all=20
> subclasses of a collected type are collected types.
>
> An object of collected type is called a collected object. A collected=20
> object may only be a complete object or a base class subobject, it may no=
t=20
> be a member subobject or an array element:
>
>    foo x[10]; // ill-formed
>
>    struct bar { foo x; } // ill-formed
>
> You can use pointers instead:
>
>    foo* x[10]; // ok
>
>    struct bar { foo* x; } // ok
>
> =20
>
> A collected type may only be allocated with dynamic storage duration.  It=
=20
> may not be allocated with automatic, static or thread local storage=20
> duration.  Again, you can use pointers instead:
>
>    auto s =3D new foo;
>
>    thread_local auto t =3D new foo;
>
>    void f()
>
>    {
>
>        auto a =3D new foo;
>
>    }
>
> An object of type pointer to a collected type, is called a collecting=20
> pointer.  A collecting pointer cannot participate in pointer arithmetic.=
=20
>  That is, there is no builtin meaning for addition, subtraction, incremen=
t=20
> or decrement of a collected pointer.  It may also not be converted or cas=
t=20
> to or from void*, and it may not be the subject or result of a reinterpre=
t=20
> cast.  It may only be initialized or assigned a null pointer constant or=
=20
> another collected pointer (possibly dynamic or static cast from a base=20
> class or subclass).
>
> If a complete collected object is destroyed, any pointers to it or its=20
> base class subobjects are assigned the null pointer value by the=20
> implementation.
>
> Given a time point at run-time of the program, we will describe a directe=
d=20
> graph as follows.  There is a root node.  For each complete object of=20
> collected type there is a node.  For each non-null collecting pointer tha=
t=20
> is not a member subobject of an object of collected type, there is an edg=
e=20
> from the root node to the complete object of the subject of the pointer.=
=20
>  For each remaining non-null collecting pointer, there is an edge from th=
e=20
> collected object of which it is a member to the complete object that is t=
he=20
> subject of the pointer.  If there is no path from the root node to a=20
> collected objects node, we say the collected object is unreachable.
>
> The implementation shall automatically destroy collected objects, at some=
=20
> point between when it first was unreachable and the end of the program, o=
r=20
> at the end of the program if they never become unreachable.  (As a qualit=
y=20
> of implementation issue this should be as soon as reasonably possible giv=
en=20
> reasonable resources.)
>
> Implementation
>
> If a program contains a collected type, a garbage collector is linked int=
o=20
> the program by the implementation. The constructor and destructor of both=
=20
> collected types and collecting pointers are generated to talk to the=20
> garbage collector.   The garbage collector uses this information to track=
=20
> the graph.  Periodically the garbage collector searches the graph using a=
=20
> generational or other garbage collection algorithm, deleting objects as=
=20
> appropriate.
>
> Outstanding Issues
>
> How do references to collected types work?  References are much like=20
> constrained pointers so the specification of a reference to collected typ=
e=20
> would be similar to collecting pointers.
>
> Are the restrictions on storage duration necessary?  Couldn=E2=80=99t col=
lected=20
> objects of non-dynamic storage duration simply be ignored by the collecto=
r?=20
>  What about the subobject restriction?  It was initially felt that this=
=20
> would simplify usage and make it safer - as well as easing implementation=
..
>
> Is the assignment of null to pointers on delete necessary or helpful?=20
>  Again this was a safety feature.  We wanted collecting pointers if=20
> non-null to always be pointing to a collected object.  If they are delete=
d=20
> manually, which would be unusual - we thought this would be because of=20
> destructor timing, and not resources - given that the performance profile=
=20
> of these high-level objects is most likely not paramount.
>
>
> So, what is the point to having garbage collection in C++?  My problem=20
with gc in general is two fold:  1) It tends to laziness -- that is=20
developers use it and then don't ever really understand object lifetime,=20
etc.  and 2) it is non-deterministic.  The control over lifetime of an=20
object is left up to the implementation of the collector -- not to the=20
developer who should fully understand the required lifetime.

I'm also not sure you've made the case for why shared_ptr is=20
insufficient.  It, like unique_ptr, gives you exact control over the=20
lifetime of pointers.  They are tied to scope and reference counts as they=
=20
are actually used.  I may be slow, but I don't understand what you mean by =
"Shared=20
pointers cannot deal with cycles."  What cycles?

One of my complaints about managed languages is that everything becomes a=
=20
pointer -- everything is made with new.  Why bring that flaw into C++?

I also suspect that the idea of restricting reinterpret_cast is going to be=
=20
problematic.  One of the best things about C++ is that your hands are NOT=
=20
tied -- if you want to leak memory, it is expected that you have a good=20
reason for it.  If you want to cast something to void *, it is again=20
expected that you have a good reason for doing it.  Everyone knows better=
=20
than to reinterpret_cast without a very good reason, right?

Sorry to come down sounding negative, I personally just don't see the need=
=20
and don't want C++ to pickup what I think are mistakes in managed languages=
..

Best wishes anyway.=20

--=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/.

------=_Part_770_19298154.1392129828012
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 11, 2014 8:03:27 AM UTC-6, Andrew Tom=
azos wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0=
..8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left=
-width: 1px; border-left-style: solid;"><div dir=3D"ltr"><span><p style=3D"=
line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr">Hey gu=
ys, this is a design I've been toying with (in the abstract for some time a=
ctually). &nbsp;It needs a bunch of work, but I would appreciate your feedb=
ack on this short draft. &nbsp;Also, if you are aware of any overlapping pa=
st proposals that would be great.</p><p style=3D"line-height: 1.15; margin-=
top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><br></p><p style=3D"line-height:=
 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr">Thanks,</p><p styl=
e=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr">A=
ndrew.</p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0p=
t;" dir=3D"ltr"><br></p><p style=3D"line-height: 1.15; margin-top: 0pt; mar=
gin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-fami=
ly: Arial; font-size: 15px; font-weight: bold; white-space: pre-wrap; backg=
round-color: transparent;">Precise Per-Type Cyclic Garbage Collection (DRAF=
T 1)</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; =
font-size: 15px; font-weight: bold; white-space: pre-wrap; background-color=
: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; marg=
in-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-famil=
y: Arial; font-size: 15px; font-weight: bold; white-space: pre-wrap; backgr=
ound-color: transparent;">Introduction / Summary</span></p><br><span style=
=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: =
pre-wrap; background-color: transparent;"></span><p style=3D"line-height: 1=
..15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color=
: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap;=
 background-color: transparent;">We propose a core language feature that al=
lows objects of user-selected class types to be cyclically garbage collecte=
d. &nbsp;Constraints on the usage of class types so selected, and pointers =
to such class types, are imposed to enable the implementation of fast safe =
precise collection.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-=
family: Arial; font-size: 15px; white-space: pre-wrap; background-color: tr=
ansparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-b=
ottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: A=
rial; font-size: 15px; font-weight: bold; white-space: pre-wrap; background=
-color: transparent;">Motivation</span></p><br><span style=3D"color: rgb(0,=
 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgro=
und-color: transparent;"></span><p style=3D"line-height: 1.15; margin-top: =
0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); f=
ont-family: Arial; font-size: 15px; white-space: pre-wrap; background-color=
: transparent;">Many C++ programs can be decomposed into (a) low-level comp=
onents for which the performance and timing control of manual memory manage=
ment and value layout are of great benefit; and (b) higher-level organizati=
onal components for which the benefit is dominated and negligble - and the =
convenience of safe automatic cyclic garbage collection would be worth the =
tradeoff.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Ar=
ial; font-size: 15px; white-space: pre-wrap; background-color: transparent;=
"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt=
;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font=
-size: 15px; white-space: pre-wrap; background-color: transparent;">It woul=
d be great to be able to get the best of both worlds in one program. &nbsp;=
That is, to be able to specify certain classes as being garbage collected a=
nd others to be manually managed - and to only pay for what you use.</span>=
</p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: =
15px; white-space: pre-wrap; background-color: transparent;"></span><p styl=
e=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><=
span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; fon=
t-weight: bold; white-space: pre-wrap; background-color: transparent;">Comp=
arison</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial=
; font-size: 15px; white-space: pre-wrap; background-color: transparent;"><=
/span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" =
dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-si=
ze: 15px; font-weight: bold; white-space: pre-wrap; background-color: trans=
parent;">With Boehm Demers Weiser Collector</span></p><br><span style=3D"co=
lor: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wr=
ap; background-color: transparent;"></span><p style=3D"line-height: 1.15; m=
argin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(=
0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backg=
round-color: transparent;">The Boehm Collector can only be used either prog=
ram-wide or not-at-all. &nbsp;What we propose isolates garbage collection o=
nly to certain user-selected types. &nbsp;Also, what we propose is </span><=
span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; fon=
t-style: italic; white-space: pre-wrap; background-color: transparent;">pre=
cise</span><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-siz=
e: 15px; white-space: pre-wrap; background-color: transparent;"> garbage co=
llection like in the managed languages, as opposed to </span><span style=3D=
"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; font-style: ital=
ic; white-space: pre-wrap; background-color: transparent;">conservative</sp=
an><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px;=
 white-space: pre-wrap; background-color: transparent;"> collection. &nbsp;=
The reachability graph is tracked explicitly through instrumenting the type=
 system. &nbsp;That is, rather than scanning entire memory areas for all po=
tential pointers to any dynamic memory, only the pointers to collected type=
s are tracked - and they are tracked as they are initialized, assigned and =
destroyed. &nbsp;This gives it a radically different performance profile, a=
nd makes it proportional only to the use of collected types in the program,=
 and not proportional to all dynamic memory use.</span></p><br><span style=
=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: =
pre-wrap; background-color: transparent;"></span><p style=3D"line-height: 1=
..15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color=
: rgb(0, 0, 0); font-family: Arial; font-size: 15px; font-weight: bold; whi=
te-space: pre-wrap; background-color: transparent;">With shared_ptr&lt;T&gt=
;</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; fon=
t-size: 15px; white-space: pre-wrap; background-color: transparent;"></span=
><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=
=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size:=
 15px; white-space: pre-wrap; background-color: transparent;">Shared pointe=
rs cannot deal with cycles. &nbsp;weak_ptr often does not have a sensible p=
lace where it can be applied to break cycles, and when it does it is awkwar=
d to use. &nbsp;Shared pointer are also awkward to use with this through en=
able_shared_from_this. &nbsp;What we propose is much cleaner and easier to =
use, at the cost of the added implementation complexity of compiler support=
.. &nbsp;Under the proposed feature, the user can just use regular pointer s=
yntax to work with collected types, and doesn=E2=80=99t need to worry about=
 any of these issues.</span><span style=3D"color: rgb(0, 0, 0); font-family=
: Arial; font-size: 15px; font-weight: bold; white-space: pre-wrap; backgro=
und-color: transparent;"></span></p><br><span style=3D"color: rgb(0, 0, 0);=
 font-family: Arial; font-size: 15px; white-space: pre-wrap; background-col=
or: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; ma=
rgin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-fam=
ily: Arial; font-size: 15px; font-weight: bold; white-space: pre-wrap; back=
ground-color: transparent;">With ownership and memory pools</span></p><br><=
span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; whi=
te-space: pre-wrap; background-color: transparent;"></span><p style=3D"line=
-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span styl=
e=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space:=
 pre-wrap; background-color: transparent;">Ownership schemes are many times=
 artificial. &nbsp;In many object models, objects do not have natural owner=
s, and it can be challenging to impose one. &nbsp;When an owner is selected=
 the programmer must be careful to make sure the lifetime of the owner encl=
oses uses of the owned object. &nbsp;This implementation overhead and const=
raint is many times not worth the effort compared to automatic memory manag=
ement.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial=
; font-size: 15px; white-space: pre-wrap; background-color: transparent;"><=
/span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" =
dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-si=
ze: 15px; white-space: pre-wrap; background-color: transparent;">Memory poo=
ls, which are just artificial owners, are not feasible in many long-running=
 programs. &nbsp;In many such programs the memory pool can never be cleared=
, so they are no different than simply leaking into the heap and waste and =
exhaust memory.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-fami=
ly: Arial; font-size: 15px; white-space: pre-wrap; background-color: transp=
arent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-botto=
m: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial=
; font-size: 15px; font-weight: bold; white-space: pre-wrap; background-col=
or: transparent;">Specification</span></p><br><span style=3D"color: rgb(0, =
0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgrou=
nd-color: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0=
pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); fo=
nt-family: Arial; font-size: 15px; white-space: pre-wrap; background-color:=
 transparent;">Introduce a context-sensitive keyword </span><span style=3D"=
color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; font-weight: bold=
; white-space: pre-wrap; background-color: transparent;">gc</span><span sty=
le=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space=
: pre-wrap; background-color: transparent;"> that can appear in the head of=
 a class specifier:</span></p><br><span style=3D"color: rgb(0, 0, 0); font-=
family: Arial; font-size: 15px; white-space: pre-wrap; background-color: tr=
ansparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-b=
ottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "=
Courier New"; font-size: 15px; white-space: pre-wrap; background-color: tra=
nsparent;'> &nbsp;&nbsp;&nbsp;class foo gc</span></p><p style=3D"line-heigh=
t: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'c=
olor: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; white-spac=
e: pre-wrap; background-color: transparent;'> &nbsp;&nbsp;&nbsp;{</span></p=
><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=
=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courier New"; fo=
nt-size: 15px; white-space: pre-wrap; background-color: transparent;'> &nbs=
p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;...</span></p><p style=3D"line-height=
: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'co=
lor: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; white-space=
: pre-wrap; background-color: transparent;'> &nbsp;&nbsp;&nbsp;};</span></p=
><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15p=
x; white-space: pre-wrap; background-color: transparent;"></span><p style=
=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><s=
pan style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; whit=
e-space: pre-wrap; background-color: transparent;">If a class type is marke=
d with gc, it is called a </span><span style=3D"color: rgb(0, 0, 0); font-f=
amily: Arial; font-size: 15px; font-style: italic; white-space: pre-wrap; b=
ackground-color: transparent;">collected type</span><span style=3D"color: r=
gb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; ba=
ckground-color: transparent;">. &nbsp;A subclass of a collected type is als=
o a collected type, whether or not marked with gc. &nbsp;A collected type m=
ay not have any base classes that are not also collected types. &nbsp;It fo=
llows that all base classes and all subclasses of a collected type are coll=
ected types.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family:=
 Arial; font-size: 15px; white-space: pre-wrap; background-color: transpare=
nt;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: =
0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; f=
ont-size: 15px; white-space: pre-wrap; background-color: transparent;">An o=
bject of collected type is called a collected object. A collected object ma=
y only be a complete object or a base class subobject, it may not be a memb=
er subobject or an array element:</span></p><br><span style=3D"color: rgb(0=
, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgr=
ound-color: transparent;"></span><p style=3D"line-height: 1.15; margin-top:=
 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); =
font-family: "Courier New"; font-size: 15px; white-space: pre-wrap; backgro=
und-color: transparent;'> &nbsp;&nbsp;&nbsp;foo x[10]; // ill-formed</span>=
</p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" di=
r=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courier New"; f=
ont-size: 15px; white-space: pre-wrap; background-color: transparent;'> &nb=
sp;&nbsp;&nbsp;struct bar { foo x; } // ill-formed</span></p><br><span styl=
e=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space:=
 pre-wrap; background-color: transparent;"></span><p style=3D"line-height: =
1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"colo=
r: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap=
; background-color: transparent;">You can use pointers instead:</span></p><=
br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px;=
 white-space: pre-wrap; background-color: transparent;"></span><p style=3D"=
line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span =
style=3D'color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; =
white-space: pre-wrap; background-color: transparent;'> &nbsp;&nbsp;&nbsp;f=
oo* x[10]; // ok</span></p><p style=3D"line-height: 1.15; margin-top: 0pt; =
margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-f=
amily: "Courier New"; font-size: 15px; white-space: pre-wrap; background-co=
lor: transparent;'> &nbsp;&nbsp;&nbsp;struct bar { foo* x; } // ok</span></=
p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=
=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size:=
 15px; white-space: pre-wrap; background-color: transparent;"> &nbsp;</span=
></p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" d=
ir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-siz=
e: 15px; white-space: pre-wrap; background-color: transparent;">A collected=
 type may only be allocated with dynamic storage duration. &nbsp;It may not=
 be allocated with automatic, static or thread local storage duration. &nbs=
p;Again, you can use pointers instead:</span></p><br><span style=3D"color: =
rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; b=
ackground-color: transparent;"></span><p style=3D"line-height: 1.15; margin=
-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0,=
 0); font-family: "Courier New"; font-size: 15px; white-space: pre-wrap; ba=
ckground-color: transparent;'> &nbsp;&nbsp;&nbsp;auto s =3D new foo;</span>=
</p><br><span style=3D'color: rgb(0, 0, 0); font-family: "Courier New"; fon=
t-size: 15px; white-space: pre-wrap; background-color: transparent;'></span=
><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=
=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courier New"; fo=
nt-size: 15px; white-space: pre-wrap; background-color: transparent;'> &nbs=
p;&nbsp;&nbsp;thread_local auto t =3D new foo;</span></p><br><span style=3D=
'color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; white-sp=
ace: pre-wrap; background-color: transparent;'></span><p style=3D"line-heig=
ht: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'=
color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; white-spa=
ce: pre-wrap; background-color: transparent;'> &nbsp;&nbsp;&nbsp;void f()</=
span></p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt=
;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courier Ne=
w"; font-size: 15px; white-space: pre-wrap; background-color: transparent;'=
> &nbsp;&nbsp;&nbsp;{</span></p><p style=3D"line-height: 1.15; margin-top: =
0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); f=
ont-family: "Courier New"; font-size: 15px; white-space: pre-wrap; backgrou=
nd-color: transparent;'> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;auto a =
=3D new foo;</span></p><p style=3D"line-height: 1.15; margin-top: 0pt; marg=
in-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-famil=
y: "Courier New"; font-size: 15px; white-space: pre-wrap; background-color:=
 transparent;'> &nbsp;&nbsp;&nbsp;}</span></p><br><span style=3D"color: rgb=
(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; back=
ground-color: transparent;"></span><p style=3D"line-height: 1.15; margin-to=
p: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0)=
; font-family: Arial; font-size: 15px; white-space: pre-wrap; background-co=
lor: transparent;">An object of type pointer to a collected type, is called=
 a collecting pointer. &nbsp;A collecting pointer cannot participate in poi=
nter arithmetic. &nbsp;That is, there is no builtin meaning for addition, s=
ubtraction, increment or decrement of a collected pointer. &nbsp;It may als=
o not be converted or cast to or from void*, and it may not be the subject =
or result of a reinterpret cast. &nbsp;It may only be initialized or assign=
ed a null pointer constant or another collected pointer (possibly dynamic o=
r static cast from a base class or subclass).</span></p><br><span style=3D"=
color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-=
wrap; background-color: transparent;"></span><p style=3D"line-height: 1.15;=
 margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rg=
b(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; bac=
kground-color: transparent;">If a complete collected object is destroyed, a=
ny pointers to it or its base class subobjects are assigned the null pointe=
r value by the implementation.</span></p><br><span style=3D"color: rgb(0, 0=
, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgroun=
d-color: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0p=
t; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); fon=
t-family: Arial; font-size: 15px; white-space: pre-wrap; background-color: =
transparent;">Given a time point at run-time of the program, we will descri=
be a directed graph as follows. &nbsp;There is a root node. &nbsp;For each =
complete object of collected type there is a node. &nbsp;For each non-null =
collecting pointer that is not a member subobject of an object of collected=
 type, there is an edge from the root node to the complete object of the su=
bject of the pointer. &nbsp;For each remaining non-null collecting pointer,=
 there is an edge from the collected object of which it is a member to the =
complete object that is the subject of the pointer. &nbsp;If there is no pa=
th from the root node to a collected objects node, we say the collected obj=
ect is unreachable.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-=
family: Arial; font-size: 15px; white-space: pre-wrap; background-color: tr=
ansparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-b=
ottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: A=
rial; font-size: 15px; white-space: pre-wrap; background-color: transparent=
;">The implementation shall automatically destroy collected objects, at som=
e point between when it first was unreachable and the end of the program, o=
r at the end of the program if they never become unreachable. &nbsp;(As a q=
uality of implementation issue this should be as soon as reasonably possibl=
e given reasonable resources.)</span></p><br><span style=3D"color: rgb(0, 0=
, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgroun=
d-color: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0p=
t; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); fon=
t-family: Arial; font-size: 15px; font-weight: bold; white-space: pre-wrap;=
 background-color: transparent;">Implementation</span></p><br><span style=
=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: =
pre-wrap; background-color: transparent;"></span><p style=3D"line-height: 1=
..15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color=
: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap;=
 background-color: transparent;">If a program contains a collected type, a =
garbage collector is linked into the program by the implementation. The con=
structor and destructor of both collected types and collecting pointers are=
 generated to talk to the garbage collector. &nbsp;&nbsp;The garbage collec=
tor uses this information to track the graph. &nbsp;Periodically the garbag=
e collector searches the graph using a generational or other garbage collec=
tion algorithm, deleting objects as appropriate.</span></p><br><span style=
=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: =
pre-wrap; background-color: transparent;"></span><p style=3D"line-height: 1=
..15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color=
: rgb(0, 0, 0); font-family: Arial; font-size: 15px; font-weight: bold; whi=
te-space: pre-wrap; background-color: transparent;">Outstanding Issues</spa=
n></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size=
: 15px; white-space: pre-wrap; background-color: transparent;"></span><p st=
yle=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"=
><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; w=
hite-space: pre-wrap; background-color: transparent;">How do references to =
collected types work? &nbsp;References are much like constrained pointers s=
o the specification of a reference to collected type would be similar to co=
llecting pointers.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-f=
amily: Arial; font-size: 15px; white-space: pre-wrap; background-color: tra=
nsparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bo=
ttom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Ar=
ial; font-size: 15px; white-space: pre-wrap; background-color: transparent;=
">Are the restrictions on storage duration necessary? &nbsp;Couldn=E2=80=99=
t collected objects of non-dynamic storage duration simply be ignored by th=
e collector? &nbsp;What about the subobject restriction? &nbsp;It was initi=
ally felt that this would simplify usage and make it safer - as well as eas=
ing implementation.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-=
family: Arial; font-size: 15px; white-space: pre-wrap; background-color: tr=
ansparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-b=
ottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: A=
rial; font-size: 15px; white-space: pre-wrap; background-color: transparent=
;">Is the assignment of null to pointers on delete necessary or helpful? &n=
bsp;Again this was a safety feature. &nbsp;We wanted collecting pointers if=
 non-null to always be pointing to a collected object. &nbsp;If they are de=
leted manually, which would be unusual - we thought this would be because o=
f destructor timing, and not resources - given that the performance profile=
 of these high-level objects is most likely not paramount.</span></p><br><s=
pan style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; whit=
e-space: pre-wrap; background-color: transparent;"></span></span><div><span=
><br></span></div></div></blockquote><div>So, what is the&nbsp;point to&nbs=
p;having garbage collection in C++?&nbsp; My problem with gc in general is =
two fold:&nbsp; 1)&nbsp;It tends to laziness -- that is developers use it a=
nd then don't ever really understand object lifetime, etc.&nbsp; and 2) it&=
nbsp;is non-deterministic.&nbsp; The control over lifetime of an object is =
left up to&nbsp;the implementation of the collector -- not to the developer=
 who should fully understand the required lifetime.</div><div><br></div><di=
v>I'm also not sure you've made the case&nbsp;for why shared_ptr is insuffi=
cient.&nbsp;&nbsp;It, like unique_ptr,&nbsp;gives you exact control over th=
e lifetime of pointers.&nbsp; They are tied to scope and reference counts a=
s they are&nbsp;actually used.&nbsp; I may be slow, but I don't understand =
what you mean&nbsp;by "<span style=3D"color: rgb(0, 0, 0); font-family: Ari=
al; font-size: 15px; white-space: pre-wrap; background-color: transparent;"=
>Shared pointers cannot deal with cycles.</span>"&nbsp; What cycles?</div><=
div><br></div><div>One of my complaints about managed languages is that eve=
rything becomes a pointer -- everything is&nbsp;made with new.&nbsp; Why br=
ing that flaw into C++?</div><div><br></div><div>I also suspect that the id=
ea of&nbsp;restricting reinterpret_cast is going to be problematic.&nbsp; O=
ne of the best things about&nbsp;C++ is that&nbsp;your hands are NOT tied -=
- if you want to leak memory, it is expected that you have a good reason fo=
r it.&nbsp; If you want to cast something to void *, it is again expected t=
hat you have a good reason for&nbsp;doing&nbsp;it.&nbsp; Everyone knows bet=
ter than to reinterpret_cast without a very good reason, right?</div><div><=
br></div><div>Sorry to come down sounding&nbsp;negative, I&nbsp;personally =
just don't see the need and don't want C++ to&nbsp;pickup what I think are =
mistakes in managed languages.</div><div><br></div><div>Best wishes anyway.=
&nbsp;</div></div>

<p></p>

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

------=_Part_770_19298154.1392129828012--

.

On 2014-02-11 09:43, Andrew Sandoval wrote:
> I'm also not sure you've made the case for why shared_ptr is
> insufficient.  It, like unique_ptr, gives you exact control over the
> lifetime of pointers.  They are tied to scope and reference counts as they
> are actually used.  I may be slow, but I don't understand what you mean by "Shared
> pointers cannot deal with cycles."  What cycles?

Let's say that A and B are classes that each keep a record of other
objects referencing them... Now say we have:

pa = make_shared<A>();
pb = make_shared<b>();
// both pa and pb have refcount 1
pa->connect(pb);
// *pa now has an sptr ref to *pb, likewise *pb to *pa
// refcount of pa, pb is 2

Now if pa and pb go out of scope, the objects are inaccessible to the
program but still reference each other, and so are not freed by
shared_ptr. The above may be a contrived example, but that's the idea of
a self-referential cycle. Any useful GC needs to be able to detect such
cycles.

Basically, "reachable memory" is not a function of refcounts but of what
memory is accessible, directly or indirectly, via all variables
currently in scope.

--
Matthew

--

---
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/.

.

------=_Part_128_24596735.1392141335601
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 11, 2014 11:12:01 AM UTC-6, Matthew Woehlke wrote:
>
> On 2014-02-11 09:43, Andrew Sandoval wrote:
> > I'm also not sure you've made the case for why shared_ptr is
> > insufficient.  It, like unique_ptr, gives you exact control over the
> > lifetime of pointers.  They are tied to scope and reference counts as
> they
> > are actually used.  I may be slow, but I don't understand what you mean
> by "Shared
> > pointers cannot deal with cycles."  What cycles?
>
> Let's say that A and B are classes that each keep a record of other
> objects referencing them... Now say we have:
>
> pa = make_shared<A>();
> pb = make_shared<b>();
> // both pa and pb have refcount 1
> pa->connect(pb);
> // *pa now has an sptr ref to *pb, likewise *pb to *pa
> // refcount of pa, pb is 2
>
> Now if pa and pb go out of scope, the objects are inaccessible to the
> program but still reference each other, and so are not freed by
> shared_ptr. The above may be a contrived example, but that's the idea of
> a self-referential cycle. Any useful GC needs to be able to detect such
> cycles.
>
> Basically, "reachable memory" is not a function of refcounts but of what
> memory is accessible, directly or indirectly, via all variables
> currently in scope.
>
> --
> Matthew
>
> I still don't see it.  if pa and pb go out of scope, the reference count
should drop to zero.  connect() should either have a shared_ptr at it's
scope or use one at the class scope and either way when the destructor
fires (at scope exit) the reference count should drop.  If not I would
think there is a design flaw.

More importantly, the whole thing can probably be simplified to start with
so that one or both do not need to be dynamically created.  I might be
alone in this, but I find that I very rarely ever use new outside of
singletons.  Almost everything is best kept owned within a particular
scope.  On the rare occasions that new is needed, the results always go to
a shared_ptr, either at local scope or in container at class scope, etc.

I'm not trying to pick on the idea, I just don't see it.  And maybe I'm
overstating this a little bit, but I really think that the languages that
use GC have fundamental flaws that hurt the quality of code written with
them.  Way back when Java first came out, GC was the salvation from
pointers.  The problem is that they just made a mess of something that was
never that bad to start with.  So, instead of leaks you get crashes due to
lifetime issues.  It's a lot easier to catch a leak than to solve
a free-after-use crash.  Objective-C, C#, they all have that problem still,
and they sort of ruin the whole meaning of scope.  RAII is a much better
way IMO.

-Andrew

--

---
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/.

------=_Part_128_24596735.1392141335601
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 11, 2014 11:12:01 AM UTC-6, Matthew W=
oehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px=
 0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-le=
ft-width: 1px; border-left-style: solid;">On 2014-02-11 09:43, Andrew Sando=
val wrote:
<br>&gt; I'm also not sure you've made the case for why shared_ptr is
<br>&gt; insufficient. &nbsp;It, like unique_ptr, gives you exact control o=
ver the
<br>&gt; lifetime of pointers. &nbsp;They are tied to scope and reference c=
ounts as they
<br>&gt; are actually used. &nbsp;I may be slow, but I don't understand wha=
t you mean by "Shared
<br>&gt; pointers cannot deal with cycles." &nbsp;What cycles?
<br>
<br>Let's say that A and B are classes that each keep a record of other=20
<br>objects referencing them... Now say we have:
<br>
<br>pa =3D make_shared&lt;A&gt;();
<br>pb =3D make_shared&lt;b&gt;();
<br>// both pa and pb have refcount 1
<br>pa-&gt;connect(pb);
<br>// *pa now has an sptr ref to *pb, likewise *pb to *pa
<br>// refcount of pa, pb is 2
<br>
<br>Now if pa and pb go out of scope, the objects are inaccessible to the=
=20
<br>program but still reference each other, and so are not freed by=20
<br>shared_ptr. The above may be a contrived example, but that's the idea o=
f=20
<br>a self-referential cycle. Any useful GC needs to be able to detect such=
=20
<br>cycles.
<br>
<br>Basically, "reachable memory" is not a function of refcounts but of wha=
t=20
<br>memory is accessible, directly or indirectly, via all variables=20
<br>currently in scope.
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote><div>I still don't see it.&nbsp; if pa and pb go out of sc=
ope, the reference count should drop to zero.&nbsp; connect() should either=
 have a shared_ptr at it's scope or use one at the class scope and either w=
ay when the destructor fires (at scope exit) the reference count should dro=
p.&nbsp; If not I&nbsp;would think there is a design flaw.</div><div><br></=
div><div>More importantly, the whole thing can probably be simplified to st=
art with so that one or both do not need to be dynamically created.&nbsp; I=
 might be alone in this, but I find that I very rarely ever use new outside=
 of singletons.&nbsp; Almost everything is best kept owned within a particu=
lar scope.&nbsp; On the rare occasions that new is needed, the results alwa=
ys go to a shared_ptr, either at local scope or in container at class scope=
, etc.</div><div><br></div><div>I'm not trying to pick on the idea, I just =
don't see it.&nbsp; And maybe I'm overstating this a little bit, but I real=
ly think that the languages that use GC have fundamental flaws that hurt th=
e quality of code written with them.&nbsp; Way back when Java first came ou=
t, GC was the salvation from pointers.&nbsp; The problem is that they just =
made a mess of something that was never that bad to start with.&nbsp; So, i=
nstead of leaks you get crashes due to lifetime issues.&nbsp; It's a lot ea=
sier to catch a leak than to solve a&nbsp;free-after-use crash.&nbsp; Objec=
tive-C, C#, they all have that problem still, and they sort of ruin the who=
le meaning of scope.&nbsp; RAII is a much better way IMO.</div><div><br></d=
iv><div>-Andrew</div><div><br></div></div>

<p></p>

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

------=_Part_128_24596735.1392141335601--

.

--089e0122991a4c3c8904f225b66c
Content-Type: text/plain; charset=UTF-8

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 which
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/.

--089e0122991a4c3c8904f225b66c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra">Hi, here are a few questions ab=
out this proposal:</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">1. This proposal is about a language extension, but seems (if =
I didn&#39;t miss anything) to ignore C++11 minimal garbage collection hook=
s</div>
<div class=3D"gmail_extra">=C2=A0 =C2=A0 as explained by Stroustrup there:=
=C2=A0<a href=3D"http://www.stroustrup.com/C++11FAQ.html#gc-abi">http://www=
..stroustrup.com/C++11FAQ.html#gc-abi</a><br>=C2=A0 =C2=A0 Did you take this=
 into account?<br><br>2. Acronyms are harder to interpret, even in this cas=
e.<br>
=C2=A0 =C2=A0 Instead of &#39;gc&#39;, I would suggest &#39;collected&#39; =
(which is the adjective you use to describe what the keyword does to the ty=
pe)</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">3.=
 How do you expect generic algorithm developers to work with types which ca=
n&#39;t be manipulated through iterators/ranges?</div>
<div class=3D"gmail_extra">=C2=A0 =C2=A0</div><div class=3D"gmail_extra">4.=
 Did you consider attaching the garbage collecting logic to specific instan=
ces instead of types?</div><div class=3D"gmail_extra"><br></div></div>

<p></p>

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

--089e0122991a4c3c8904f225b66c--

.

--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 <mjklaim@gmail.com>:

> 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

<div dir=3D"ltr"><div>My main concern is whether a language extension is re=
ally necessary or it could be implemented as a library.=A0</div><div>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?</div>
<div>There might be certain things missing in the language:</div><div>=A0 =
=A0- Being able to forbid automatic storage for certain types.</div><div>=
=A0 =A0- Having some mechanism so that objects can only be created inside a=
 smart pointer. Without inheritance, it&#39;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.</div>
<div>=A0 =A0- Maybe tweak virtual inheritance so that it&#39;s possible to =
inherit from two ref-counted classes without significant overhead.</div><di=
v><br></div><div>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.</div>
</div><div class=3D"gmail_extra"><br><br><div class=3D"gmail_quote">2014-02=
-11 Klaim - Jo=EBl Lamotte <span dir=3D"ltr">&lt;<a href=3D"mailto:mjklaim@=
gmail.com" target=3D"_blank">mjklaim@gmail.com</a>&gt;</span>:<br><blockquo=
te class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc so=
lid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">Hi, here are a few questions ab=
out this proposal:</div><div class=3D"gmail_extra"><br></div><div class=3D"=
gmail_extra">1. This proposal is about a language extension, but seems (if =
I didn&#39;t miss anything) to ignore C++11 minimal garbage collection hook=
s</div>

<div class=3D"gmail_extra">=A0 =A0 as explained by Stroustrup there:=A0<a h=
ref=3D"http://www.stroustrup.com/C++11FAQ.html#gc-abi" target=3D"_blank">ht=
tp://www.stroustrup.com/C++11FAQ.html#gc-abi</a><br>=A0 =A0 Did you take th=
is into account?<br>
<br>2. Acronyms are harder to interpret, even in this case.<br>
=A0 =A0 Instead of &#39;gc&#39;, I would suggest &#39;collected&#39; (which=
 is the adjective you use to describe what the keyword does to the type)</d=
iv><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">3. How d=
o you expect generic algorithm developers to work with types which can&#39;=
t be manipulated through iterators/ranges?</div>

<div class=3D"gmail_extra">=A0 =A0</div><div class=3D"gmail_extra">4. Did y=
ou consider attaching the garbage collecting logic to specific instances in=
stead of types?</div><div class=3D"gmail_extra"><br></div></div><div class=
=3D"HOEnZb">
<div class=3D"h5">

<p></p>

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

<p></p>

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

--047d7bf1651c56e4e504f226416c--

.

------=_Part_4975_28612542.1392146749376
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tuesday, February 11, 2014 7:34:52 PM UTC+1, Klaim - Jo=C3=ABl Lamotte w=
rote:
>
> 1. This proposal is about a language extension, but seems (if I didn't=20
> miss anything) to ignore C++11 minimal garbage collection hooks
>     as explained by Stroustrup there:=20
> http://www.stroustrup.com/C++11FAQ.html#gc-abi
>     Did you take this into account?
>

Yes.  The safely-derived pointer concept is designed for program-wide=20
conservative collection such as the Boehm collector.  This proposal is for=
=20
nominating specific types for collection by a precise collector.=20
 Collecting pointers are even more constrained than safely-derived=20
pointers, and they are better as the constraints on collecting pointers are=
=20
enforced at compile-time.
=20

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

3. How do you expect generic algorithm developers to work with types which=
=20
> can't be manipulated through iterators/ranges?
>

Integration with collections and algorithms needs some study, but the=20
initial idea is that you use pointer to T rather than T itself.  So for=20
example:

    vector<foo*> v =3D ...;

    for (auto x : v)
        x->do_something();

Clearly this doesn't work easily with user-defined equality, hashing and=20
comparison - this is no different than the situation today with pointers,=
=20
unique_ptrs or shared_ptrs.

But having said that - since posting the proposal I have come up with a=20
pretty radical idea of how to deal with this, but it is quite difficult to=
=20
explain and I need to work through the ramifications.  To try to summarize=
=20
it (and fail), a collected type will be a "handle" type.  It will store its=
=20
data members within an unnamed struct, and it will have one "hidden"=20
implicit member that is a pointer to that struct.  That way, what we call=
=20
in the original proposal a collecting pointer (foo*) will now be the=20
collected type itself (foo), and what was the collected type (foo) is now=
=20
an unnamed struct.  Within its member functions, the this pointer is set to=
=20
the implicit pointer member for looking up data members.  So from within=20
the class specifier it will look like you are defining a normal type and=20
you can use it mostly as normal, but when you copy construct it, it will be=
=20
a handle to the same instance.  The collection graph is then traced the=20
same way, except using these implicit pointer members and unnamed structs,=
=20
rather than the collecting pointers and collected types.  I have to double=
=20
check that this isn't completely insane, and if you couldn't follow what I=
=20
just said, I don't blame you.

4. Did you consider attaching the garbage collecting logic to specific=20
> instances instead of types?
>

Yes.  It doesn't seem to work as well.  If the entire type is nominated,=20
things seem to work out much cleaner.

--=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/.

------=_Part_4975_28612542.1392146749376
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 11, 2014 7:34:52 PM UTC+1, Klaim - Jo=
=C3=ABl Lamotte wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;=
margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=
=3D"ltr"><div>1. This proposal is about a language extension, but seems (if=
 I didn't miss anything) to ignore C++11 minimal garbage collection hooks<b=
r></div>
<div>&nbsp; &nbsp; as explained by Stroustrup there:&nbsp;<a href=3D"http:/=
/www.stroustrup.com/C++11FAQ.html#gc-abi" target=3D"_blank" onmousedown=3D"=
this.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fwww.stroustrup.com%=
2FC%2B%2B11FAQ.html%23gc-abi\46sa\75D\46sntz\0751\46usg\75AFQjCNEEb2g2Rql1G=
SPp6loHNkBQxPETVg';return true;" onclick=3D"this.href=3D'http://www.google.=
com/url?q\75http%3A%2F%2Fwww.stroustrup.com%2FC%2B%2B11FAQ.html%23gc-abi\46=
sa\75D\46sntz\0751\46usg\75AFQjCNEEb2g2Rql1GSPp6loHNkBQxPETVg';return true;=
">http://www.stroustrup.<wbr>com/C++11FAQ.html#gc-abi</a><br>&nbsp; &nbsp; =
Did you take this into account?<br></div></div></blockquote><div><br></div>=
<div>Yes. &nbsp;The safely-derived pointer concept is designed for program-=
wide conservative collection such as the Boehm collector. &nbsp;This propos=
al is for nominating specific types for collection by a precise collector. =
&nbsp;Collecting pointers are even more constrained than safely-derived poi=
nters, and they are better as the constraints on collecting pointers are en=
forced at compile-time.</div><div>&nbsp;</div><blockquote class=3D"gmail_qu=
ote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padd=
ing-left: 1ex;"><div dir=3D"ltr"><div>2. Acronyms are harder to interpret, =
even in this case.<br>
&nbsp; &nbsp; Instead of 'gc', I would suggest 'collected' (which is the ad=
jective you use to describe what the keyword does to the type)</div></div><=
/blockquote><div>&nbsp;</div><div>Noted. &nbsp;To be considered.</div><div>=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left:=
 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><di=
v></div><div>3. How do you expect generic algorithm developers to work with=
 types which can't be manipulated through iterators/ranges?</div></div></bl=
ockquote><div><br></div><div>Integration with collections and algorithms ne=
eds some study, but the initial idea is that you use pointer to T rather th=
an T itself. &nbsp;So for example:</div><div><br></div><div>&nbsp; &nbsp; v=
ector&lt;foo*&gt; v =3D ...;</div><div><br></div><div>&nbsp; &nbsp; for (au=
to x : v)</div><div>&nbsp; &nbsp; &nbsp; &nbsp; x-&gt;do_something();</div>=
<div><br></div><div>Clearly this doesn't work easily with user-defined equa=
lity, hashing and comparison - this is no different than the situation toda=
y with pointers, unique_ptrs or shared_ptrs.</div><div><br></div><div>But h=
aving said that - since posting the proposal I have come up with a pretty r=
adical idea of how to deal with this, but it is quite difficult to explain =
and I need to work through the ramifications. &nbsp;To try to summarize it =
(and fail), a collected type will be a "handle" type. &nbsp;It will store i=
ts data members within an unnamed struct, and it will have one "hidden" imp=
licit member that is a pointer to that struct. &nbsp;That way, what we call=
 in the original proposal a collecting pointer (foo*) will now be the colle=
cted type itself (foo), and what was the collected type (foo) is now an unn=
amed struct. &nbsp;Within its member functions, the this pointer is set to =
the implicit pointer member for looking up data members. &nbsp;So from with=
in the class specifier it will look like you are defining a normal type and=
 you can use it mostly as normal, but when you copy construct it, it will b=
e a handle to the same instance. &nbsp;The collection graph is then traced =
the same way, except using these implicit pointer members and unnamed struc=
ts, rather than the collecting pointers and collected types. &nbsp;I have t=
o double check that this isn't completely insane, and if you couldn't follo=
w what I just said, I don't blame you.</div><div><br></div><blockquote clas=
s=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;border-left: 1px #c=
cc solid;padding-left: 1ex;"><div dir=3D"ltr"><div>4. Did you consider atta=
ching the garbage collecting logic to specific instances instead of types?<=
/div></div></blockquote><div><br></div><div>Yes. &nbsp;It doesn't seem to w=
ork as well. &nbsp;If the entire type is nominated, things seem to work out=
 much cleaner.</div><div><br></div></div>

<p></p>

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

------=_Part_4975_28612542.1392146749376--

.

On 2014-02-11 14:13, xavi wrote:
> My main concern is whether a language extension is really necessary or it
> could be implemented as a library.

I believe there are already libraries in the wild that do this. IIRC,
VTK (http://vtk.org) is one...

See also http://www.aosabook.org/en/vtk.html and
http://www.vtk.org/doc/release/5.10/html/classvtkGarbageCollector.html.

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

These days you probably just want to friend std::make_shared.

> With inheritance things get much more complicated, so the language
> might need to be changed there.

I'm not sure a technical solution to this problem is required. If
someone wants to shoot themselves in the foot by bypassing a base class
that is intended to only ever be constructed into a shared_ptr...

>     - Maybe tweak virtual inheritance so that it's possible to inherit from
> two ref-counted classes without significant overhead.

Is this a problem in cases other than non-virtual inheritance from an
intrusive pointer class? (Do I miss why this would be an issue with
plain old std::shared_ptr?)

--
Matthew

--

---
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/.

.

------=_Part_1134_24666029.1392150367173
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable



What you are describing sounds similar to the way C++/CLI added managed=20
classes. If you are not familiar with it, you might check that out.

 I'm not sure if a GC is necessary, I find shared types are rare, and=20
cyclic shared types rarer still--which weak ptr breaks well enough.. Seems=
=20
like alot of complexity for little, if any gain. Perhaps this would be=20
better as a library solution?

 =20
=20
On Tuesday, February 11, 2014 11:03:27 AM UTC-3, Andrew Tomazos wrote:

> Hey guys, this is a design I've been toying with (in the abstract for som=
e=20
> time actually).  It needs a bunch of work, but I would appreciate your=20
> feedback on this short draft.  Also, if you are aware of any overlapping=
=20
> past proposals that would be great.
>
>
> Thanks,
>
> Andrew.
>
>
> Precise Per-Type Cyclic Garbage Collection (DRAFT 1)
>
> Introduction / Summary
>
> We propose a core language feature that allows objects of user-selected=
=20
> class types to be cyclically garbage collected.  Constraints on the usage=
=20
> of class types so selected, and pointers to such class types, are imposed=
=20
> to enable the implementation of fast safe precise collection.
>
> Motivation
>
> Many C++ programs can be decomposed into (a) low-level components for=20
> which the performance and timing control of manual memory management and=
=20
> value layout are of great benefit; and (b) higher-level organizational=20
> components for which the benefit is dominated and negligble - and the=20
> convenience of safe automatic cyclic garbage collection would be worth th=
e=20
> tradeoff.
>
> It would be great to be able to get the best of both worlds in one=20
> program.  That is, to be able to specify certain classes as being garbage=
=20
> collected and others to be manually managed - and to only pay for what yo=
u=20
> use.
>
> Comparison
>
> With Boehm Demers Weiser Collector
>
> The Boehm Collector can only be used either program-wide or not-at-all.=
=20
>  What we propose isolates garbage collection only to certain user-selecte=
d=20
> types.  Also, what we propose is precise garbage collection like in the=
=20
> managed languages, as opposed to conservative collection.  The=20
> reachability graph is tracked explicitly through instrumenting the type=
=20
> system.  That is, rather than scanning entire memory areas for all=20
> potential pointers to any dynamic memory, only the pointers to collected=
=20
> types are tracked - and they are tracked as they are initialized, assigne=
d=20
> and destroyed.  This gives it a radically different performance profile,=
=20
> and makes it proportional only to the use of collected types in the=20
> program, and not proportional to all dynamic memory use.
>
> With shared_ptr<T>
>
> Shared pointers cannot deal with cycles.  weak_ptr often does not have a=
=20
> sensible place where it can be applied to break cycles, and when it does =
it=20
> is awkward to use.  Shared pointer are also awkward to use with this=20
> through enable_shared_from_this.  What we propose is much cleaner and=20
> easier to use, at the cost of the added implementation complexity of=20
> compiler support.  Under the proposed feature, the user can just use=20
> regular pointer syntax to work with collected types, and doesn=E2=80=99t =
need to=20
> worry about any of these issues.
>
> With ownership and memory pools
>
> Ownership schemes are many times artificial.  In many object models,=20
> objects do not have natural owners, and it can be challenging to impose=
=20
> one.  When an owner is selected the programmer must be careful to make su=
re=20
> the lifetime of the owner encloses uses of the owned object.  This=20
> implementation overhead and constraint is many times not worth the effort=
=20
> compared to automatic memory management.
>
> Memory pools, which are just artificial owners, are not feasible in many=
=20
> long-running programs.  In many such programs the memory pool can never b=
e=20
> cleared, so they are no different than simply leaking into the heap and=
=20
> waste and exhaust memory.
>
> Specification
>
> Introduce a context-sensitive keyword gc that can appear in the head of a=
=20
> class specifier:
>
>    class foo gc
>
>    {
>
>        ...
>
>    };
>
> If a class type is marked with gc, it is called a collected type.  A=20
> subclass of a collected type is also a collected type, whether or not=20
> marked with gc.  A collected type may not have any base classes that are=
=20
> not also collected types.  It follows that all base classes and all=20
> subclasses of a collected type are collected types.
>
> An object of collected type is called a collected object. A collected=20
> object may only be a complete object or a base class subobject, it may no=
t=20
> be a member subobject or an array element:
>
>    foo x[10]; // ill-formed
>
>    struct bar { foo x; } // ill-formed
>
> You can use pointers instead:
>
>    foo* x[10]; // ok
>
>    struct bar { foo* x; } // ok
>
> =20
>
> A collected type may only be allocated with dynamic storage duration.  It=
=20
> may not be allocated with automatic, static or thread local storage=20
> duration.  Again, you can use pointers instead:
>
>    auto s =3D new foo;
>
>    thread_local auto t =3D new foo;
>
>    void f()
>
>    {
>
>        auto a =3D new foo;
>
>    }
>
> An object of type pointer to a collected type, is called a collecting=20
> pointer.  A collecting pointer cannot participate in pointer arithmetic.=
=20
>  That is, there is no builtin meaning for addition, subtraction, incremen=
t=20
> or decrement of a collected pointer.  It may also not be converted or cas=
t=20
> to or from void*, and it may not be the subject or result of a reinterpre=
t=20
> cast.  It may only be initialized or assigned a null pointer constant or=
=20
> another collected pointer (possibly dynamic or static cast from a base=20
> class or subclass).
>
> If a complete collected object is destroyed, any pointers to it or its=20
> base class subobjects are assigned the null pointer value by the=20
> implementation.
>
> Given a time point at run-time of the program, we will describe a directe=
d=20
> graph as follows.  There is a root node.  For each complete object of=20
> collected type there is a node.  For each non-null collecting pointer tha=
t=20
> is not a member subobject of an object of collected type, there is an edg=
e=20
> from the root node to the complete object of the subject of the pointer.=
=20
>  For each remaining non-null collecting pointer, there is an edge from th=
e=20
> collected object of which it is a member to the complete object that is t=
he=20
> subject of the pointer.  If there is no path from the root node to a=20
> collected objects node, we say the collected object is unreachable.
>
> The implementation shall automatically destroy collected objects, at some=
=20
> point between when it first was unreachable and the end of the program, o=
r=20
> at the end of the program if they never become unreachable.  (As a qualit=
y=20
> of implementation issue this should be as soon as reasonably possible giv=
en=20
> reasonable resources.)
>
> Implementation
>
> If a program contains a collected type, a garbage collector is linked int=
o=20
> the program by the implementation. The constructor and destructor of both=
=20
> collected types and collecting pointers are generated to talk to the=20
> garbage collector.   The garbage collector uses this information to track=
=20
> the graph.  Periodically the garbage collector searches the graph using a=
=20
> generational or other garbage collection algorithm, deleting objects as=
=20
> appropriate.
>
> Outstanding Issues
>
> How do references to collected types work?  References are much like=20
> constrained pointers so the specification of a reference to collected typ=
e=20
> would be similar to collecting pointers.
>
> Are the restrictions on storage duration necessary?  Couldn=E2=80=99t col=
lected=20
> objects of non-dynamic storage duration simply be ignored by the collecto=
r?=20
>  What about the subobject restriction?  It was initially felt that this=
=20
> would simplify usage and make it safer - as well as easing implementation=
..
>
> Is the assignment of null to pointers on delete necessary or helpful?=20
>  Again this was a safety feature.  We wanted collecting pointers if=20
> non-null to always be pointing to a collected object.  If they are delete=
d=20
> manually, which would be unusual - we thought this would be because of=20
> destructor timing, and not resources - given that the performance profile=
=20
> of these high-level objects is most likely not paramount.
>
>
>

--=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/.

------=_Part_1134_24666029.1392150367173
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p>What you are describing sounds similar to the way C++/C=
LI added managed classes. If you are not familiar with it, you might check =
that out.</p><p>&nbsp;I'm not sure if a GC is necessary, I find shared type=
s are rare, and cyclic shared types rarer still--which weak ptr breaks well=
 enough.. Seems like alot of complexity for little, if any gain. Perhaps th=
is would be better as a library solution?</p><p>&nbsp; <br>&nbsp;<br>On Tue=
sday, February 11, 2014 11:03:27 AM UTC-3, Andrew Tomazos wrote:</p><blockq=
uote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; padding-left=
: 1ex; border-left-color: rgb(204, 204, 204); border-left-width: 1px; borde=
r-left-style: solid;"><div dir=3D"ltr"><span><p style=3D"line-height: 1.15;=
 margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr">Hey guys, this is a desi=
gn I've been toying with (in the abstract for some time actually). &nbsp;It=
 needs a bunch of work, but I would appreciate your feedback on this short =
draft. &nbsp;Also, if you are aware of any overlapping past proposals that =
would be great.</p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-b=
ottom: 0pt;" dir=3D"ltr"><br></p><p style=3D"line-height: 1.15; margin-top:=
 0pt; margin-bottom: 0pt;" dir=3D"ltr">Thanks,</p><p style=3D"line-height: =
1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr">Andrew.</p><p style=
=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><b=
r></p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" =
dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-si=
ze: 15px; font-weight: bold; white-space: pre-wrap; background-color: trans=
parent;">Precise Per-Type Cyclic Garbage Collection (DRAFT 1)</span></p><br=
><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; f=
ont-weight: bold; white-space: pre-wrap; background-color: transparent;"></=
span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" d=
ir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-siz=
e: 15px; font-weight: bold; white-space: pre-wrap; background-color: transp=
arent;">Introduction / Summary</span></p><br><span style=3D"color: rgb(0, 0=
, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgroun=
d-color: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0p=
t; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); fon=
t-family: Arial; font-size: 15px; white-space: pre-wrap; background-color: =
transparent;">We propose a core language feature that allows objects of use=
r-selected class types to be cyclically garbage collected. &nbsp;Constraint=
s on the usage of class types so selected, and pointers to such class types=
, are imposed to enable the implementation of fast safe precise collection.=
</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font=
-size: 15px; white-space: pre-wrap; background-color: transparent;"></span>=
<p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D=
"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15=
px; font-weight: bold; white-space: pre-wrap; background-color: transparent=
;">Motivation</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family=
: Arial; font-size: 15px; white-space: pre-wrap; background-color: transpar=
ent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom:=
 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; =
font-size: 15px; white-space: pre-wrap; background-color: transparent;">Man=
y C++ programs can be decomposed into (a) low-level components for which th=
e performance and timing control of manual memory management and value layo=
ut are of great benefit; and (b) higher-level organizational components for=
 which the benefit is dominated and negligble - and the convenience of safe=
 automatic cyclic garbage collection would be worth the tradeoff.</span></p=
><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15p=
x; white-space: pre-wrap; background-color: transparent;"></span><p style=
=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><s=
pan style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; whit=
e-space: pre-wrap; background-color: transparent;">It would be great to be =
able to get the best of both worlds in one program. &nbsp;That is, to be ab=
le to specify certain classes as being garbage collected and others to be m=
anually managed - and to only pay for what you use.</span></p><br><span sty=
le=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space=
: pre-wrap; background-color: transparent;"></span><p style=3D"line-height:=
 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"col=
or: rgb(0, 0, 0); font-family: Arial; font-size: 15px; font-weight: bold; w=
hite-space: pre-wrap; background-color: transparent;">Comparison</span></p>=
<br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px=
; white-space: pre-wrap; background-color: transparent;"></span><p style=3D=
"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span=
 style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; font-we=
ight: bold; white-space: pre-wrap; background-color: transparent;">With Boe=
hm Demers Weiser Collector</span></p><br><span style=3D"color: rgb(0, 0, 0)=
; font-family: Arial; font-size: 15px; white-space: pre-wrap; background-co=
lor: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; m=
argin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-fa=
mily: Arial; font-size: 15px; white-space: pre-wrap; background-color: tran=
sparent;">The Boehm Collector can only be used either program-wide or not-a=
t-all. &nbsp;What we propose isolates garbage collection only to certain us=
er-selected types. &nbsp;Also, what we propose is </span><span style=3D"col=
or: rgb(0, 0, 0); font-family: Arial; font-size: 15px; font-style: italic; =
white-space: pre-wrap; background-color: transparent;">precise</span><span =
style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-sp=
ace: pre-wrap; background-color: transparent;"> garbage collection like in =
the managed languages, as opposed to </span><span style=3D"color: rgb(0, 0,=
 0); font-family: Arial; font-size: 15px; font-style: italic; white-space: =
pre-wrap; background-color: transparent;">conservative</span><span style=3D=
"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre=
-wrap; background-color: transparent;"> collection. &nbsp;The reachability =
graph is tracked explicitly through instrumenting the type system. &nbsp;Th=
at is, rather than scanning entire memory areas for all potential pointers =
to any dynamic memory, only the pointers to collected types are tracked - a=
nd they are tracked as they are initialized, assigned and destroyed. &nbsp;=
This gives it a radically different performance profile, and makes it propo=
rtional only to the use of collected types in the program, and not proporti=
onal to all dynamic memory use.</span></p><br><span style=3D"color: rgb(0, =
0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgrou=
nd-color: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0=
pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); fo=
nt-family: Arial; font-size: 15px; font-weight: bold; white-space: pre-wrap=
; background-color: transparent;">With shared_ptr&lt;T&gt;</span></p><br><s=
pan style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; whit=
e-space: pre-wrap; background-color: transparent;"></span><p style=3D"line-=
height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=
=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: =
pre-wrap; background-color: transparent;">Shared pointers cannot deal with =
cycles. &nbsp;weak_ptr often does not have a sensible place where it can be=
 applied to break cycles, and when it does it is awkward to use. &nbsp;Shar=
ed pointer are also awkward to use with this through enable_shared_from_thi=
s. &nbsp;What we propose is much cleaner and easier to use, at the cost of =
the added implementation complexity of compiler support. &nbsp;Under the pr=
oposed feature, the user can just use regular pointer syntax to work with c=
ollected types, and doesn=E2=80=99t need to worry about any of these issues=
..</span><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: =
15px; font-weight: bold; white-space: pre-wrap; background-color: transpare=
nt;"></span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial;=
 font-size: 15px; white-space: pre-wrap; background-color: transparent;"></=
span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" d=
ir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-siz=
e: 15px; font-weight: bold; white-space: pre-wrap; background-color: transp=
arent;">With ownership and memory pools</span></p><br><span style=3D"color:=
 rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; =
background-color: transparent;"></span><p style=3D"line-height: 1.15; margi=
n-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0=
, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgroun=
d-color: transparent;">Ownership schemes are many times artificial. &nbsp;I=
n many object models, objects do not have natural owners, and it can be cha=
llenging to impose one. &nbsp;When an owner is selected the programmer must=
 be careful to make sure the lifetime of the owner encloses uses of the own=
ed object. &nbsp;This implementation overhead and constraint is many times =
not worth the effort compared to automatic memory management.</span></p><br=
><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; w=
hite-space: pre-wrap; background-color: transparent;"></span><p style=3D"li=
ne-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span st=
yle=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-spac=
e: pre-wrap; background-color: transparent;">Memory pools, which are just a=
rtificial owners, are not feasible in many long-running programs. &nbsp;In =
many such programs the memory pool can never be cleared, so they are no dif=
ferent than simply leaking into the heap and waste and exhaust memory.</spa=
n></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size=
: 15px; white-space: pre-wrap; background-color: transparent;"></span><p st=
yle=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"=
><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; f=
ont-weight: bold; white-space: pre-wrap; background-color: transparent;">Sp=
ecification</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: =
Arial; font-size: 15px; white-space: pre-wrap; background-color: transparen=
t;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0=
pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; fo=
nt-size: 15px; white-space: pre-wrap; background-color: transparent;">Intro=
duce a context-sensitive keyword </span><span style=3D"color: rgb(0, 0, 0);=
 font-family: Arial; font-size: 15px; font-weight: bold; white-space: pre-w=
rap; background-color: transparent;">gc</span><span style=3D"color: rgb(0, =
0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgrou=
nd-color: transparent;"> that can appear in the head of a class specifier:<=
/span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-=
size: 15px; white-space: pre-wrap; background-color: transparent;"></span><=
p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"=
ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courier New"; font-s=
ize: 15px; white-space: pre-wrap; background-color: transparent;'> &nbsp;&n=
bsp;&nbsp;class foo gc</span></p><p style=3D"line-height: 1.15; margin-top:=
 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); =
font-family: "Courier New"; font-size: 15px; white-space: pre-wrap; backgro=
und-color: transparent;'> &nbsp;&nbsp;&nbsp;{</span></p><p style=3D"line-he=
ight: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=
=3D'color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; white=
-space: pre-wrap; background-color: transparent;'> &nbsp;&nbsp;&nbsp;&nbsp;=
&nbsp;&nbsp;&nbsp;...</span></p><p style=3D"line-height: 1.15; margin-top: =
0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); f=
ont-family: "Courier New"; font-size: 15px; white-space: pre-wrap; backgrou=
nd-color: transparent;'> &nbsp;&nbsp;&nbsp;};</span></p><br><span style=3D"=
color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-=
wrap; background-color: transparent;"></span><p style=3D"line-height: 1.15;=
 margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rg=
b(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; bac=
kground-color: transparent;">If a class type is marked with gc, it is calle=
d a </span><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-siz=
e: 15px; font-style: italic; white-space: pre-wrap; background-color: trans=
parent;">collected type</span><span style=3D"color: rgb(0, 0, 0); font-fami=
ly: Arial; font-size: 15px; white-space: pre-wrap; background-color: transp=
arent;">. &nbsp;A subclass of a collected type is also a collected type, wh=
ether or not marked with gc. &nbsp;A collected type may not have any base c=
lasses that are not also collected types. &nbsp;It follows that all base cl=
asses and all subclasses of a collected type are collected types.</span></p=
><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15p=
x; white-space: pre-wrap; background-color: transparent;"></span><p style=
=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><s=
pan style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; whit=
e-space: pre-wrap; background-color: transparent;">An object of collected t=
ype is called a collected object. A collected object may only be a complete=
 object or a base class subobject, it may not be a member subobject or an a=
rray element:</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family=
: Arial; font-size: 15px; white-space: pre-wrap; background-color: transpar=
ent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom:=
 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courie=
r New"; font-size: 15px; white-space: pre-wrap; background-color: transpare=
nt;'> &nbsp;&nbsp;&nbsp;foo x[10]; // ill-formed</span></p><p style=3D"line=
-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span styl=
e=3D'color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; whit=
e-space: pre-wrap; background-color: transparent;'> &nbsp;&nbsp;&nbsp;struc=
t bar { foo x; } // ill-formed</span></p><br><span style=3D"color: rgb(0, 0=
, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; backgroun=
d-color: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0p=
t; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); fon=
t-family: Arial; font-size: 15px; white-space: pre-wrap; background-color: =
transparent;">You can use pointers instead:</span></p><br><span style=3D"co=
lor: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wr=
ap; background-color: transparent;"></span><p style=3D"line-height: 1.15; m=
argin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(=
0, 0, 0); font-family: "Courier New"; font-size: 15px; white-space: pre-wra=
p; background-color: transparent;'> &nbsp;&nbsp;&nbsp;foo* x[10]; // ok</sp=
an></p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;"=
 dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courier New"=
; font-size: 15px; white-space: pre-wrap; background-color: transparent;'> =
&nbsp;&nbsp;&nbsp;struct bar { foo* x; } // ok</span></p><p style=3D"line-h=
eight: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=
=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: =
pre-wrap; background-color: transparent;"> &nbsp;</span></p><p style=3D"lin=
e-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span sty=
le=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space=
: pre-wrap; background-color: transparent;">A collected type may only be al=
located with dynamic storage duration. &nbsp;It may not be allocated with a=
utomatic, static or thread local storage duration. &nbsp;Again, you can use=
 pointers instead:</span></p><br><span style=3D"color: rgb(0, 0, 0); font-f=
amily: Arial; font-size: 15px; white-space: pre-wrap; background-color: tra=
nsparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bo=
ttom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "C=
ourier New"; font-size: 15px; white-space: pre-wrap; background-color: tran=
sparent;'> &nbsp;&nbsp;&nbsp;auto s =3D new foo;</span></p><br><span style=
=3D'color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; white=
-space: pre-wrap; background-color: transparent;'></span><p style=3D"line-h=
eight: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=
=3D'color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px; white=
-space: pre-wrap; background-color: transparent;'> &nbsp;&nbsp;&nbsp;thread=
_local auto t =3D new foo;</span></p><br><span style=3D'color: rgb(0, 0, 0)=
; font-family: "Courier New"; font-size: 15px; white-space: pre-wrap; backg=
round-color: transparent;'></span><p style=3D"line-height: 1.15; margin-top=
: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0);=
 font-family: "Courier New"; font-size: 15px; white-space: pre-wrap; backgr=
ound-color: transparent;'> &nbsp;&nbsp;&nbsp;void f()</span></p><p style=3D=
"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span=
 style=3D'color: rgb(0, 0, 0); font-family: "Courier New"; font-size: 15px;=
 white-space: pre-wrap; background-color: transparent;'> &nbsp;&nbsp;&nbsp;=
{</span></p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: =
0pt;" dir=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courier=
 New"; font-size: 15px; white-space: pre-wrap; background-color: transparen=
t;'> &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;auto a =3D new foo;</span></=
p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=
=3D"ltr"><span style=3D'color: rgb(0, 0, 0); font-family: "Courier New"; fo=
nt-size: 15px; white-space: pre-wrap; background-color: transparent;'> &nbs=
p;&nbsp;&nbsp;}</span></p><br><span style=3D"color: rgb(0, 0, 0); font-fami=
ly: Arial; font-size: 15px; white-space: pre-wrap; background-color: transp=
arent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-botto=
m: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial=
; font-size: 15px; white-space: pre-wrap; background-color: transparent;">A=
n object of type pointer to a collected type, is called a collecting pointe=
r. &nbsp;A collecting pointer cannot participate in pointer arithmetic. &nb=
sp;That is, there is no builtin meaning for addition, subtraction, incremen=
t or decrement of a collected pointer. &nbsp;It may also not be converted o=
r cast to or from void*, and it may not be the subject or result of a reint=
erpret cast. &nbsp;It may only be initialized or assigned a null pointer co=
nstant or another collected pointer (possibly dynamic or static cast from a=
 base class or subclass).</span></p><br><span style=3D"color: rgb(0, 0, 0);=
 font-family: Arial; font-size: 15px; white-space: pre-wrap; background-col=
or: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; ma=
rgin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-fam=
ily: Arial; font-size: 15px; white-space: pre-wrap; background-color: trans=
parent;">If a complete collected object is destroyed, any pointers to it or=
 its base class subobjects are assigned the null pointer value by the imple=
mentation.</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: A=
rial; font-size: 15px; white-space: pre-wrap; background-color: transparent=
;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0p=
t;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; fon=
t-size: 15px; white-space: pre-wrap; background-color: transparent;">Given =
a time point at run-time of the program, we will describe a directed graph =
as follows. &nbsp;There is a root node. &nbsp;For each complete object of c=
ollected type there is a node. &nbsp;For each non-null collecting pointer t=
hat is not a member subobject of an object of collected type, there is an e=
dge from the root node to the complete object of the subject of the pointer=
.. &nbsp;For each remaining non-null collecting pointer, there is an edge fr=
om the collected object of which it is a member to the complete object that=
 is the subject of the pointer. &nbsp;If there is no path from the root nod=
e to a collected objects node, we say the collected object is unreachable.<=
/span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-=
size: 15px; white-space: pre-wrap; background-color: transparent;"></span><=
p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"=
ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15p=
x; white-space: pre-wrap; background-color: transparent;">The implementatio=
n shall automatically destroy collected objects, at some point between when=
 it first was unreachable and the end of the program, or at the end of the =
program if they never become unreachable. &nbsp;(As a quality of implementa=
tion issue this should be as soon as reasonably possible given reasonable r=
esources.)</span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: A=
rial; font-size: 15px; white-space: pre-wrap; background-color: transparent=
;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0p=
t;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; fon=
t-size: 15px; font-weight: bold; white-space: pre-wrap; background-color: t=
ransparent;">Implementation</span></p><br><span style=3D"color: rgb(0, 0, 0=
); font-family: Arial; font-size: 15px; white-space: pre-wrap; background-c=
olor: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; =
margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-f=
amily: Arial; font-size: 15px; white-space: pre-wrap; background-color: tra=
nsparent;">If a program contains a collected type, a garbage collector is l=
inked into the program by the implementation. The constructor and destructo=
r of both collected types and collecting pointers are generated to talk to =
the garbage collector. &nbsp;&nbsp;The garbage collector uses this informat=
ion to track the graph. &nbsp;Periodically the garbage collector searches t=
he graph using a generational or other garbage collection algorithm, deleti=
ng objects as appropriate.</span></p><br><span style=3D"color: rgb(0, 0, 0)=
; font-family: Arial; font-size: 15px; white-space: pre-wrap; background-co=
lor: transparent;"></span><p style=3D"line-height: 1.15; margin-top: 0pt; m=
argin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-fa=
mily: Arial; font-size: 15px; font-weight: bold; white-space: pre-wrap; bac=
kground-color: transparent;">Outstanding Issues</span></p><br><span style=
=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: =
pre-wrap; background-color: transparent;"></span><p style=3D"line-height: 1=
..15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr"><span style=3D"color=
: rgb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap;=
 background-color: transparent;">How do references to collected types work?=
 &nbsp;References are much like constrained pointers so the specification o=
f a reference to collected type would be similar to collecting pointers.</s=
pan></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-si=
ze: 15px; white-space: pre-wrap; background-color: transparent;"></span><p =
style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"lt=
r"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px;=
 white-space: pre-wrap; background-color: transparent;">Are the restriction=
s on storage duration necessary? &nbsp;Couldn=E2=80=99t collected objects o=
f non-dynamic storage duration simply be ignored by the collector? &nbsp;Wh=
at about the subobject restriction? &nbsp;It was initially felt that this w=
ould simplify usage and make it safer - as well as easing implementation.</=
span></p><br><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-s=
ize: 15px; white-space: pre-wrap; background-color: transparent;"></span><p=
 style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"l=
tr"><span style=3D"color: rgb(0, 0, 0); font-family: Arial; font-size: 15px=
; white-space: pre-wrap; background-color: transparent;">Is the assignment =
of null to pointers on delete necessary or helpful? &nbsp;Again this was a =
safety feature. &nbsp;We wanted collecting pointers if non-null to always b=
e pointing to a collected object. &nbsp;If they are deleted manually, which=
 would be unusual - we thought this would be because of destructor timing, =
and not resources - given that the performance profile of these high-level =
objects is most likely not paramount.</span></p><br><span style=3D"color: r=
gb(0, 0, 0); font-family: Arial; font-size: 15px; white-space: pre-wrap; ba=
ckground-color: transparent;"></span></span><div><span><br></span></div></d=
iv></blockquote></div>

<p></p>

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

------=_Part_1134_24666029.1392150367173--

.

------=_Part_5277_9488548.1392175665195
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 11, 2014 9:26:07 PM UTC+1, Dain Bray wrote:
>
> What you are describing sounds similar to the way C++/CLI added managed
> classes. If you are not familiar with it, you might check that out.
>
I am familiar, thanks.  It is similar in part, but has different goals.
 What Microsoft was trying to do was modify C++ so it could run on their VM
and so use their VM libraries.  A small part of that was precise garbage
collection.  What we are proposing here is some minimal clean additions
purely to enable adding a precise garbage collector for a subset of
user-nominated types.

Perhaps this would be better as a library solution?


shared_ptr is basically as good as it gets as a pure library solution, and
I compare the differences in the proposal.  In any case, something as
heavily-demanded as real garbage collection warrants core language
additions if needed - and I think the "only pay for what you use" property
of my proposal is the right approach.

--

---
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/.

------=_Part_5277_9488548.1392175665195
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 11, 2014 9:26:07 PM UTC+1, Dain Bray =
wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8=
ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><p>What=
 you are describing sounds similar to the way C++/CLI added managed classes=
.. If you are not familiar with it, you might check that out.</p></div></blo=
ckquote><div>I am familiar, thanks. &nbsp;It is similar in part, but has di=
fferent goals. &nbsp;What Microsoft was trying to do was modify C++ so it c=
ould run on their VM and so use their VM libraries. &nbsp;A small part of t=
hat was precise garbage collection. &nbsp;What we are proposing here is som=
e minimal clean additions purely to enable adding a precise garbage collect=
or for a subset of user-nominated types.</div><div><br></div><blockquote cl=
ass=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; border-left-width: =
1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; paddi=
ng-left: 1ex;">Perhaps this would be better as a library solution?</blockqu=
ote><div><br></div><div>shared_ptr is basically as good as it gets as a pur=
e library solution, and I compare the differences in the proposal. &nbsp;In=
 any case, something as heavily-demanded as real garbage collection warrant=
s core language additions if needed - and I think the "only pay for what yo=
u use" property of my proposal is the right approach.<br></div><div><br></d=
iv></div>

<p></p>

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

------=_Part_5277_9488548.1392175665195--

.

------=_Part_1135_33494494.1392179817284
Content-Type: text/plain; charset=UTF-8

On Tuesday, February 11, 2014 8:54:42 PM UTC+1, Matthew Woehlke wrote:
>
> On 2014-02-11 14:13, xavi wrote:
> > My main concern is whether a language extension is really necessary or
> it
> > could be implemented as a library.
>
> I believe there are already libraries in the wild that do this. IIRC,
> VTK (http://vtk.org) is one...
>

Like in many of the native extension environments of managed languages and
scripting languages, the VTK garbage collector works with the same general
architecture as the proposal - however to register the outbound-side of
edges you need to manually call a register function for each member
collecting pointer that a collected type contains.  From this information
the full graph is formed.

It should be clear that such a system as a pure library solution is
extremely awkward to use and unsafe.  Under the proposal, this graph
tracking is instrumented automatically by the compiler.  Given the
extremely high demand for this feature, it should be clear that a core
language addition is warranted.  If unconvinced by ease of use, than you
should be at least be convinced by the compile-time safety aspect.

--

---
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/.

------=_Part_1135_33494494.1392179817284
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Tuesday, February 11, 2014 8:54:42 PM UTC+1, Matthew Wo=
ehlke wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-lef=
t: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;">On 2014-02-11 14:1=
3, xavi wrote:
<br>&gt; My main concern is whether a language extension is really necessar=
y or it
<br>&gt; could be implemented as a library.
<br>
<br>I believe there are already libraries in the wild that do this. IIRC,=
=20
<br>VTK (<a href=3D"http://vtk.org" target=3D"_blank" onmousedown=3D"this.h=
ref=3D'http://www.google.com/url?q\75http%3A%2F%2Fvtk.org\46sa\75D\46sntz\0=
751\46usg\75AFQjCNEk3HmYVGjTDvXXzRV6ftSAJNe1Mg';return true;" onclick=3D"th=
is.href=3D'http://www.google.com/url?q\75http%3A%2F%2Fvtk.org\46sa\75D\46sn=
tz\0751\46usg\75AFQjCNEk3HmYVGjTDvXXzRV6ftSAJNe1Mg';return true;">http://vt=
k.org</a>) is one...
<br></blockquote><div><br></div><div>Like in many of the native extension e=
nvironments of managed languages and scripting languages, the VTK garbage c=
ollector works with the same general architecture as the proposal - however=
 to register the outbound-side of edges you need to manually call a registe=
r function for each member collecting pointer that a collected type contain=
s. &nbsp;From this information the full graph is formed.</div><div><br></di=
v><div>It should be clear that such a system as a pure library solution is =
extremely awkward to use and unsafe. &nbsp;Under the proposal, this graph t=
racking is instrumented automatically by the compiler. &nbsp;Given the extr=
emely high demand for this feature, it should be clear that a core language=
 addition is warranted. &nbsp;If unconvinced by ease of use, than you shoul=
d be at least be convinced by the compile-time safety aspect.</div><div><br=
></div></div>

<p></p>

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

------=_Part_1135_33494494.1392179817284--

.

------=_Part_172_8433431.1392284382699
Content-Type: text/plain; charset=UTF-8

On the positive note, I think it's a great idea to introduce optional
garbage collection.
As for the null assignment, it may be a good idea to consider this option.
If you assign null to the pointer than the object that it points to will
obviously be destroyed.
Now, delete: I once was playing with that idea. Imagine, you got a graph or
a database, you wan to delete a node. You use delete and all the nodes
(pointers) that point to it will be assigned null automatically. There is
an issue of timing, of course. You start accessing those nodes during
garbage collection, it's not good.
After delete there should be a forced garbage collection.

On Tuesday, February 11, 2014 2:03:27 PM UTC, Andrew Tomazos wrote:

> Hey guys, this is a design I've been toying with (in the abstract for some
> time actually).  It needs a bunch of work, but I would appreciate your
> feedback on this short draft.  Also, if you are aware of any overlapping
> past proposals that would be great.
>
>
> Thanks,
>
> Andrew.
>
>
> Precise Per-Type Cyclic Garbage Collection (DRAFT 1)
>
>
>

--

---
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/.

------=_Part_172_8433431.1392284382699
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>On the positive note, I think it's a great idea to in=
troduce optional garbage collection.&nbsp; </div><div>As for the null assig=
nment, it may be a good idea to consider this option. If you assign null to=
 the pointer than the object that it points to will obviously be destroyed.=
</div><div>Now, delete: I once was&nbsp;playing with that idea. Imagine, yo=
u got a graph or a database, you wan to delete a node. You&nbsp;use delete =
and all the nodes (pointers) that point to it will be assigned null automat=
ically. There is an issue&nbsp;of timing, of course.&nbsp;You start accessi=
ng those nodes during garbage collection, it's not good.</div><div>After de=
lete there should be a forced garbage collection.<br></div><div>&nbsp;</div=
><div>On Tuesday, February 11, 2014 2:03:27 PM UTC, Andrew Tomazos wrote:</=
div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px 0.8ex; p=
adding-left: 1ex; border-left-color: rgb(204, 204, 204); border-left-width:=
 1px; border-left-style: solid;"><div dir=3D"ltr"><span><p style=3D"line-he=
ight: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr">Hey guys, thi=
s is a design I've been toying with (in the abstract for some time actually=
). &nbsp;It needs a bunch of work, but I would appreciate your feedback on =
this short draft. &nbsp;Also, if you are aware of any overlapping past prop=
osals that would be great.</p><p style=3D"line-height: 1.15; margin-top: 0p=
t; margin-bottom: 0pt;" dir=3D"ltr"><br></p><p style=3D"line-height: 1.15; =
margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr">Thanks,</p><p style=3D"li=
ne-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=3D"ltr">Andrew.<=
/p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bottom: 0pt;" dir=
=3D"ltr"><br></p><p style=3D"line-height: 1.15; margin-top: 0pt; margin-bot=
tom: 0pt;" dir=3D"ltr"><span style=3D"color: rgb(0, 0, 0); font-family: Ari=
al; font-size: 15px; font-weight: bold; white-space: pre-wrap; background-c=
olor: transparent;">Precise Per-Type Cyclic Garbage Collection (DRAFT 1)</s=
pan></p><br></span><div><span><br></span></div></div></blockquote></div>

<p></p>

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

------=_Part_172_8433431.1392284382699--

.

------=_Part_7723_3997256.1392320821080
Content-Type: text/plain; charset=UTF-8

On Thursday, February 13, 2014 1:39:42 AM UTC-8, Mikhail Semenov wrote:
>
> On the positive note, I think it's a great idea to introduce optional
> garbage collection.
> As for the null assignment, it may be a good idea to consider this option.
> If you assign null to the pointer than the object that it points to will
> obviously be destroyed.
> Now, delete: I once was playing with that idea. Imagine, you got a graph
> or a database, you wan to delete a node. You use delete and all the nodes
> (pointers) that point to it will be assigned null automatically. There is
> an issue of timing, of course. You start accessing those nodes during
> garbage collection, it's not good.
> After delete there should be a forced garbage collection.
>

It's not currently feasible to allow deterministic destruction of objects
in a GC'd world without very severe performance consequences in far too
many real-world scenarios.  For larger server/HPC apps, forcing a
collection across many gigabytes of heap spread out in a NUMA architecture
just to delete one object/graph would be non-optimal to the say the least.
 Even a reasonable desktop today can have apps with several or even dozens
of gigabytes of managed objects.  For other devices, GC is often avoided
(at great pain in managed languages; see any discussion on performance in
C# or JavaScript on mobile devices or even desktop-class game development
for a more thorough overview; I'm not interested in rehashing that
discussion) making the need for `delete` on objects in many apps with small
memory working sets relatively moot.  The number of use cases where
`delete` on a GC'd object would not be a severe performance issue is pretty
slim.

--

---
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/.

------=_Part_7723_3997256.1392320821080
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 13, 2014 1:39:42 AM UTC-8, Mikhail S=
emenov wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-le=
ft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr">=
<div>On the positive note, I think it's a great idea to introduce optional =
garbage collection.&nbsp; </div><div>As for the null assignment, it may be =
a good idea to consider this option. If you assign null to the pointer than=
 the object that it points to will obviously be destroyed.</div><div>Now, d=
elete: I once was&nbsp;playing with that idea. Imagine, you got a graph or =
a database, you wan to delete a node. You&nbsp;use delete and all the nodes=
 (pointers) that point to it will be assigned null automatically. There is =
an issue&nbsp;of timing, of course.&nbsp;You start accessing those nodes du=
ring garbage collection, it's not good.</div><div>After delete there should=
 be a forced garbage collection.</div></div></blockquote><div><br></div><di=
v>It's not currently feasible to allow deterministic destruction of objects=
 in a GC'd world without very severe performance consequences in far too ma=
ny real-world scenarios. &nbsp;For larger server/HPC apps, forcing a collec=
tion across many gigabytes of heap spread out in a NUMA architecture just t=
o delete one object/graph would be non-optimal to the say the least. &nbsp;=
Even a reasonable desktop today can have apps with several or even dozens o=
f gigabytes of managed objects. &nbsp;For other devices, GC is often avoide=
d (at great pain in managed languages; see any discussion on performance in=
 C# or JavaScript on mobile devices or even desktop-class game development =
for a more thorough overview; I'm not interested in rehashing that discussi=
on) making the need for `delete` on objects in many apps with small memory =
working sets relatively moot. &nbsp;The number of use cases where `delete` =
on a GC'd object would not be a severe performance issue is pretty slim.</d=
iv></div>

<p></p>

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

------=_Part_7723_3997256.1392320821080--

.

------=_Part_3512_7952254.1392323240420
Content-Type: text/plain; charset=UTF-8

On Thursday, February 13, 2014 8:47:01 PM UTC+1, Sean Middleditch wrote:
>
> On Thursday, February 13, 2014 1:39:42 AM UTC-8, Mikhail Semenov wrote:
>>
>> On the positive note, I think it's a great idea to introduce optional
>> garbage collection.
>> As for the null assignment, it may be a good idea to consider this
>> option. If you assign null to the pointer than the object that it points to
>> will obviously be destroyed.
>> Now, delete: I once was playing with that idea. Imagine, you got a graph
>> or a database, you wan to delete a node. You use delete and all the nodes
>> (pointers) that point to it will be assigned null automatically. There is
>> an issue of timing, of course. You start accessing those nodes during
>> garbage collection, it's not good.
>> After delete there should be a forced garbage collection.
>>
>
> It's not currently feasible to allow deterministic destruction of objects
> in a GC'd world without very severe performance consequences in far too
> many real-world scenarios.  For larger server/HPC apps, forcing a
> collection across many gigabytes of heap spread out in a NUMA architecture
> just to delete one object/graph would be non-optimal to the say the least.
>  Even a reasonable desktop today can have apps with several or even dozens
> of gigabytes of managed objects.  For other devices, GC is often avoided
> (at great pain in managed languages; see any discussion on performance in
> C# or JavaScript on mobile devices or even desktop-class game development
> for a more thorough overview; I'm not interested in rehashing that
> discussion) making the need for `delete` on objects in many apps with small
> memory working sets relatively moot.  The number of use cases where
> `delete` on a GC'd object would not be a severe performance issue is pretty
> slim.
>

Ok, it sounds like the conclusion here is that a delete expression should
be ill-formed on a collecting pointer type.  If you want to delete a
collected object, assign your collecting pointer to nullptr and it will be
destroyed at some non-deterministic point in the future.

--

---
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/.

------=_Part_3512_7952254.1392323240420
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Thursday, February 13, 2014 8:47:01 PM UTC+1, Sean Midd=
leditch wrote:<blockquote class=3D"gmail_quote" style=3D"margin: 0;margin-l=
eft: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"=
>On Thursday, February 13, 2014 1:39:42 AM UTC-8, Mikhail Semenov wrote:<bl=
ockquote class=3D"gmail_quote" style=3D"margin:0;margin-left:0.8ex;border-l=
eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>On the positive =
note, I think it's a great idea to introduce optional garbage collection.&n=
bsp; </div><div>As for the null assignment, it may be a good idea to consid=
er this option. If you assign null to the pointer than the object that it p=
oints to will obviously be destroyed.</div><div>Now, delete: I once was&nbs=
p;playing with that idea. Imagine, you got a graph or a database, you wan t=
o delete a node. You&nbsp;use delete and all the nodes (pointers) that poin=
t to it will be assigned null automatically. There is an issue&nbsp;of timi=
ng, of course.&nbsp;You start accessing those nodes during garbage collecti=
on, it's not good.</div><div>After delete there should be a forced garbage =
collection.</div></div></blockquote><div><br></div><div>It's not currently =
feasible to allow deterministic destruction of objects in a GC'd world with=
out very severe performance consequences in far too many real-world scenari=
os. &nbsp;For larger server/HPC apps, forcing a collection across many giga=
bytes of heap spread out in a NUMA architecture just to delete one object/g=
raph would be non-optimal to the say the least. &nbsp;Even a reasonable des=
ktop today can have apps with several or even dozens of gigabytes of manage=
d objects. &nbsp;For other devices, GC is often avoided (at great pain in m=
anaged languages; see any discussion on performance in C# or JavaScript on =
mobile devices or even desktop-class game development for a more thorough o=
verview; I'm not interested in rehashing that discussion) making the need f=
or `delete` on objects in many apps with small memory working sets relative=
ly moot. &nbsp;The number of use cases where `delete` on a GC'd object woul=
d not be a severe performance issue is pretty slim.</div></div></blockquote=
><div><br></div><div>Ok, it sounds like the conclusion here is that a delet=
e expression should be ill-formed on a collecting pointer type. &nbsp;If yo=
u want to delete a collected object, assign your collecting pointer to null=
ptr and it will be destroyed at some non-deterministic point in the future.=
</div><div><br></div></div>

<p></p>

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

------=_Part_3512_7952254.1392323240420--

.

On 2014-02-13 04:39, Mikhail Semenov wrote:
> You use delete and all the nodes (pointers) that point to it will be
> assigned null automatically.

Isn't this what weak pointers are for?

--
Matthew

--

---
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/.

.

------=_Part_40_21524153.1392326137239
Content-Type: text/plain; charset=UTF-8

How would I organize a cyclic structure with shared/weak pointers? When you
use garbage collection you just use pointers, all pointers own the
structure the point to.
They are all equal.


On Thursday, February 13, 2014 8:28:21 PM UTC, Matthew Woehlke wrote:

> On 2014-02-13 04:39, Mikhail Semenov wrote:
> > You use delete and all the nodes (pointers) that point to it will be
> > assigned null automatically.
>
> Isn't this what weak pointers are for?
>
> --
> Matthew
>
>

--

---
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/.

------=_Part_40_21524153.1392326137239
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>How would I organize a cyclic structure with shared/w=
eak pointers? When you use garbage collection you just use pointers, all po=
inters own the structure the point to.</div><div>They are all equal.</div><=
div><br><br>On Thursday, February 13, 2014 8:28:21 PM UTC, Matthew Woehlke =
wrote:</div><blockquote class=3D"gmail_quote" style=3D"margin: 0px 0px 0px =
0.8ex; padding-left: 1ex; border-left-color: rgb(204, 204, 204); border-lef=
t-width: 1px; border-left-style: solid;">On 2014-02-13 04:39, Mikhail Semen=
ov wrote:
<br>&gt; You use delete and all the nodes (pointers) that point to it will =
be
<br>&gt; assigned null automatically.
<br>
<br>Isn't this what weak pointers are for?
<br>
<br>--=20
<br>Matthew
<br>
<br></blockquote></div>

<p></p>

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

------=_Part_40_21524153.1392326137239--

.

On 2014-02-13 16:15, Mikhail Semenov wrote:
> On Thursday, February 13, 2014 8:28:21 PM UTC, Matthew Woehlke wrote:
>> On 2014-02-13 04:39, Mikhail Semenov wrote:
>>> You use delete and all the nodes (pointers) that point to it will be
>>> assigned null automatically.
>>
>> Isn't this what weak pointers are for?
>
> How would I organize a cyclic structure with shared/weak pointers? When you
> use garbage collection you just use pointers, all pointers own the
> structure the point to.
> They are all equal.

I wasn't talking about std::weak_ptr specifically (which isn't helpful
for this purpose, no). I was talking about the general concept of a weak
pointer, which is a pointer class where each object has a pointer to a
shared instance of the pointer class, which in turn has a pointer the
actual object. So that when you want to delete it, the only place you
need to null a pointer is on the pointer class. (The pointer class
itself is just strongly ref-counted in the usual manner.)

(Hmm... actually a shared_ptr<unique_ptr<T>> might work here... you'd
have to do the double dereference by hand, but you could specialize or
subclass to work around that.)

--
Matthew

--

---
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/.

.

I haven't read the whole thread, but see
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2297.html#cycles
and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2286.pdf

On Tue, Feb 11, 2014 at 6:03 AM, Andrew Tomazos <andrewtomazos@gmail.com> wrote:
> Hey guys, this is a design I've been toying with (in the abstract for some
> time actually).  It needs a bunch of work, but I would appreciate your
> feedback on this short draft.  Also, if you are aware of any overlapping
> past proposals that would be great.
>
>
> Thanks,
>
> Andrew.
>
>
> Precise Per-Type Cyclic Garbage Collection (DRAFT 1)
>
>
> Introduction / Summary
>
>
> We propose a core language feature that allows objects of user-selected
> class types to be cyclically garbage collected.  Constraints on the usage of
> class types so selected, and pointers to such class types, are imposed to
> enable the implementation of fast safe precise collection.
>
>
> Motivation
>
>
> Many C++ programs can be decomposed into (a) low-level components for which
> the performance and timing control of manual memory management and value
> layout are of great benefit; and (b) higher-level organizational components
> for which the benefit is dominated and negligble - and the convenience of
> safe automatic cyclic garbage collection would be worth the tradeoff.
>
>
> It would be great to be able to get the best of both worlds in one program.
> That is, to be able to specify certain classes as being garbage collected
> and others to be manually managed - and to only pay for what you use.
>
>
> Comparison
>
>
> With Boehm Demers Weiser Collector
>
>
> The Boehm Collector can only be used either program-wide or not-at-all.
> What we propose isolates garbage collection only to certain user-selected
> types.  Also, what we propose is precise garbage collection like in the
> managed languages, as opposed to conservative collection.  The reachability
> graph is tracked explicitly through instrumenting the type system.  That is,
> rather than scanning entire memory areas for all potential pointers to any
> dynamic memory, only the pointers to collected types are tracked - and they
> are tracked as they are initialized, assigned and destroyed.  This gives it
> a radically different performance profile, and makes it proportional only to
> the use of collected types in the program, and not proportional to all
> dynamic memory use.
>
>
> With shared_ptr<T>
>
>
> Shared pointers cannot deal with cycles.  weak_ptr often does not have a
> sensible place where it can be applied to break cycles, and when it does it
> is awkward to use.  Shared pointer are also awkward to use with this through
> enable_shared_from_this.  What we propose is much cleaner and easier to use,
> at the cost of the added implementation complexity of compiler support.
> Under the proposed feature, the user can just use regular pointer syntax to
> work with collected types, and doesn't need to worry about any of these
> issues.
>
>
> With ownership and memory pools
>
>
> Ownership schemes are many times artificial.  In many object models, objects
> do not have natural owners, and it can be challenging to impose one.  When
> an owner is selected the programmer must be careful to make sure the
> lifetime of the owner encloses uses of the owned object.  This
> implementation overhead and constraint is many times not worth the effort
> compared to automatic memory management.
>
>
> Memory pools, which are just artificial owners, are not feasible in many
> long-running programs.  In many such programs the memory pool can never be
> cleared, so they are no different than simply leaking into the heap and
> waste and exhaust memory.
>
>
> Specification
>
>
> Introduce a context-sensitive keyword gc that can appear in the head of a
> class specifier:
>
>
>    class foo gc
>
>    {
>
>        ...
>
>    };
>
>
> If a class type is marked with gc, it is called a collected type.  A
> subclass of a collected type is also a collected type, whether or not marked
> with gc.  A collected type may not have any base classes that are not also
> collected types.  It follows that all base classes and all subclasses of a
> collected type are collected types.
>
>
> An object of collected type is called a collected object. A collected object
> may only be a complete object or a base class subobject, it may not be a
> member subobject or an array element:
>
>
>    foo x[10]; // ill-formed
>
>    struct bar { foo x; } // ill-formed
>
>
> You can use pointers instead:
>
>
>    foo* x[10]; // ok
>
>    struct bar { foo* x; } // ok
>
>
>
> A collected type may only be allocated with dynamic storage duration.  It
> may not be allocated with automatic, static or thread local storage
> duration.  Again, you can use pointers instead:
>
>
>    auto s = new foo;
>
>
>    thread_local auto t = new foo;
>
>
>    void f()
>
>    {
>
>        auto a = new foo;
>
>    }
>
>
> An object of type pointer to a collected type, is called a collecting
> pointer.  A collecting pointer cannot participate in pointer arithmetic.
> That is, there is no builtin meaning for addition, subtraction, increment or
> decrement of a collected pointer.  It may also not be converted or cast to
> or from void*, and it may not be the subject or result of a reinterpret
> cast.  It may only be initialized or assigned a null pointer constant or
> another collected pointer (possibly dynamic or static cast from a base class
> or subclass).
>
>
> If a complete collected object is destroyed, any pointers to it or its base
> class subobjects are assigned the null pointer value by the implementation.
>
>
> Given a time point at run-time of the program, we will describe a directed
> graph as follows.  There is a root node.  For each complete object of
> collected type there is a node.  For each non-null collecting pointer that
> is not a member subobject of an object of collected type, there is an edge
> from the root node to the complete object of the subject of the pointer.
> For each remaining non-null collecting pointer, there is an edge from the
> collected object of which it is a member to the complete object that is the
> subject of the pointer.  If there is no path from the root node to a
> collected objects node, we say the collected object is unreachable.
>
>
> The implementation shall automatically destroy collected objects, at some
> point between when it first was unreachable and the end of the program, or
> at the end of the program if they never become unreachable.  (As a quality
> of implementation issue this should be as soon as reasonably possible given
> reasonable resources.)
>
>
> Implementation
>
>
> If a program contains a collected type, a garbage collector is linked into
> the program by the implementation. The constructor and destructor of both
> collected types and collecting pointers are generated to talk to the garbage
> collector.   The garbage collector uses this information to track the graph.
> Periodically the garbage collector searches the graph using a generational
> or other garbage collection algorithm, deleting objects as appropriate.
>
>
> Outstanding Issues
>
>
> How do references to collected types work?  References are much like
> constrained pointers so the specification of a reference to collected type
> would be similar to collecting pointers.
>
>
> Are the restrictions on storage duration necessary?  Couldn't collected
> objects of non-dynamic storage duration simply be ignored by the collector?
> What about the subobject restriction?  It was initially felt that this would
> simplify usage and make it safer - as well as easing implementation.
>
>
> Is the assignment of null to pointers on delete necessary or helpful?  Again
> this was a safety feature.  We wanted collecting pointers if non-null to
> always be pointing to a collected object.  If they are deleted manually,
> which would be unusual - we thought this would be because of destructor
> timing, and not resources - given that the performance profile of these
> high-level objects is most likely not paramount.
>
>
>
> --
>
> ---
> 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/.

--

---
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/.

.

------=_Part_1289_18718676.1392713877457
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

11 Feb 2014 =D0=B3., 18:03:27 UTC+4 Andrew Tomazos:
>
> We propose a core language feature that allows objects of user-selected=
=20
> class types to be cyclically garbage collected.  Constraints on the usage=
=20
> of class types so selected, and pointers to such class types, are imposed=
=20
> to enable the implementation of fast safe precise collection.
>

 I think it, or maybe most part of it, can be implemented as library-only=
=20
solution.
Refer following examples:
http://www.codeproject.com/Articles/912/A-garbage-collection-framework-for-=
C
http://sourceforge.net/projects/smieciuch/

--=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/.

------=_Part_1289_18718676.1392713877457
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">11 Feb 2014&nbsp;=D0=B3., 18:03:27 UTC+4 Andrew Tomazos:<b=
lockquote class=3D"gmail_quote" style=3D"margin: 0;margin-left: 0.8ex;borde=
r-left: 1px #ccc solid;padding-left: 1ex;"><div dir=3D"ltr"><span><p dir=3D=
"ltr" style=3D"line-height:1.15;margin-top:0pt;margin-bottom:0pt"><span sty=
le=3D"font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:tr=
ansparent;font-weight:bold;white-space:pre-wrap"></span></p><span style=3D"=
font-size:15px;font-family:Arial;color:rgb(0,0,0);background-color:transpar=
ent;white-space:pre-wrap"></span><p dir=3D"ltr" style=3D"line-height:1.15;m=
argin-top:0pt;margin-bottom:0pt"><span style=3D"font-size:15px;font-family:=
Arial;color:rgb(0,0,0);background-color:transparent;white-space:pre-wrap">W=
e propose a core language feature that allows objects of user-selected clas=
s types to be cyclically garbage collected. &nbsp;Constraints on the usage =
of class types so selected, and pointers to such class types, are imposed t=
o enable the implementation of fast safe precise collection.</span></p></sp=
an></div></blockquote><div><br>&nbsp;I think it, or maybe most part of it, =
can be implemented as library-only solution.<br>Refer following examples:<b=
r>http://www.codeproject.com/Articles/912/A-garbage-collection-framework-fo=
r-C<br>http://sourceforge.net/projects/smieciuch/<br></div></div>

<p></p>

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

------=_Part_1289_18718676.1392713877457--

.