SmartPointer & Inheritance & Explicit Constructors

[=?ISO-8859-1?Q?Erik_Wikstr=F6m?=]

Re: SmartPointer & Inheritance & Explicit Constructors

On 2007-06-17 16:39, Chris Thomasson wrote:

"James Kanze" <james.kanze@gm ail.comwrote in message
news:1182089817 .375371.93150@c 77g2000hse.goog legroups.com...
On Jun 17, 10:56 am, "Chris Thomasson" <cris...@comcas t.netwrote:

"James Kanze" <james.ka...@gm ail.comwrote in message

>

news:1181426365 .332095.42450@m 36g2000hse.goog legroups.com...
On Jun 9, 10:16 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

>

[...]

>
[...]
>

IMHO, C++ simply does not need a GC.

>

>Nor did it need templates, nor exceptions. It's just a tool
>which means less work for the programmer.

>
If GC does make it into the language, imho, it should be optional...

That seems to be a sentiment that the standards committee shares with
you, so never fear.

--
Erik Wikström

[Chris Thomasson]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

"Erik Wikström" <Erik-wikstrom@telia. comwrote in message
news:d9fdi.2359 $ZA.1180@newsb. telia.net...

On 2007-06-17 16:39, Chris Thomasson wrote:

[...]

>If GC does make it into the language, imho, it should be optional...

>
That seems to be a sentiment that the standards committee shares with you,
so never fear.

Good to here!

[Chris Thomasson]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

"Erik Wikström" <Erik-wikstrom@telia. comwrote in message
news:d9fdi.2359 $ZA.1180@newsb. telia.net...

On 2007-06-17 16:39, Chris Thomasson wrote:

>"James Kanze" <james.kanze@gm ail.comwrote in message
>news:118208981 7.375371.93150@ c77g2000hse.goo glegroups.com.. .
>On Jun 17, 10:56 am, "Chris Thomasson" <cris...@comcas t.netwrote:

>"James Kanze" <james.ka...@gm ail.comwrote in message
>news:118142636 5.332095.42450@ m36g2000hse.goo glegroups.com.. .
>On Jun 9, 10:16 am, Gianni Mariani <gi3nos...@mari ani.wswrote:

[...]

>>

>IMHO, C++ simply does not need a GC.

>>

>>Nor did it need templates, nor exceptions. It's just a tool
>>which means less work for the programmer.

>>
>If GC does make it into the language, imho, it should be optional...

>
That seems to be a sentiment that the standards committee shares with you,
so never fear.

Well, I think they have to keep the GC optional. If the force a low-level
systems language to use a GC, then it would not longer be all that
"practical" for __low-level__ operating system design...

[James Kanze]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

On Jun 20, 5:08 am, "Chris Thomasson" <cris...@comcas t.netwrote:

"Erik Wikström" <Erik-wikst...@telia. comwrote in message

[...]

That seems to be a sentiment that the standards committee shares with you,
so never fear.

Well, I think they have to keep the GC optional. If the force a low-level
systems language to use a GC, then it would not longer be all that
"practical" for __low-level__ operating system design...

I think that it's generally agreed that you should be able to
write a garbage collector in C++. Since you obviously can't use
garbage collection to implement the collector (without getting
endless recursion)...

But that's true for a lot of things already: std::vector can't
use std::vector in it's implementation, for example, but can
definitly be written in C++.

With regards to "optional": it depends on what you mean. There
is certainly no movement to force people to use garbage
collection where it isn't appropriate. On the other hand, I do
think that it should be required that a hosted implementation
support it---it's not optional for the implementation.

--
James Kanze (GABI Software, from CAI) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Chris Thomasson]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

"James Kanze" <james.kanze@gm ail.comwrote in message
news:1182333297 .613267.37860@c 77g2000hse.goog legroups.com...
On Jun 20, 5:08 am, "Chris Thomasson" <cris...@comcas t.netwrote:

"Erik Wikström" <Erik-wikst...@telia. comwrote in message

[...]

That seems to be a sentiment that the standards committee shares with
you,
so never fear.

Well, I think they have to keep the GC optional. If the force a
low-level
systems language to use a GC, then it would not longer be all that
"practical" for __low-level__ operating system design...

I think that it's generally agreed that you should be able to
write a garbage collector in C++. Since you obviously can't use
garbage collection to implement the collector (without getting
endless recursion)...

Agreed.

[...]

With regards to "optional": it depends on what you mean. There
is certainly no movement to force people to use garbage
collection where it isn't appropriate.

Okay; that's definitely good news.

On the other hand, I do
think that it should be required that a hosted implementation
support it---it's not optional for the implementation.

Okay. I need a little clarification: Are you saying that any implementation
of the Standard C++ runtime for any architecture must have a full-blown
general-purpose garbage collector built-in it's infrastructure?

