res wrote: > On 16.09.2006 16:04, Lukas Erlinghagen wrote: > >> +# Unit-testing helper classes/macro: replaces >> CPPUNIT_TEST_SUITE_REGISTRATION >> +# with a version that lives on the CS side. This prevents a crash on exit >> due >> +# to static variable destruction order. >> > > >> +# CrystalSpace has its own memory allocator, though, so the automated test >> +# registration has to happen on CS's side. Therefore, the boilerplate code >> +# from CS's Jamrules contains our own implementation of >> +# CPPUNIT_TEST_SUITE_REGISTRATION and its companion classes. It also >> #defines >> +# the "CS_CPPUNIT" symbol to distinguish between our macro and the generic >> +# CppUnit variant. >> > > AFAICS that makes two explanations for the same thing. Which of these > explanations is the correct one? > > -f.r. Actually, both are:
CPPUNIT_TEST_SUITE_REGISTRATION causes the creation of a static variable inside libcppunit, which uses CS's allocator. However, ptmalloc is shut down before this variable is destructed, leading to a crash. The replacement macro creates this static variable inside CS, so that it is destructed while ptmalloc still has a valid state. The first explanation is more appropriate, I guess. Greetings, Lukas E. (erluk) ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Crystal-main mailing list Crystal-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[EMAIL PROTECTED]
