- Boost - lists.boost.org

Boost.Threads static linking status report
by Michael Glassford 11 Aug '04

11 Aug '04

Based on recent work and discussions here, I've checked in changes that implement tss cleanup in statically linked Boost.Thread on Win32 (for VC++ only, so far). I've also used the opportunity to rewrite the rest of the Win32 tss cleanup code and update it to use the Boost copyright. In the process, I eliminated threadmon.cpp, threadmon.hpp, and pe_tls.cpp. They've been replaced by tss_hooks.cpp, tss_hooks.hpp, tss_pe.cpp, and tss_dll.cpp. As suggested by Roland in his posted sample code, the default for VC++ linking of Boost.Threads is now static linking. I also changed all non-Win32 platforms to use static linking by default. I realize this is very late in the regression testing process to make these changes, but it seemed too good an opportunity to miss. If you disagree, please let me know. If the changes cause problems or it turns out to be a wrong decision in people's opinions here, I'll back the changes out quickly until after the release. In any case, many, many thanks to Aaron and Roland for working out this solution and making static linking possible on Win32. Mike

5 8

Sumptin' happened
by Victor A. Wagner Jr. 11 Aug '04

11 Aug '04

I don't know who did what to whom, but my regression test took over 8 hours last time. and now there are some new failures in VC7.1 I started it manually since it had missed the scheduled time to restart and looked at the log from cvs.... seems there are a lot of corrected files this time also. Victor A. Wagner Jr. http://rudbek.com The five most dangerous words in the English language: "There oughta be a law"

2 1

serialization and cwpro status
by Robert Ramey 11 Aug '04

11 Aug '04

Rene, Here is my assessment of the status of the serialization library as it relates to the Metrowerks compiler. all versions of CodeWarrior C++ CW two-phase lookup threw me for a loop. It took me long time to really understand this. Now that I do, I'm strongly convinced that it's a really bad idea. I don't know if its true - but I think I heard that it was implemented in order to make template export work - which looks like another bad idea to me. Oh well. CWPro 9.2 - my home copy All tests using utf8-codecvt fail. This includes the test for utf8-codecvt itself. I have come to believe that its an error somewhere in the MSL 9.2 implementation of the standard library. CWPro 8.3 - your machine The tests which serialize arrays fail - I haven't looked at this too carefully. There might be an issue regarding references to arrays decaying into pointers. Borland also has this problem. test_diamond fails with this compiler - I haven't figured out why it fails only here. CWPro 8.3 and 9.2 Hashed set serialization fails to produce the correct result at runtime. I haven't looked real closely at this. Since its particular to this version of CWpro I suspect it might be a library problem. I don't know how many standard libraries include support for hashed sets so I don't know for a fact that other compilers are in fact testing this. serialization of polymorphic derived pointers. Forward declaration method. I had reorganize code in archive_pointer_oserialize etc and use MSVC specific key words (used by BOOST_FORCE_INCLUDE) in order to get certain things to instantiate static variables whose pre-runtime construction is necessary for this to function. This seems like a bad idea as CW supports lots of other platforms. I tried every alternative I could find but wasn't able to find a better one that worked. "Export" functionality suffers from a variation of the above which I have not been able to overcome. So tests which use export fail. I've spent even more time on this - without success. It seems to me that CW is too smart in eliminating code that it "knows" it won't need. Actually I'm not even sure it's a CW issue. Comeau has the same symptom. That would suggest it's another manifestation of the problem I'm having comprehending two-phase lookup. CW < 8 I believe that these versions will pass 100 % Robert Ramey

4 5

Lock unification (shared vs. upgradable)
by Bronek Kozicki 10 Aug '04

10 Aug '04

Is there any reason for distinction between shared lock and upgradable shared lock? I mean - obviously updgradable shared lock can be upgraded to exclusive one, but do we need separate type for this? What's rationale behind this distinciton? I can easily imagine design (and implementation) where every shared lock is also upgradable one, if it's mutex type support upgrade operation. Under such design one can upgrade shared lock only if it's the only (currently locking) lock on synchromization object (supporting such transition). Implementation of such mutex could be very similar to semaphore (or just using semaphore, if present on platform). Here are some simple use cases: some_mutex_type_not_supporting_shared_locks m1; shared_lock<some...> l1(m1); // compilation error some_mutex_type_fully_supporting_shared_locks m2; shared_lock<some...> l2(m2); // ok exclusive_lock<some...> l3 = l2.try_upgrade(); // ok, non-blocking some_mutex_type_with_limited_support_for_shared_locks m3; shared_lock<some...> l4(m3); // ok exclusive_lock<some...> l5 = l4.try_upgrade(); // compilation error exclusive_lock<some...> l6 = l4.upgrade(); // ok, blocking some_mutex_type_with_minimal_support_for_shared_locks m4; { shared_lock<some...> l7(m4); // ok exclusive_lock<some...> l8 = l7.try_upgrade(); // compilation error exclusive_lock<some...> l9 = l7.upgrade(); // compilation error } exclusive_lock<some...> l10(m4); // ok B.

