gast128 wrote:
Downloading and using the 1.32 version was probably not such a good idea...
Why do you think so? I am facing a similar situation in that I will need to rewrite parts of my code that is using ublas. Altough I think it is worth the effort. Remember: boost (as I understand it) is not intended as beeing API stable! I only expect parts beeing stable that are already in the standard. Others constantly face improvement. And this is the place where it is to happen. Do I get something wrong?
Now I get a mem-leak reported by the debug crt of VC 7.1. The report is located in 'init_threadmon_mutex' where a global object is allocated but never deleted. Before we start a discussion of what is a memory leak or not, in our production code we do not accept any leak reported by VC. The past has learned us that if you accept one leak, programmers/colleaques start to ignore them and in the end you have 200 leaks, instead of this one.
Granted. However as I have found out using the MSVC memory leak detection can be tricky at times. One usually must be careful not to generate false alarms. Which detection system do you use? (Sidebar: wouldn't a boost::memory_debug lib be desirable?) E.g. when inside MFC you cannot be sure when the detection code actually triggers, since it is called from within a destructor of a global object. If you are also allocating dynamic memory from a global constructor the leak is reported depending on the order of constructor calls. (Don't know why MS deactivated the CRT detection when using MFC....)
I guess it wouldn't be difficult to resolve this one, on process exit it can be deallocated.
I guess you are refering to the (documented) leak in tss.cpp, aren't you? // Intentional memory "leak" // This is the only way to ensure the mutex in the global data // structure is available when cleanup handlers are run, since the // execution order of cleanup handlers is unspecified on any platform // with regards to C++ destructor ordering rules. tss_data = temp.release(); Getting rid of it however is not as trivial as it might seem at first glance, since the TLS code is able to clean up even when used from non boost::threads. There is also a yet to be discussed issue what should happen when the main thread exits but a user thread is still running. (When you have a look at pthreads, this is quite legal.) And what is "process exit" when speaking about global ctors/dtors?
And yes I am aware of the (phoenix) singleton discussions in Alexandrescu/Meyers, but really this kind of reinit of singletons after atexit calls won't happen too much.
Sorry I am not aware of this discussions, could you give me a short overview? I suspect the problem is similar to when using the CRT together with the native CreateThread API. In this case you are also introducing an unavoidable memory leak, where the CRT's TLS doesn't get deallocated. (Or occasionally will be reallocated.) However I already have proposed a solution to the above problem (at least for the windows version) which is based on reference counting. This however requires a (significant) bit of rewrite which I think Michael Glassford did not want to introduce so short before release. At least the leak is intentional and well understood. But I agree it _is_ ugly and it should be removed for any reason, no matter. Roland