Re: Memory leak: Windows DLL build only

There is a quick and dirty fix (work around) for the memory leak that 
works for MSVC 7.1 -

Change the constructor:
        StringBuffer() : std::basic_ostream<wchar_t>(0)
                { this->init(&buffer); }

to
        StringBuffer() : std::basic_ostream<wchar_t>(&buffer) {}

This is NOT a good fix because it assumes that buffer is constructed 
(and therefore the reference valid)  at the point that the constructor 
of the class which holds it is called.  My understanding of the C++ 
specification is that this can NOT be assumed. In fact, this would be 
why the init() call was made available. [Sorry for the poor 
explanation.]

Anyway, insofar as the MSVC 7.1 memory leak in multithreaded DLL code 
is concerned, this patch resolves the issue (and works in all 
configurations that we tested single/multi threaded, debug/nondebug, 
DLL/static).

Apologies if my poor understanding of the C++ specification has lead me 
astray - willing to be corrected by those who know better, so please 
do.

I will take a look at the latest CVS code when it is available with the 
APR migration and run our test cases with purify and report back. [I 
hope your path to APR is smoother than the raft of issues that I ran 
into with APR versions and Subversion. If you need help checking Linux, 
Windows or Mac OS X builds, I am willing to help when you have the code 
in CVS.]

btw a work colleague who has had good contact with M$ just warned me 
about the use of basic_ostream because of the way it uses LOCALEs 
internally. Suggested avoiding them because of the overheads. Can't 
comment one way or the other myself but seems like you are heading away 
from them in any case.

regards
malcolm

ps Has anyone else ever pondered like me what would have happened if 
Intel had maintained the segmented architecture? We would have, on top 
the current configurations (single/multi threaded, debug/nondebug, 
DLL/static), the added dimension of small, medium, large, huge and 
anything else Intel and M$ dreamed up. And I suppose we could have had 
16/32/64 bit flavors of the models so more variants. So I am grateful 
for a linear address space!

----------------------------------------------------------------
Malcolm Melville                    email:   malcolm@xxxxxxxxx
ixa2a ltd.                                   malcolm@xxxxxxxxx
Software and technical services     Tel:     +44 1435 831159
                                    FAX:     +44 1435 830216
Enterprise Melville Limited         Mobile:  07771 781478
Network and Aviation Consultancy
----------------------------------------------------------------