[James Kanze]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

On Jun 21, 4:02 pm, "Chris Thomasson" <cris...@comcas t.netwrote:

"James Kanze" <james.ka...@gm ail.comwrote in message
news:1182333297 .613267.37860@c 77g2000hse.goog legroups.com...
On Jun 20, 5:08 am, "Chris Thomasson" <cris...@comcas t.netwrote:

"Erik Wikström" <Erik-wikst...@telia. comwrote in message

[...]

On the other hand, I do
think that it should be required that a hosted implementation
support it---it's not optional for the implementation.

Okay. I need a little clarification: Are you saying that any
implementation of the Standard C++ runtime for any
architecture must have a full-blown general-purpose garbage
collector built-in it's infrastructure?

I'm not sure concerning the latest evolution, but the last I
saw, a hosted implementation would not be conforming if it
wasn't possible to request the use of garbage collection. So
for hosted implementations , yes, although I'm not sure what you
mean by "built-in". It's a set of library components, plus
(probably) some compiler options. If you don't use it, you
shouldn't have to pay for it. (Except, of course, in that it
means that the library files will take up a little more space on
your disk, etc. The total cost will certainly be less than for
std::vector.)

--
James Kanze (GABI Software, from CAI) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Chris Thomasson]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

"James Kanze" <james.kanze@gm ail.comwrote in message
news:1182441600 .787826.313450@ k79g2000hse.goo glegroups.com.. .
On Jun 21, 4:02 pm, "Chris Thomasson" <cris...@comcas t.netwrote:

"James Kanze" <james.ka...@gm ail.comwrote in message
news:1182333297 .613267.37860@c 77g2000hse.goog legroups.com...
On Jun 20, 5:08 am, "Chris Thomasson" <cris...@comcas t.netwrote:

"Erik Wikström" <Erik-wikst...@telia. comwrote in message

[...]

On the other hand, I do
think that it should be required that a hosted implementation
support it---it's not optional for the implementation.

Okay. I need a little clarification: Are you saying that any
implementation of the Standard C++ runtime for any
architecture must have a full-blown general-purpose garbage
collector built-in it's infrastructure?

I'm not sure concerning the latest evolution, but the last I
saw, a hosted implementation would not be conforming if it
wasn't possible to request the use of garbage collection. So
for hosted implementations , yes, although I'm not sure what you
mean by "built-in".

Built-in wrt garbage collector itself being hard-coded into some/all of the
libraries that make up the hosted implementations entire Standard C++
runtime...

It's a set of library components, plus
(probably) some compiler options. If you don't use it, you
shouldn't have to pay for it.

Indeed! ;^)

(Except, of course, in that it
means that the library files will take up a little more space on
your disk, etc. The total cost will certainly be less than for
std::vector.)

Okay. Well, I was just wondering if I would __have to__ create some sort of
"general-purpose" GC and incorporate it into the library(s) which make up
one of my custom C++ runtimes... Seems like your saying that I would have to
do "something" like that. I guess that's okay.

One other question... Would the GC have to be general-purpose? What would
the GC be required to protect? Does it have to track every single piece of
dynamically allocated memory? If I have to protect everything, then I don't
think I could apply some of the neat tricks I have learned over the years...
Well, I think that the GC Specification in the Standard should be "flexible"
enough to at least allow some PDR techniques to be used. For instance, I
think it could be beneficial if the Standard's wording could allow for
something like a "Proxy" Garbage Collector to be used instead of a
full-blown "Convention al" GC.

I am concerned that the GC rules wrt the std will rule out some novel
innovations in the areas of GC techniques/implementations and possible
usage-patterns...


Any thoughts?



_______________ ____
P.S.
------- {

>

http://groups.google.com/group/comp.programming.threads/msg/41f29efe33e7f124

} (brief definition of Proxy GC...)


------- {

>

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/82376b7295e6ce1a

>

http://groups.google.com/group/comp.programming.threads/msg/e59c2dd1afb8e0a3

>

http://groups.google.com/group/comp.programming.threads/msg/c5e8e86dcce00c11

>

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/82376b7295e6ce1a

>

http://groups.google.com/group/comp.programming.threads/browse_frm/thread/b2f751d5dad6c07b

} (brief description of 'PDR')...

[James Kanze]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

On Jun 21, 6:22 pm, "Chris Thomasson" <cris...@comcas t.netwrote:

"James Kanze" <james.ka...@gm ail.comwrote in message

news:1182441600 .787826.313450@ k79g2000hse.goo glegroups.com.. .
On Jun 21, 4:02 pm, "Chris Thomasson" <cris...@comcas t.netwrote:

"James Kanze" <james.ka...@gm ail.comwrote in message
>news:118233329 7.613267.37860@ c77g2000hse.goo glegroups.com.. .
On Jun 20, 5:08 am, "Chris Thomasson" <cris...@comcas t.netwrote:
"Erik Wikström" <Erik-wikst...@telia. comwrote in message
[...]
On the other hand, I do
think that it should be required that a hosted implementation
support it---it's not optional for the implementation.
Okay. I need a little clarification: Are you saying that any
implementation of the Standard C++ runtime for any
architecture must have a full-blown general-purpose garbage
collector built-in it's infrastructure?

I'm not sure concerning the latest evolution, but the last I
saw, a hosted implementation would not be conforming if it
wasn't possible to request the use of garbage collection. So
for hosted implementations , yes, although I'm not sure what you
mean by "built-in".

Built-in wrt garbage collector itself being hard-coded into some/all of the
libraries that make up the hosted implementations entire Standard C++
runtime...

It's still very much in a state of flux, but the last proposal I
saw provided for three cases: code which required garbage
collection, code which couldn't work with it, and code which was
garbage collection neutral. Presumably, the standard libraries,
and most third party libraries, would be designed to fall into
the last category. (Although I suspect that more than a few
implementations would offer two sets of libraries, one of which
required garbage collection, simply because something like
std::basic_stri ng can be made a lot faster if you can count on
garbage collection being present.)

[...]

(Except, of course, in that it
means that the library files will take up a little more space on
your disk, etc. The total cost will certainly be less than for
std::vector.)

Okay. Well, I was just wondering if I would __have to__ create some sort of
"general-purpose" GC and incorporate it into the library(s) which make up
one of my custom C++ runtimes... Seems like your saying that I would haveto
do "something" like that. I guess that's okay.

I'm not sure what you mean here. The obvious goal would be to
make most existing C++ code garbage collection neutral; to
define the requirements such that most existing code met them.
Third party libraries, except in special cases where they do
something funny, will probably automatically be garbage
collection neutral.

>From what little I understand of your work, you'll be much more

affected by the threading definitions which are added to the
standard.

One other question... Would the GC have to be general-purpose? What would
the GC be required to protect? Does it have to track every single piece of
dynamically allocated memory? If I have to protect everything, then I don't
think I could apply some of the neat tricks I have learned over the years....
Well, I think that the GC Specification in the Standard should be "flexible"
enough to at least allow some PDR techniques to be used. For instance, I
think it could be beneficial if the Standard's wording could allow for
something like a "Proxy" Garbage Collector to be used instead of a
full-blown "Convention al" GC.

I am concerned that the GC rules wrt the std will rule out some novel
innovations in the areas of GC techniques/implementations and possible
usage-patterns...

Any thoughts?

The obvious intent is not too. The general philosophy of C++ is
to rule out as little as possible (and it's a philosophy which
has paid off in the long run). The issue is still under active
discussion, however, and it's hard to say exactly what the final
form will be.

--
James Kanze (GABI Software, from CAI) email:james.kan ze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Jerry Coffin]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

In article <1182494075.894 249.69170@k79g2 000hse.googlegr oups.com>,
james.kanze@gma il.com says...

[ ... ]

It's still very much in a state of flux, but the last proposal I
saw provided for three cases: code which required garbage
collection, code which couldn't work with it, and code which was
garbage collection neutral. Presumably, the standard libraries,
and most third party libraries, would be designed to fall into
the last category. (Although I suspect that more than a few
implementations would offer two sets of libraries, one of which
required garbage collection, simply because something like
std::basic_stri ng can be made a lot faster if you can count on
garbage collection being present.)

The most recent draft I've looked at on it is N2287. It fairly
specifically does NOT say you can ever depend on GC being present. The
closest it comes is a note that says [basic.stc.colle ct]:

[ Note: For garbage collected programs, a high quality
hosted implementation should attempt to maximize the
amount of unreachable memory it reclaims. ?end note ]

That's it. There's a lot of language to define things like what
constitutes unreachable memory. When you get down to it, however, a
large part of the idea is that the garbage collection is transparent --
which means it has no externally visible effect on the program.

I know a lot of people really want garbage collection, and I know some
smart people have really put some hard work into it -- but when you get
down to it, trying to specify GC in terms of externally visible,
required behavior is nearly impossible. There's no guarantee that any
allocation will ever succeed, and basically all GC can ever do do is
increase the chance of an allocation succeeding.

Other than that, N2287 adds some mechanisms that attempt to give you
control over whether GC is optional, required, etc. -- but with no clear
definition of what GC really does (and probably none possible) it's
pretty easy for an implementation to "conform" by saying GC is present,
but never providing a real implementation (i.e. GC is simply a NOP).

There are, of course a few real rules to be added -- basically just a
restriction against pointer swizzling, and other such things that
prevent a pointer from being recognized (well, it's not really a
restriction against it -- but the code has undefined behavior if it
attempts to dereference a pointer after it's been unrecognizable for any
period of time).

