> Providing optional GC would be a big win. Providing
> useful (and standard) counted and counting_ptr pairs
> would fix a ton of systems, but we are still fooling
> around with this?
>
> Color me disgusted.

Well, an attractive collection of smart pointers has been added to C++0x that would make you quite happy, and GC is under discussion. (Color yourself updated.) But in the meantime, we need to get by.

> that this is still the state of discourse in C++.
>
> Frozen in time for something like 10 years.

Well folks have been working hard in that time for a "new release" of the standard, which seems likely to contain a decent - and useful - collection of pointer wrappers, including counting ones.

If the language had been moving at the rate it was pre 1997, would you have preferred it?

> Still no
> standard reference counting pointer implementation?
> Auto_ptr is weird and error prone and this level of
> f fiddling is just madness.

Ah well, auto_ptr has its uses though. Less wierd I reckon than strtok. And less error prone ;-)

> Providing optional GC would be a big win.

I'm still bemused by the amount of people who think automatic GC is some kind of silver bullet (I'm not suggesting you are one of them). I write in C# and C++ a lot, and I prefer C++'s deterministic destruction. For one thing, it makes exceptions much easier to think about.

Steve

There's one misleading sentence in the article:

Another way of prohibiting copy construction and copy assignment is to make one or more members a reference or const (or const reference, for the especially cautious)—this effectively shuts down the compiler's ability to generate these special member functions

As far as I remember, const or ref members won't disable copy constructor implicitly generated by compiler. It will only disable implicit copy assignment operator, or (more precisely) render program ill-formed when implicitly generated by compiler copy assignment operator is used.

can you help me by doing this referal for getting a free ipod or pc you chose..... Just sign in and complet the recomended Call wave form and i will guide you so no personal info is given..at the end(with just referring some people) of the we will both have and ipod and its not a fake..please !http://www.freeiPods.com/?r=14135080

http://www.FreeDesktopPC.com/?r=14319525

http://www.FreeFlatScreens.com/?r=14321387

Thanks

I realize this is a newbie question, but does this code cause a leak for the old value of p_?

Example& operator=(const Example& other) {
// Self assignment?
if (this==&other)
return *this;

*p_=*other.p_; // Uses SomeResource::operator=
return *this;
}

Iam loooking for a Dan Teske from Cleveland Ohio .1969 Grad. of Rhodes High School / St. Thomas More 1965. Please advise if you r him ...Marsha PROS Gorman

I realize this is a newbie question, but does this code cause a leak for the old value of p_?

Example& operator=(const Example& other) {
// Self assignment?
if (this==&other)
return *this;

*p_=*other.p_; // Uses SomeResource::operator=
return *this;
}


With all the indirection going on, it's a bit tricky to see, but there's no leak here. The reason is that there's no memory allocation or deallocation, only copying of values. That is, the assignment statement ("*p_=*other.p_;") is copying the value of other's p_ into the location currently pointed to by this's p_. Their allocation remains the same.

A simplified example:


int *i = new int(42);
int *i2 = new int(2008);

*i = *i2; // no leak here; just copying values

delete i2;
delete i;