SmartPointer & Inheritance & Explicit Constructors

[coder_lol]

Thanks everyone again for contributing to helping me clear C++
confusions. I did some serious reading on copy constructors and
assignments and I think I've got a good handle on the memory stuff.

Well, I came across Scott Meyer's SmartPtr example from some 10 years
ago. I like the template member function for type conversion to solve
inheritance issues.

On MSVS 2003, I get the below error, if I declare the constructor
SmartPtr(T* realPtr = 0); as explicit, ie.

explicit SmartPtr(T* realPtr = 0);
SmartPtr.h(33): error C2520: SmartPtr<T>::SmartPtr: no non-explicit
constructor available for implicit conversion
with
[
T=Object
]
and
[
T=Object
]
I think of explicit as an "insurance" against silly mistakes. Is
there a way to solve the issue and keep explicit?

Thanks...

=== Scott Meyer's===
template<class T// template class for smart
class SmartPtr { // pointers-to-T objects
public:
SmartPtr(T* realPtr = 0);
T* operator->() const;
T& operator*() const;
template<class newType// template function for
operator SmartPtr<newType>() // implicit conversion ops.
{
return SmartPtr<newType>(pointee);
}

[Jon Harrop]

co*******@yahoo.com wrote:

Well, I came across Scott Meyer's SmartPtr example from some 10 years
ago. I like the template member function for type conversion to solve
inheritance issues.

As smart pointers are a rudimentary precursor of garbage collection, you
might consider a full-blown garbage collector or a garbage collected
language. There is really no need to battle "inheritance issues" any more.

--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/product...ntists/?usenet

[James Kanze]

On May 30, 4:33 pm, Jon Harrop <[e-mail]:

[e-mail] wrote:

Well, I came across Scott Meyer's SmartPtr example from some 10 years
ago. I like the template member function for type conversion to solve
inheritance issues.

As smart pointers are a rudimentary precursor of garbage collection, you
might consider a full-blown garbage collector or a garbage collected
language.

It depends on what the smart pointers are used for. I normally
use the Boehm collector for new projects, but I still use smart
pointers in some cases: to manage locks, for example, or to
manage ownership between threads. In the past, I've also used
them for simplified transaction management, and manually managed
object paging (keeping most of the objects physically on disk,
and not in memory).

Obviously, it's stupid not to use the Boehm collector when you
can, but just as obviously, it's not a silver bullet, and can
only replace those smart pointers which were being used
exclusively for memory management.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Gianni Mariani]

James Kanze wrote:
....

Obviously, it's stupid not to use the Boehm collector when you
can,

I have found that using smart pointers is almost all that is needed to
develop a leak free application. The circular pointers issue is
normally very easy to design around.

... but just as obviously, it's not a silver bullet, and can
only replace those smart pointers which were being used
exclusively for memory management.

[James Kanze]

On Jun 1, 10:29 am, Gianni Mariani <[e-mail]:

James Kanze wrote:

...

Obviously, it's stupid not to use the Boehm collector when you
can,

I have found that using smart pointers is almost all that is needed to
develop a leak free application. The circular pointers issue is
normally very easy to design around.

If you can't implement an application that works without garbage
collection, you won't be able to implement one with. In the old
days, I've even implemented complex applications fully in
assembler.

