ma740988 wrote:
Quote:
Referencing source snippet below, the actual contruction of the foo
objects is done in a class. In that regard, I chose methods,
class1_construct and class2_construct for demonstration purposes. That
aside, I encountered source akin to what's shown below today and I was
almost convinced the source is wrought with trouble. On second thought
it appears legal. The static ptr_foo object and it's use in assignment
to other foo objects (ptr_1 etc ) at first troubled me but it's fine as
is. Correct? Of course the real issue surrounded the fact that the
ptr_1, ptr_2, ptr_3 and ptr_4 objects ar used in a thread. As a result
when the user exited the GUI application the vector of foo objects ( fv
vec ) was being called prior to destruction of the ptr_1, ptr_2 , ptr_3
and ptr_4 objects. That led to nasty error messages.
>
My initial recommendation (futher below )was to rid the 'statics', in
part because I thought there was a static initilization/destruction
fiasco going on. Come to think of it that's not the case. Correct?
Having said I think the ideal thing to do here involves the use of a
reference counted smart pointer. Correct?
At global scope, the "static" keyword affects linkage, not lifetime, so
a static initialization/destruction fiasco would not be affected. The
only thing that changes when you remove the "static" keyword from
ptr_1, ptr_2, ptr_3, and ptr_4 is that now they may be referenced by
another translation unit (one that declares them with something like
"extern foo *ptr_1;").
In a quick examination, I don't see anything wrong with the code you
posted, with or without the statics. Does it cause some error on your
system?
--
Alan Johnson