Passing Pointers -- where to delete them

[Ian Collins]

James Kanze wrote:

[...]

I guess we bent the rules for our singleton objects to enable
then to be created and destroyed in tests. The single
instance is enforced through a base class template with a
static member pointer.
The problem with this is that you're no longer testing the code
you actually use.

No, the code is the code we actually use.

But the context it's tested in isn't. Especially if you're
"resetting" a singleton. (I suppose that if you're actually
destructing the object, and renew'ing it, the difference is
minor. But I can still imagine cases where it might make a
difference.)

That (destructing the object, and renewing it) is the case.

Except, of course, that it's running in a different environment.
That's partially unavoidable, of course, but in code that I
expect to be run before main(), I do ensure that it's tested
running before main().

That's one reason why we construct everything from main(), restricting
static objects to pointers. When running tests on a different platform
form the eventual target, it pays to minimise the potential differences.
Initialisation order is one potentially significant difference.

 

[James Kanze]

James Kanze wrote:
James Kanze wrote:

[...]

Don't forget that everything I or my team writes is written
test first, so the only thing is actual production code.

Except, of course, that it's running in a different environment.
That's partially unavoidable, of course, but in code that I
expect to be run before main(), I do ensure that it's tested
running before main().

That's one reason why we construct everything from main(),
restricting static objects to pointers. When running tests on
a different platform form the eventual target, it pays to
minimise the potential differences. Initialisation order is
one potentially significant difference.

Then you don't use the classical singleton idiom (which is, of
course, designed explicitly as a solution to the order of
initialization). That's probably a solution in some cases, but
it does introduce significant coupling: main has to know about
everything which needs initialization.

And of course, it still doesn't really change anything---there's
still a difference in the environment when the instance is
created the second time. Probably not significant, at least
most of the time, but still a difference. (Of course, in
practice, you can't possibly test all possible "environments" in
which the object might be used. Nor, reasonably, do you have
to. But you do need to be aware of what might be different.
And there's always something.)

FWIW: I wrote my own test harness---I was using it before
cppUnit existed. The original motivation for adding support for
using a separate process wasn't singletons, but a bit of code
whose purpose was to manage error messages and the return code:
it wrote to std::cerr, and if the error severity was sufficient,
terminated the process. And I couldn't figure out how to test
that it really did terminate the process (with a failure return
code) except by running it in a separate process. Once I had
that in the harness, however, it seemed logical to use it for
things like singletons. Rather than add special code to them to
break them down, so that they could be reconstructed. It also
turns out to be handy when I implement dynamic mapping code,
where the map is a singleton, but the elements in it are static
objects, which enrol with the map in their constructors. (I've
posted the idea here several times, when people ask about class
factories, etc.---creating an object whose type depends on an
externally provided key.)

Anyhow, it works for me.