On the other hand, it's a lot less work if you have the
appropriate tools. Garbage collection reduces the amount of
code I have to write, and so reduces how much it costs to
develop the working application. Given that the Boehm collector
is readily available and easy to use, it would be stupid not to
use it when you can. (I don't use assembler today, either,
unless I have to.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[coder_lol]

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.

Thanks,

On Jun 1, 1:29 am, Gianni Mariani <[e-mail]:

James Kanze wrote:

...

Obviously, it's stupid not to use the Boehm collector when you
can,

I have found that using smart pointers is almost all that is needed to
develop a leak free application. The circular pointers issue is
normally very easy to design around.

... but just as obviously, it's not a silver bullet, and can
only replace those smart pointers which were being used
exclusively for memory management.- Hide quoted text -

- Show quoted text -

[coder_lol]

How well does BOEHM work in an embedded environment? I have to port
substantial amount of J2ME applications to another C/C++ embedded
environment. Based on my study, I figure that RefCount smart pointers
and proper use of assignment operator and copy constructor will
essentially give me the a pseudo Java "reference" / garbage collection
programming model.

I scanned BOEHM briefly and it is very interesting that you don't need
to modify your code to employ it, but how does it work in an embedded
environment esp. single-threaded embedded env.

Thanks...

On Jun 1, 7:11 am, James Kanze <[e-mail]:

On Jun 1, 10:29 am, Gianni Mariani <[e-mail]:

James Kanze wrote:
...

Obviously, it's stupid not to use the Boehm collector when you
can,

I have found that using smart pointers is almost all that is needed to
develop a leak free application. The circular pointers issue is
normally very easy to design around.

If you can't implement an application that works without garbage
collection, you won't be able to implement one with. In the old
days, I've even implemented complex applications fully in
assembler.

On the other hand, it's a lot less work if you have the
appropriate tools. Garbage collection reduces the amount of
code I have to write, and so reduces how much it costs to
develop the working application. Given that the Boehm collector
is readily available and easy to use, it would be stupid not to
use it when you can. (I don't use assembler today, either,
unless I have to.)

--
James Kanze (GABI Software) email:[e-mail]
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Gianni Mariani]

James Kanze wrote:
.... Given that the Boehm collector

is readily available and easy to use, it would be stupid not to
use it ...

Are you meaning to suggest that the Boehm collector will perform without
any issues perfectly every time, no side effects, just peachy even ?

[Gianni Mariani]

co*******@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.

Networks usually are hard to implement because any object can point to
any other object. One of my first applications using reference counted
objects, I had identified that this might happen (seldom but did happen)
and a secondary method to clean up those objects were needed. Objects
were given a lifetime handle and when it was determined that the life of
all the objects of that network were done with, regardless of the
reference count, all the objects removed themselves from the network
which then automatically deleted themselves because their reference
count went to zero. Today I'd consider using a garbage collector on
code like that.

Most of my applications since then have not been anywhere near as
complex from a lifetime management point of view and judicious use of
reference counting smart pointers eliminated all (yes - all) issues with
resource leaks. The most recent project I worked on came to life with
no memory leaks (a few handle leaks tho) to the astonishment of many of
the old timer engrs.

Garbage collection is not free, it can be somewhat expensive in compute
resources. For short lived applications, it may be better since it is
likely that the collector never runs. For long running applications, it
can introduce unwanted timing issues.

I have no used the Bohem collector, I hope it becomes a standard feature
personally but I also would not support it becoming a mandatory
requirement for all C++ code.

[Jon Harrop]

co*******@yahoo.com wrote:

I scanned BOEHM briefly and it is very interesting that you don't need
to modify your code to employ it

You do need to modify your code if you hide pointers (e.g. as ints). Also,
Boehm is unreliable or "conservative". You're much better off using a real
GC.

--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/product...ntists/?usenet

[James Kanze]

On Jun 9, 9:40 am, [e-mail] wrote:

How well does BOEHM work in an embedded environment? I have
to port substantial amount of J2ME applications to another
C/C++ embedded environment. Based on my study, I figure that
RefCount smart pointers and proper use of assignment operator
and copy constructor will essentially give me the a pseudo
Java "reference" / garbage collection programming model.

It depends really on the embedded environment. I'm tempted to
say that it works about as well as ref. counted smart
pointers:-). But that's probably because all of my experience
in embedded environments has been hard real time applications,
where no dynamic memory allocation was allowed.

Generally, the Boehm collector will require more memory than
manually allocating and deleting. (In most cases, to judge from
my experience, it will also be a little bit faster.)

