Re: Future of C++
On Aug 12, 5:19 pm, David Abrahams <d...@boostpro.com> wrote:
Furthermore, the fact that a
class (indirectly) manages a non-memory resource can no longer be an
implementation detail. In fact, that "detail" now needs to ripple
upward through the documentation of all classes that contain such a
resource manager, so clients will know they can't be safely leaked.
This is the exact reverse what happens in GC languages where the fact
that the class need to be manually 'disposed' similarly has to bubble
up.
So
far, nobody has been able to come up with a reasonable coding practice
that avoids this problem.
I am sure the following idea is not new so I am probably overlooking
something. :-) Let's define a new concept "gc class" which can contain
(as members or bases) only other gc classes. Similarly "gc pointers"
are pointers that are only allowed to point to gc classes. A normal
class is allowed to contain gc classes or gc pointers. The gc class
would be forbidden to have a destructor and gc pointer cannot be
deleted. Finally primitive types should be considered gc classes.
Something like:
class gc bar; //gc class forward declaration
class baz;
class gc foo //gc class declaration
{
int i; //correct
bar * pbar; //correct, gc pointer
bar a_bar; //also correct
mutex m; //error: should not compile
baz * pbaz; //correct but implies 'knows about' not 'owns'
public:
foo() //ok, ctor is allowed
{}
~foo() //error, dtors are not allowed
{}
};
foo * pfoo = new foo(); //ok
delete pfoo; //error, cannot delete a gc class
class baz //normal class
{
foo * pfoo; //ok
foo another_foo; //also ok
};
To me it seems to produce a clean model where you can *safely* use
both gc and manual resource management. Of course it requires a change
in the language and will not allow to magically make existing code use
gc. The last 'limitation' is actually a good thing in my view.
--
Eugene
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]