6 25

boost::filesystem problems under windows
by Stefan Seefeld 10 Aug '04

10 Aug '04

hi there, I'v some trouble with filesystem::path manipulation with boost release 1.31 / vc 7.1 . The code ----------- fs::path src = fs::path(__FILE__, fs::no_check); std::cout << "src= " << src.string() << std::endl; fs::path dir = src.branch_path(); std::cout << "script dir= " << dir.string() << std::endl; ----------- generates the output src= C:\cygwin\home\stefan\ToolBox\test\scripting\Algo\embedding.cpp script dir= C: i.e. it appears path::branch_path() doesn't work. Does anybody have an idea what's going on here ? Thanks, Stefan PS: oh, and if I replace the fs::no_check above by fs::native, I get an exception 'invalid path' which, I assume, fs::native is supposed to suppress.

1 0

pool/detail/mutex.hpp patch
by Thomas Witt 10 Aug '04

10 Aug '04

The attached patch fixes what I think is a bug in the win32 platform detection code. Thomas -- Thomas Witt witt(a)acm.org Index: mutex.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/pool/detail/mutex.hpp,v retrieving revision 1.4 diff -u -3 -p -u -r1.4 mutex.hpp --- mutex.hpp 14 Sep 2003 00:50:31 -0000 1.4 +++ mutex.hpp 10 Aug 2004 00:15:22 -0000 @@ -22,7 +22,7 @@ // No multithreading -> make locks into no-ops #define BOOST_MUTEX_HELPER BOOST_MUTEX_HELPER_NONE #else - #ifdef __WIN32__ + #if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) #define BOOST_MUTEX_HELPER BOOST_MUTEX_HELPER_WIN32 #else #include <unistd.h> @@ -37,7 +37,7 @@ #endif -#ifdef __WIN32__ +#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) #include <windows.h> #endif #ifdef _POSIX_THREADS @@ -49,7 +49,7 @@ namespace boost { namespace details { namespace pool { -#ifdef __WIN32__ +#if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) class win32_mutex { @@ -73,7 +73,7 @@ class win32_mutex { LeaveCriticalSection(&mtx); } }; -#endif // defined(__WIN32__) +#endif // defined(_WIN32) || defined(__WIN32__) || defined(WIN32) #ifdef _POSIX_THREADS

2 2

Missing typename in range compat2_test
by Jonathan Wakely 10 Aug '04

10 Aug '04

This fail (and a related warning for GCC 3.3) http://boost.sourceforge.net/regression-logs/cs-Linux-links.html#range-comp… would be fixed by applying the attached patch jon -- ABROAD, adj. At war with savages and idiots. To be a Frenchman abroad is to be miserable; to be an American abroad is to make others miserable." - Ambrose Bierce, 'The Devil's Dictionary'

4 5

old filesystem improvements
by Walter Landry 10 Aug '04

10 Aug '04

Greetings, In the past, I've posted various patches to the filesystem library. Some of them were implemented, and some were not. In particular, I offered patches to implement symlink and readlink http://lists.boost.org/MailArchives/boost/msg52521.php the who() function for filesystem exceptions, http://lists.boost.org/MailArchives/boost/msg52522.php copy and copy_directory, http://lists.boost.org/MailArchives/boost/msg58652.php and hard links. http://lists.boost.org/MailArchives/boost/msg61975.php Since these posts, I've modified and extended some of them a little. I'm happy to post the new versions, but I am wondering if there is actually any interest in any of these things. Regards, Walter Landry wlandry(a)ucsd.edu

3 2

why run-fail tests are missing from Boost-wide reports?
by Gennadiy Rozental 10 Aug '04

10 Aug '04

Regards, Gennadiy.

1 0

Problems with MPL in Fusion on MSVC 6.5
by Peder Holt 10 Aug '04

10 Aug '04

Hi. I am porting Fusion, Joel de Guzmans new tuple library to MSVC 6.5 and VC 7.0. Several of the testcases ICEs on MSVC 6.5. I traced the problems back to integral_c's operator int() Problem: When the template expressions gets too complicated, MSVC is unable to handle inlined functions inside a type computer struct. Solution: Place the function body outside of the struct. The relevant lines: operator AUX_WRAPPER_VALUE_TYPE() const #if BOOST_WORKAROUND(BOOST_MSVC,==1200) ; #else { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif }; #if BOOST_WORKAROUND(BOOST_MSVC,==1200) template< AUX_WRAPPER_PARAMS(N) > AUX_WRAPPER_INST(N)::operator AUX_WRAPPER_VALUE_TYPE() const { return static_cast<AUX_WRAPPER_VALUE_TYPE>(this->value); } #endif This change fixed most of the remaining (known) issues with Fusion & MSVC Is it OK if I check in these changes? -- Peder Holt

4 4