I scanned BOEHM briefly and it is very interesting that you
don't need to modify your code to employ it, but how does it
work in an embedded environment esp. single-threaded embedded
env.

I suspect that there are two elements that you have to consider:
it typically does require more memory than manual allocation,
and if memory is tight, it might not be the ideal solution. And
at least in the configurations I've used, it doesn't give any
hard real time guarantees (but then, neither does malloc/free,
and I've had serious problems with the latency of malloc in the
past).

One final consideration: the Boehm collector has been ported to
Windows and to most mainstream Unix environments. If you're
target machine isn't one of those (and watch out for modified
versions of Linux), then you may have to port it yourself. I've
never done that, but I can imagine that it's not necessarily
trivial.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 9, 9:58 am, Gianni Mariani <[e-mail]:

James Kanze wrote:

... Given that the Boehm collector

is readily available and easy to use, it would be stupid not to
use it ...

Are you meaning to suggest that the Boehm collector will
perform without any issues perfectly every time, no side
effects, just peachy even ?

It's not a silver bullet, if that's what you're asking. On
typical systems to which it has been ported (I've used it under
Solaris and Linux), it works without problems, resulting in
faster programs at less work from the programmer.

I'm not sure what you mean by "side effects", however.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 9, 9:37 am, [e-mail] 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.

A dual linked list. Many tree structures. Any time
bidirectional navigation is required, in fact.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:

Most of my applications since then have not been anywhere near as
complex from a lifetime management point of view and judicious use of
reference counting smart pointers eliminated all (yes - all) issues with
resource leaks. The most recent project I worked on came to life with
no memory leaks (a few handle leaks tho) to the astonishment of many of
the old timer engrs.

I'd say that this is actually fairly typical. The key word
above being "judicious". With garbage collection, there are
many cases where you don't even have to think about it. Doing
it right without garbage collection is far from impossible, but
doing it right with garbage collection is less work.

Garbage collection is not free, it can be somewhat expensive
in compute resources.

Which explains why programs using garbage collection are
typically faster than those without.

For short lived applications, it may be better since it is
likely that the collector never runs. For long running
applications, it can introduce unwanted timing issues.

That depends on the collector used. There are collectors which
give hard real-time guarantees (which malloc and free typically
don't); I've never needed one, however, so I don't know much
more than that they exist. A good incremental collector,
however, will generally not cause any problems, and it's usually
easier to tune the application (by explicitly collecting when
the system is otherwise idle, for example) with a collector than
with manual management. Of course, this depends at least
partially on memory use patterns; programs with lots of small,
short-lived allocations generally run faster with the garbage
collector; programs with very few, very long lived allocations
run slower.

The main cost of the Boehm collector is in total memory usage,
and at least at times, in locality.

I have no used the Bohem collector, I hope it becomes a standard feature
personally but I also would not support it becoming a mandatory
requirement for all C++ code.

There's no proposal for it to be mandatory; it's well recognized
that there are times when it isn't appropriate.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jon Harrop]

James Kanze wrote:

On Jun 9, 9:37 am, [e-mail] 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.

A dual linked list. Many tree structures...

Symbolic expressions, any graph...

Seriously, if you're doing anything non-trivial, use a GC.

--
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/product...ntists/?usenet

[Chris Thomasson]

"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@m36g2000hse.googlegro ups.com...
On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:

[...]

>Garbage collection is not free, it can be somewhat expensive
in compute resources.

Which explains why programs using garbage collection are
typically faster than those without.

What type of garbage collection are you talking about? Some of the methods
used to actually implement most types of "general purpose" garbage
collection are overkill and can have an overall negative effect on
scalability and performance in general. IMHO, C++ simply does not need a GC.

[Chris Thomasson]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@c77g2000hse.googlegr oups.com...
On Jun 9, 9:40 am, [e-mail] wrote:

>How well does BOEHM work in an embedded environment? I have
to port substantial amount of J2ME applications to another
C/C++ embedded environment. Based on my study, I figure that
RefCount smart pointers and proper use of assignment operator
and copy constructor will essentially give me the a pseudo
Java "reference" / garbage collection programming model.

It depends really on the embedded environment. I'm tempted to
say that it works about as well as ref. counted smart
pointers:-).

