Re: Order of destruction of static members and static objects
On Nov 30, 3:21 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
James Kanze wrote:
But does that ensure that it's not accessed after it has been
destroyed? If not, how do you make sure it's not?
std::vector< int >&
sharedContainer()
{
static std::vector< int >* theOneAndOnly = new std::vecctor< int >;
return *theOneAndOnly;
}
The standard singleton idiom, in fact.
So you mean that you have to deliberately introduce a memory
leak if you want to make sure the container is not accessed
after it has been destroyed?
How are you defining "memory leak". I don't see anything which
could be qualified as a memory leak, with any of the usual
definitions.
The only useful definition is "memory which leaks"; i.e. which
is periodically reallocated, with previous allocations going
unused, so that the program grows indefinitely. That's not the
case here. I have seen it defined as memory which can no longer
be accessed, because there are no more pointers to it; the only
use I can think of for this definition is to prove that you
can't get a memory leak with garbage collection. But the above
doesn't leak by this definition either, since there's always a
pointer to it.
Is there *really* no better way of doing it?
It being? And "better" meaning?
If the goal is to ensure that an object is not destructed (which
is what you want here), then I don't know of any better way of
doing it than using an allocation without a delete.
--
James Kanze