Quote Originally Posted by Russco View Post
Remember objects in stl containers are copied in and copied out.
Ah, I had forgotten.

You store the this of a temporary yet this gets copied into the vector. MyClass relies on a default copy constructor, so your set becomes out-of-sync with the real this pointers.

Provide a copy constructor that updates the set correctly.
Are you saying that the objects are being copied, or that the pointers are being copied?
1.) If the objects are being copied, why? The container only holds pointers to the objects.
2.) Or are the pointers being copied, and then the objects are being moved around in memory, such that the copies of the pointers no longer point to the objects?


Quote Originally Posted by Paul McKenzie View Post
Well, you're making my point.

What if when optimizations are turned on (which you want turned on for release versions of your code), the output is different? What do you do then?

Hopefully you are observing this behaviour only for educational purposes. If you are truly planning on writing a program based on when objects destroy themselves, then you're going about this the wrong way.

Regards,

Paul McKenzie
Thanks for the warning...

It was never my intent to rely on some "compiler quirk" to get my program working. I'm just not clear on what's happening here, or what assumptions I have that are causing me to expect something else to occur...

My goal is to have a class which contains a static function which, when called, calls a member function on all instances of the class. My purpose for the code shown above was just to be a proof of concept, that I could track all the existing instances of the class--I probably would have added the static function next. However, it seems some instances are being destroyed before I expect, or there are copies taking place that I'm unaware of, or the pointers in the set are being invalidated, or...?

So, if I am going about this the wrong way, can you suggest a right way?

Thanks.