[...]

I feel the need to point out the fact that you cannot use something like
Boost shared_ptr to implement Java References. Your going to have to use
some sort of PDR scheme instead:

http://groups.google.com/group/comp....376b7295e6ce1a
(origin of term 'PDR'...)
Any solution is going to have to have strong thread-safety characteristics:

http://groups.google.com/group/comp....67941d32340c6/
(difference between basic and normal thread-safety...)
You certainly do not need a full-blown GC to implement Java References in
C++. For instance, you could use full-blown atomic reference counting to
implement something just like Java References in C++:

http://appcore.home.comcast.net/vzoom/refcount/

http://atomic-ptr-plus.sourceforge.net/

Any thoughts?

[Chris Thomasson]

"Chris Thomasson" <cr*****@comcast.netwrote in message
news:QN******************************@comcast.com. ..

>
"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@m36g2000hse.googlegro ups.com...
On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:

[...]

>>Garbage collection is not free, it can be somewhat expensive
in compute resources.

>Which explains why programs using garbage collection are
typically faster than those without.

What type of garbage collection are you talking about? Some of the methods
used to actually implement most types of "general purpose" garbage
collection are overkill

[...]

Well, I guess it would be nice for C++ to offer a "Proxy" Garbage Collector
scheme... That would not be overkill IMO because a proxy garbage collector
can actually be implemented with virtually zero-overheads:

http://appcore.home.comcast.net/vzoom/round-1.pdf
(section 1.1)

http://appcore.home.comcast.net/vzoom/round-2.pdf
(section 1.2)

[Bo Persson]

Chris Thomasson wrote:
:: "James Kanze" <ja*********@gmail.comwrote in message
:: news:11*********************@m36g2000hse.googlegro ups.com...
:: On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:
::
:: [...]
::
:::: Garbage collection is not free, it can be somewhat expensive
:::: in compute resources.
::
::: Which explains why programs using garbage collection are
::: typically faster than those without.
::
:: What type of garbage collection are you talking about? Some of the
:: methods used to actually implement most types of "general purpose"
:: garbage collection are overkill and can have an overall negative
:: effect on scalability and performance in general. IMHO, C++ simply
:: does not need a GC.

Using GC saves on allocation and management. Skip your smart pointers
and reference counting, and you save on both execution time and
programming effort.

If the collector isn't run often (or at all, for typical benchmarks!),
it can be a net saving.
Bo Persson

[Chris Thomasson]

"Bo Persson" <bo*@gmb.dkwrote in message
news:5d*************@mid.individual.net...

Chris Thomasson wrote:
:: "James Kanze" <ja*********@gmail.comwrote in message
:: news:11*********************@m36g2000hse.googlegro ups.com...
:: On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:
::
:: [...]
::
:::: Garbage collection is not free, it can be somewhat expensive
:::: in compute resources.
::
::: Which explains why programs using garbage collection are
::: typically faster than those without.
::
:: What type of garbage collection are you talking about? Some of the
:: methods used to actually implement most types of "general purpose"
:: garbage collection are overkill and can have an overall negative
:: effect on scalability and performance in general. IMHO, C++ simply
:: does not need a GC.

Using GC saves on allocation

What does a general-purpose GC save on allocation in general when compared
to a state-of-the-art memory allocator algorithm:

http://groups.google.com/group/comp....c40d42a04ee855

and management.

Well, yes I agree that GC makes it so a programmer does not really "need" to
hold a firm understanding of the fact that freeing any memory that is not in
a persistent quiescent state is a very, very bad practice...

