- Boost - lists.preview.boost.org

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

shared_ptr for ROOT
by troy d.straszheim 10 Aug '04

10 Aug '04

Hi boost:: I have created a work derivative of the boost::shared_ptr and would like boost's OK before I release this into the wild. Explanation: I am on a large project, a neutrino telescope, that involves the ROOT data analysis framework (http://root.cern.ch) This is a large package, one of whose features is a C++ interpreter. That's right, an *interpreter*. You build shared objects describing your classes, load them into the interpreter, and then you can run C++ *scripts*. The ability to do all of this is absolutely insisted upon by my client, a platoon of physicists. From what I can see this is almost a standard in high-energy physics. The general idea is that, if one inherits one's object from the ROOT uber-object "TObject", and puts a macro into the class class MyClass : public TObject { // whatever ClassDef(MyClass, 1); // this inserts "streamer" functions }; then one can quite easily write these objects to disk, and use a whole slew of introspection functions that come from TObject, like bool InheritsFrom(string classname) and Browse().. well you get the idea. One's code must make its way through a code generator, called "rootcint" which adds a bunch of functions to the class. One then specifies the template instances that one wants dictionaries for with #pragmas. I managed to put together a hybridized boost::shared_ptr that works with this framework. Objects that are inherited from the TObject that contain boost::shared_ptr-s to other TObjects make the round trip to/from disk with all reference counting and everything intact. Not a small feat, if I may say so, and possibly of general interest to the ROOT community. This involved a hybridization of the no-member-templates shared_ptr and the "regular" shared_ptr. rootcint is very idiosyncratic. Member template friends don't work (I am told the fix is in CVS). sp_enable_shared_from_this doesn't work. template member functions do, for the most part, but the keyword volatile seems to confuse things. You get the idea. the atomic_count stuff had to be taken out. specializations of void didn't go through, if I remember correctly. I removed most everything that was not necessary for linux/macosx and gcc (our project's platforms). I dislike "forking" code and doing merges, but I could not imagine that boost itself would have any interest in supporting this toolkit's interpreter, the #ifdefs would be nightmarish, and testing required the framework itself, of course. I also could not leave the hybridized version named "boost", as the full boost libraries remain in our toolset, and anyway it would not be truth in advertising, I may very well have introduced some bugs. With perl's help I named everything "roost" (root/boost). I have left the comments intact at the tops of the files and where applicable added my own. the boost license is of course included. The documentation clearly states that this is a ROOT-specific version of the boost::shared_ptr<> Again, I just wanted to be sure this all was OK and give an opportunity to before I release this into the wild. The tarball is at http://www.resophonic.com/software/ROOST-1.0.tar.gz and runs tests with ./configure && make runtests Which would require ROOT (http://root.cern.ch) If you're interested, I can give quick instructions on that offline, mail me directly. Thanks, -t

2 1

Re: [boost] shared_ptr improvement proposal
by brangdon＠cix.compulink.co.uk 09 Aug '04

09 Aug '04

In-Reply-To: <200408091418.i79EIu107210(a)entwistle.systems.susq.com> stewart(a)sig.com (Rob Stewart) wrote (abridged): > The whole point behind the names selected for the new-style casts > was to make things more verbose. Yes. And as a result, I know some people still sometimes use old-style casts entirely because they are shorter. I can see mine is a minority view, so now that I've made my plea I'll shut up :-) > Note that it can be written as follows when not casting to a > different pointer type: > > boost::shared_ptr<Widget> p(boost::shared_ptr_cast(new Widget)); Thanks, that helps. -- Dave Harris, Nottingham, UK

1 0

Boost.Thread compile problems
by Johan Nilsson 09 Aug '04

09 Aug '04

Hi, I'm getting errors from the tss handling when compiling Boost.Thread using the DEC CXX 6.5 compiler (under OpenVMS). The compiler doesn't like the fact that a pointer to a function with C++ linkage is being passed to a function expecting a pointer to a function with "C" linkage. The function in question is when the address of "thread_specific_ptr<T>::cleanup" is used as an argument to pthread_key_create (indirectly). I'm using Boost 1.31.0. The workaround I've implemented is the following (snippets from the modified source to illustrate): --- tss.hpp --- namespace boost { namespace detail { extern "C" { typedef void (*pthread_key_destruct_cb_t)(void*); <<<=== } class BOOST_THREAD_DECL tss : private noncopyable { public: tss(pthread_key_destruct_cb_t cleanup = 0); <<<=== [snip] template <typename T> class thread_specific_ptr : private noncopyable { public: thread_specific_ptr() : m_tss(reinterpret_cast<detail::pthread_key_destruct_cb_t>(&thread_specific_p tr<T>::cleanup)) <<<=== {} [snip] --- tss.cpp --- [snip] #elif defined(BOOST_HAS_PTHREADS) tss::tss(pthread_key_destruct_cb_t cleanup) <<<=== { int res = 0; res = pthread_key_create(&m_key, cleanup); if (res != 0) throw thread_resource_error(); } [snip] ------ I'd be very grateful if you could implement something similar (this might not be the prettiest fix) before the release of 1.32.0. There are also some very annoying warnings originating from meaningless casts (from timeconv.inl), e.g.: --- timeconv.inl --- [snip] const int NANOSECONDS_PER_SECOND = 1000000000; [snip] #if defined(BOOST_HAS_PTHREADS) inline void to_timespec(const boost::xtime& xt, timespec& ts) { ts.tv_sec = static_cast<int>(xt.sec); ts.tv_nsec = static_cast<int>(xt.nsec); if(ts.tv_nsec > static_cast<const int>(NANOSECONDS_PER_SECOND)) <<<=== [snip] ------------ Basically the compiler finds it pretty meaningless to cast "const int"s to "const int"s (and so do I). Possible to fix this also? Thanks // Johan

3 4