Re: Passing Pointers -- where to delete them
On Mar 5, 12:31 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On 4 mar, 19:02, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Mar 4, 10:45 am, Ian Collins <ian-n...@hotmail.com> 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.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34