Skip your smart pointers and reference counting, and you save on both
execution time

This is simply not true in all cases. I can come up with several scaleable
memory management techniques that a traditional GC cannot compete with.
Here's a question: Can a general-purpose GC guarantee that threads will
never be interrupted by it during their entire lifetimes? I know of
special-purpose GC algorithms that can make this guarantee, however, I can't
think of a general-purpose GC one than can...

and programming effort.

Well, yes... But heck, doesn't that take all the fun out of programming?

:^)
Anyway, I am still holding my opinion that C++ Standard should not force a
GC into the mix...

[Chris Thomasson]

[...]

This is simply not true in all cases. I can come up with several scaleable
memory management techniques that a traditional GC cannot compete with.

^^^^^^^^^^^^^^^^^^^^^^^

Some of the techniques can include special forms of reference counting.

[...]
I guess we should discuss some possible methods that can be used to reduce
the overhead in general-purpose garbage collectors. Any clever ideas?

;^)
Here are just a few of mine:

_____________________

http://groups.google.com/group/comp....007ffdf246d50e
(read whole thread...)
http://groups.google.com/group/comp....c9c2673682d4cf
http://appft1.uspto.gov/netacgi/nph-...DN/20070067770
(a possible technique for a GC to use...)

_____________________
:^)

[Chris Thomasson]

"Gianni Mariani" <gi*******@mariani.wswrote in message
news:46***********************@per-qv1-newsreader-01.iinet.net.au...

James Kanze wrote:
...

>Obviously, it's stupid not to use the Boehm collector when you
can,

I have found that using smart pointers is almost all that is needed to
develop a leak free application.

Well, actually, nothing special is really "needed" to develop a leak-free
application... We all know that we can create leak-free programs by using
patience and discipline when designing their memory management techniques.

The circular pointers issue is normally very easy to design around.

Agreed.

[Chris Thomasson]

"Bo Persson" <bo*@gmb.dkwrote in message
news:5d*************@mid.individual.net...

Chris Thomasson wrote:
:: "James Kanze" <ja*********@gmail.comwrote in message
:: news:11*********************@m36g2000hse.googlegro ups.com...
:: On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:
::
:: [...]

[...]

If the collector isn't run often (or at all, for typical benchmarks!), it
can be a net saving.

The collector can run quite often in certain scenarios... Its not really
something that can be predicted...

[Chris Thomasson]

"Jon Harrop" <jo*@ffconsultancy.comwrote in message
news:46**********************@ptn-nntp-reader02.plus.net...

co*******@yahoo.com wrote:

>Well, I came across Scott Meyer's SmartPtr example from some 10 years
ago. I like the template member function for type conversion to solve
inheritance issues.

As smart pointers are a rudimentary precursor of garbage collection, you
might consider a full-blown garbage collector or a garbage collected
language. There is really no need to battle "inheritance issues" any more.

"Sometimes" you will need to use a reference counting smart-pointer even if
your using GC. Here is a quick example of such a scenario:

http://groups.google.com/group/comp....c58e3e1d902aec

Any thoughts?

[Chris Thomasson]

"Jon Harrop" <jo*@ffconsultancy.comwrote in message
news:46**********************@ptn-nntp-reader02.plus.net...

James Kanze wrote:

>On Jun 9, 9:37 am, [e-mail] 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.

A dual linked list. Many tree structures...

Symbolic expressions, any graph...

Seriously, if you're doing anything non-trivial, use a GC.

If you think you need a GC, then use a GC... The truth is that a GC is never
required for anything... Think about it? Can you give me an example of where
a GC is simply required to implement a particular algorithm?

GC is a convenience IMHO... If somebody thinks they "need" a GC to make
their programs correct, then perhaps programming is not one of their strong
points?

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

On 2007-06-17 13:19, Chris Thomasson wrote:

"Jon Harrop" <jo*@ffconsultancy.comwrote in message
news:46**********************@ptn-nntp-reader02.plus.net...