[ ... ]

The obvious intent is not too. The general philosophy of C++ is
to rule out as little as possible (and it's a philosophy which
has paid off in the long run). The issue is still under active
discussion, however, and it's hard to say exactly what the final
form will be.

At least based on the papers I've looked at so far, very little will be
ruled out in terms of implementation. At least in my view, the problem
is much more that code will be restricted without guaranteeing anything
in return. The only comfort is that the restrictions are pretty trivial.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Chris Thomasson]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

"Jerry Coffin" <jcoffin@taeus. comwrote in message
news:MPG.20e77f 5c7ac5e48798992 3@news.sunsite. dk...
In article <1182494075.894 249.69170@k79g2 000hse.googlegr oups.com>,
james.kanze@gma il.com says...
[...]

It's still very much in a state of flux, but the last proposal I
saw provided for three cases: code which required garbage
collection, code which couldn't work with it, and code which was
garbage collection neutral.

[...]

The most recent draft I've looked at on it is N2287. It fairly
specifically does NOT say you can ever depend on GC being present. The
closest it comes is a note that says [basic.stc.colle ct]:

[ Note: For garbage collected programs, a high quality
hosted implementation should attempt to maximize the
amount of unreachable memory it reclaims. ?end note ]

That's it.

Sound pretty good...

There's a lot of language to define things like what
constitutes unreachable memory.

That's the kind of broad statements I think we need when defining GC, or a
memory model for that matter, in the standard.
[...]

[James Kanze]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

On Jun 24, 4:05 am, Jerry Coffin <jcof...@taeus. comwrote:

In article <1182494075.894 249.69...@k79g2 000hse.googlegr oups.com>,
james.ka...@gma il.com says...

[ ... ]

It's still very much in a state of flux, but the last proposal I
saw provided for three cases: code which required garbage
collection, code which couldn't work with it, and code which was
garbage collection neutral. Presumably, the standard libraries,
and most third party libraries, would be designed to fall into
the last category. (Although I suspect that more than a few
implementations would offer two sets of libraries, one of which
required garbage collection, simply because something like
std::basic_stri ng can be made a lot faster if you can count on
garbage collection being present.)

The most recent draft I've looked at on it is N2287. It fairly
specifically does NOT say you can ever depend on GC being present.

The text from the garbage collection proposals hasn't made
it into the draft yet, at least as far as I can see. For that
matter, I think that the current state of the proposal is far
from final.

I know a lot of people really want garbage collection, and I know some
smart people have really put some hard work into it -- but when you get
down to it, trying to specify GC in terms of externally visible,
required behavior is nearly impossible.

In the same way that trying to specify free() or the operator
delete() function is. (Both can be no-ops in a conforming
implementation, but of course, that is neither the intent, nor
what we expect from a QoI point of view.)

--
James Kanze (Gabi Software) email: james.kanze@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

[Jerry Coffin]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

In article <1182687484.221 235.163760@w5g2 000hsg.googlegr oups.com>,
james.kanze@gma il.com says...

[ ... ]

The most recent draft I've looked at on it is N2287. It fairly
specifically does NOT say you can ever depend on GC being present.

>
The text from the garbage collection proposals hasn't made
it into the draft yet, at least as far as I can see. For that
matter, I think that the current state of the proposal is far
from final.

Sorry -- I didn't mean the draft standard, but the draft garbage
collection proposal...

I know a lot of people really want garbage collection, and I know some
smart people have really put some hard work into it -- but when you get
down to it, trying to specify GC in terms of externally visible,
required behavior is nearly impossible.

>
In the same way that trying to specify free() or the operator
delete() function is. (Both can be no-ops in a conforming
implementation, but of course, that is neither the intent, nor
what we expect from a QoI point of view.)

Right -- the difference being that the lack of definition of free/delete
has relatively little effect on the rest of the standard -- i.e. there's
a few lines devoted to describing what they're intended to do, and
that's it. In the case of GC, however, there's a _lot_ of text devoted
to definding things like what's collectible, what's unreachable, etc.,
-- but in the end, none of it really specifies any requirements.

--
Later,
Jerry.

The universe is a figment of its own imagination.

[Jon Harrop]

Re: SmartPointer &amp; Inheritance &amp; Explicit Constructors

coder_lol@yahoo .com wrote:

Using a refcount smart pointer, can you show me an actual code example
of when a circular dependency is created? Yeah, I figure A->B and B->A,
but I'd appreciate if you could share actual code samples.

Symbolic manipulation, because expressions can refer to each other
arbitrarily. Mathematica is written in a dialect of C and uses reference
counting. Consequently, it leaks.

--
Dr Jon D Harrop, Flying Frog Consultancy
The OCaml Journal

http://www.ffconsultancy.com/products/ocaml_journal/?usenet