Re: [Cppunit-devel] memory allocation and DLL, was: hierarchy sample bug...

[Baptiste L. <bl...@cl...>]

> Just one thing I realized today about the solution below: dynamically
> allocating the suite in the test case could be dangerous; at least given
the
> current environment on Win32. The issue is that there are multiple DLLs
and
> the application, all of which could be using different versions of the
> run-time library. It may not be safe to call delete on memory allocated in
a
> different module. While it is in the same process space, the actual code
in
> the RTLs could be different, depending on how each module was linked. (ie.
> static RTL vs DLL RTL vs multi or single threaded vs different versions of
> compiler). I recently read about this all too common problem in Jeffrey
> Richter's "Programming Applications for Microsoft Windows - Fourth
Edition"
> Given his expertise level, I would have to bet it's a real problem that
> should be avoided. The bottom line is that memory allocated in a given
> module should be freed in that same module.
    This is a real problem when you release DLL which you have no control
over, but that is not the case here. Unit test are of use for us,
developers, not for the clients. You only have to know what you are doing
when splitting your code into DLL (and its nigh impossible to successful
compile against a library that is using different RTL setting, you always
ends up with some conflicts at link time).
    Also, unit testing is of use for development, but should not be in the
final published interface of the DLL. If you want to mix up RTL setting in
different DLL, you will run into trouble and you would need to use the usual
encapsulation technics to solve them. The same technic can be applied to the
DLL published suite. You could use a encapsulating suite that delegate
instantiation and destruction of the "published" suite to the DLL.
    I think that this problem should not be solved by cppunit, as solution
depends much on the use, platform... On the other hand it may be interesting
to document it, and some of the possible solution.

>
> The basic problem is memory leaks, which is not a _huge_ problem for these
> applications, since after the test application closes, the OS will clean
up
> any memory allocated in that process. ( at least NT/Win2K will do that
    Memory leaks are very important, and you should always minimize them. If
you don't destroy test, you will make memory leaks detection tools useless.
You application may not be closed for weeks or months (your standard server,
for example). Unit test have this marvelous property that they use the code
in many way. Chasing the memory leak (when they occurs in some weird
context) is usually easy that way.

> properly) On the other hand, creating code that doesn't cause memory leaks
> is still much preferrable. This may be an issue in other places in the
code
> too, although the main problem area will only be the TestRunner DLL
freeing
> memory allocated elsewhere.
>
> On the other hand, if the base TestRunner class does the memory freeing
> (deletes the suite), and it ends up in the cppunit (statically linked)
> library, then we're okay. Perhaps this will work out more easily than I
> first thought...
    This wouldn't works. Some suite/test given to the test runner could be
instantiated by the host application. A suite can be instantiated by test
runner (it automatically creates a "all tests" suite if more than one test
was registered). See above for the solution I propose.