>James Kanze wrote:

>>On Jun 9, 9:37 am, [e-mail] 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.

A dual linked list. Many tree structures...

Symbolic expressions, any graph...

Seriously, if you're doing anything non-trivial, use a GC.

If you think you need a GC, then use a GC... The truth is that a GC is never
required for anything... Think about it? Can you give me an example of where
a GC is simply required to implement a particular algorithm?

GC is a convenience IMHO... If somebody thinks they "need" a GC to make
their programs correct, then perhaps programming is not one of their strong
points?

Or they've never learned to use anything else (like someone who started
with Java). The really interesting question (IMO) is whether one can
write all programs without using dynamically allocated memory except in
a few well understood and encapsulated places (like the standard
containers). Personally I seldom use dynamic memory/pointers in my
programs, so I don't really see what GC would give me.

--
Erik Wikström

[Chris Thomasson]

"Erik Wikström" <Er***********@telia.comwrote in message
news:Dc****************@newsb.telia.net...

On 2007-06-17 13:19, Chris Thomasson wrote:

>"Jon Harrop" <jo*@ffconsultancy.comwrote in message
news:46**********************@ptn-nntp-reader02.plus.net...

>>James Kanze wrote:
On Jun 9, 9:37 am, [e-mail] 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.

A dual linked list. Many tree structures...

Symbolic expressions, any graph...

Seriously, if you're doing anything non-trivial, use a GC.

If you think you need a GC, then use a GC... The truth is that a GC is
never required for anything... Think about it? Can you give me an example
of where a GC is simply required to implement a particular algorithm?

GC is a convenience IMHO... If somebody thinks they "need" a GC to make
their programs correct, then perhaps programming is not one of their
strong points?

Or they've never learned to use anything else (like someone who started
with Java).

Good point.

The really interesting question (IMO) is whether one can write all
programs without using dynamically allocated memory except in a few well
understood and encapsulated places (like the standard containers).

I think disciplined use of dynamic allocation in the way you describe is
just evidence of a good overall design of your applications memory
management scheme(s)... IMHO at least...

;^)

Personally I seldom use dynamic memory/pointers in my programs, so I don't
really see what GC would give me.

I think GC would just add extra unwanted overhead to your programs... IMHO,
this is one of the reasons why GC should not be "forced" into the C++
Standard...

[James Kanze]

On Jun 17, 10:56 am, "Chris Thomasson" <[e-mail]:

"James Kanze" <[e-mail] in message

news:11*********************@m36g2000hse.googlegro ups.com...
On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:

[...]

Garbage collection is not free, it can be somewhat expensive
in compute resources.

Which explains why programs using garbage collection are
typically faster than those without.

What type of garbage collection are you talking about?

The Boehm collector.

Some of the methods
used to actually implement most types of "general purpose" garbage
collection are overkill and can have an overall negative effect on
scalability and performance in general.

You can always find exceptions. I said generally.

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.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[James Kanze]

On Jun 17, 12:13 pm, "Bo Persson" <[e-mail]:

Chris Thomasson wrote:

[...]

If the collector isn't run often (or at all, for typical benchmarks!),
it can be a net saving.

A benchmark in which the garbage collector never runs isn't very
convincing. It's easy, however, to construct special cases
where garbage collection is significantly faster than manual
memory management. Or significantly slower, if that's what
you're trying to prove. Never trust any benchmark you haven't
falsified yourself.

Globally, I find that for a large number of real applications,
using garbage collection results in slightly better performance.
Nothing to get excited about, but since it comes with
significantly less work for the programmer, it would be a shame
not to use it.

It would be just as wrong, however, to think that garbage
collection is a silver bullet, and that it will solve all of
your problems, or even that it is appropriate everywhere.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Chris Thomasson]

"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@c77g2000hse.googlegro ups.com...
On Jun 17, 10:56 am, "Chris Thomasson" <[e-mail]:

"James Kanze" <[e-mail] in message

news:11*********************@m36g2000hse.googlegro ups.com...
On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:

[...]

[...]

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

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

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

"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@c77g2000hse.googlegro ups.com...
On Jun 17, 10:56 am, "Chris Thomasson" <[e-mail]:

"James Kanze" <[e-mail] in message

news:11*********************@m36g2000hse.googlegro ups.com...
On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:

[...]

[...]

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]

"Erik Wikström" <Er***********@telia.comwrote in message
news:d9****************@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]

"Erik Wikström" <Er***********@telia.comwrote in message
news:d9****************@newsb.telia.net...

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

>"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@c77g2000hse.googlegr oups.com...
On Jun 17, 10:56 am, "Chris Thomasson" <[e-mail]:

>"James Kanze" <[e-mail] in message
news:11*********************@m36g2000hse.googlegr oups.com...
On Jun 9, 10:16 am, Gianni Mariani <[e-mail]:

[...]

>>

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

On Jun 20, 5:08 am, "Chris Thomasson" <[e-mail]:

"Erik Wikström" <[e-mail] 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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Chris Thomasson]

"James Kanze" <ja*********@gmail.comwrote in message
news:11*********************@c77g2000hse.googlegro ups.com...
On Jun 20, 5:08 am, "Chris Thomasson" <[e-mail]:

"Erik Wikström" <[e-mail] 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]

On Jun 21, 4:02 pm, "Chris Thomasson" <[e-mail]:

"James Kanze" <[e-mail] in message
news:11*********************@c77g2000hse.googlegro ups.com...
On Jun 20, 5:08 am, "Chris Thomasson" <[e-mail]:

"Erik Wikström" <[e-mail] 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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Chris Thomasson]

"James Kanze" <ja*********@gmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...
On Jun 21, 4:02 pm, "Chris Thomasson" <[e-mail]:

"James Kanze" <[e-mail] in message
news:11*********************@c77g2000hse.googlegro ups.com...
On Jun 20, 5:08 am, "Chris Thomasson" <[e-mail]:

"Erik Wikström" <[e-mail] 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 "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?

___________________
P.S.
------- {

>

http://groups.google.com/group/comp....f29efe33e7f124
} (brief definition of Proxy GC...)
------- {

>

http://groups.google.com/group/comp....376b7295e6ce1a

>

http://groups.google.com/group/comp....9c2dd1afb8e0a3

>

http://groups.google.com/group/comp....e8e86dcce00c11

>

http://groups.google.com/group/comp....376b7295e6ce1a

>

http://groups.google.com/group/comp....f751d5dad6c07b
} (brief description of 'PDR')...

[James Kanze]

On Jun 21, 6:22 pm, "Chris Thomasson" <[e-mail]:

"James Kanze" <[e-mail] in message

news:11**********************@k79g2000hse.googlegr oups.com...
On Jun 21, 4:02 pm, "Chris Thomasson" <[e-mail]:

"James Kanze" <[e-mail] in message
>news:11*********************@c77g2000hse.googlegr oups.com...
On Jun 20, 5:08 am, "Chris Thomasson" <[e-mail]:
"Erik Wikström" <[e-mail] 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_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 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 "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:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <11*********************@k79g2000hse.googlegroups. com>,
ja*********@gmail.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_string 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.collect]:

[ 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]

"Jerry Coffin" <jc*****@taeus.comwrote in message
news:MP************************@news.sunsite.dk...
In article <11*********************@k79g2000hse.googlegroups. com>,
ja*********@gmail.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.collect]:

[ 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]

On Jun 24, 4:05 am, Jerry Coffin <[e-mail]:

In article <[e-mail]. com>,
[e-mail] 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_string 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: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jerry Coffin]

In article <11**********************@w5g2000hsg.googlegroups. com>,
ja*********@gmail.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]

co*******@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/product...ournal/?usenet