Re: SmartPointer & Inheritance & Explicit Constructors
On Jun 21, 6:22 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:1182441600.787826.313450@k79g2000hse.googlegroups.com...
On Jun 21, 4:02 pm, "Chris Thomasson" <cris...@comcast.net> wrote:
"James Kanze" <james.ka...@gmail.com> wrote in message
news:1182333297.613267.37860@c77g2000hse.googlegroups.com...
On Jun 20, 5:08 am, "Chris Thomasson" <cris...@comcast.net> wrote:
"Erik Wikstr=F6m" <Erik-wikst...@telia.com> wrote 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 t=
he
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_string 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 have=
to
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 "flexib=
le"
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 "Conventional" 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.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34