January 2009 - Boost - lists.preview.boost.org

Re: [boost] A PP trick to define a synchronized block java-like macro
by JOAQUIN M. LOPEZ MUÑOZ 21 Jan '09

21 Jan '09

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de Sebastian Redl [sebastian.redl(a)getdesigned.at] Enviado el: martes, 20 de enero de 2009 22:39 Para: boost(a)lists.boost.org Asunto: Re: [boost] A PP trick to define a synchronized block java-like macro > vicente.botet wrote: > > for (VARS DECLARATION, bool __continue=true; > > __continue; > > __continue=false) > > > > > I'm afraid this is not valid syntax. The first clause of the > for-statement is a for-init-statement, which can be either an expression > with a semicolon, or a simple-declaration. A simple-declaration lets you > declare any number of variables, but they must all have the same > declspec, i.e. the same fundamental type (with variations like "pointer > to", "array of" or "function returning"). The following variation would do: for (VARS DECLARATION, *continue_hlp_,**continue_=&continue_hlp_; continue_; continue_=0) Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

5 6

[1.38.0][Spirit] char_class test failing on both trunk and release, all platforms
by Beman Dawes 21 Jan '09

21 Jan '09

The Spirit char_class test is failing on both trunk and release, all platforms. Any progress on fixing this? --Beman

2 1

[1.38.0] [config] Linux release branch link failures
by Beman Dawes 20 Jan '09

20 Jan '09

config_test is failing with link errors on both Linux testers. Any ideas? --Beman "g++" -o "/home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test" -Wl,--start-group "/home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group -g /home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test.o: In function `boost_has_pthread_mutexattr_settype::f()': /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthread_ma_st.ipp:21: undefined reference to `pthread_mutexattr_init' /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthread_ma_st.ipp:23: undefined reference to `pthread_mutexattr_settype' /home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test.o: In function `boost_has_pthreads::test()': /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthreads.ipp:35: undefined reference to `pthread_mutex_trylock' /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthreads.ipp:44: undefined reference to `pthread_create' /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_pthreads.ipp:52: undefined reference to `pthread_join' /home/steve/Packages/boost/upstream/testing/release/results/boost/bin.v2/libs/config/test/config_test.test/gcc-4.3.3/debug/config_test.o: In function `boost_has_clock_gettime::f()': /home/steve/Packages/boost/upstream/testing/release/boost/status/../libs/config/test/boost_has_clock_gettime.ipp:21: undefined reference to `clock_gettime' collect2: ld returned 1 exit status

3 3

A PP trick to define a synchronized block java-like macro
by vicente.botet 20 Jan '09

20 Jan '09

In Boost.Log we can see how to define a macro that preserv the osream syntax but that logs conditionally. LOG << "Ah" << std::end; We use here the following trick: let the sentence generated by the macro is unterminated and form a correct sentence together with what follows the macro call. #define LOG if (!log::enabled()); else log::os I have recently see in [1] a trick allowing the declaration of a variable local to a block scope but OUT OF THE SCOPE!!!. This will allows to write things like synchronized(mtx_) { // block protected by a scoped lock } or atomic(tr) { // atomic block managed by a transaction } The idea is to place the declaration of the needed variables on the init declaration of a for. So these variables are accessible by the next sentence or block. The condition will let executes its body only once. A variable __continue variable is used to this goal; it initialized to true and set to false on the next part of the for. for (VARS DECLARATION, bool __continue=true; __continue; __continue=false) The definition of the synchronized macro can be #define synchronized(MUTEX) \ for (boost::mutex::scoped_lock __lock(MUTEX), bool __continue=true; \ __continue; \ __continue=false) In order to help when debuging we can define the __lock and _cont variables as macros generating symbols including the line number. #define __concat(a,b) a##b #define _concat(a,b) __concat(a,b) #define __lock _concat(__lock_, __LINE__) #define __continue _concat(__continue _, __LINE__) As the variables are local to the scope, we can use the macro twice on the same line as synchronized(mtx_1) synchronized(mtx_2){ // block protected by a scoped lock on mtx_1 and mtx_2 // ... } See how we can nest the synchronized blocks: synchronized(mtx_1) { // block protected by a scoped lock on mtx_1 // ... 1 synchronized(mtx_2) { // Embeeded block protected by a scoped lock on mtx_2 // ... 2 synchronized(mtx_3) unique_sentence_protected_by_mtx_3(); // ... 2 } // ... 1 } I know that most of the participants to this ML do not like macros too much, even less when we can do without them. { // block protected by a scoped lock on mtx_1 boost::mutex::scoped_lock lock1(mtx_1) ; // ... 1 { // Embeeded block protected by a scoped lock on mtx_2 boost::mutex::scoped_lock lock1(mtx_2) ; // ... 2 { // Artificial Embeeded block protected by a scoped lock on mtx_3 boost::mutex::scoped_lock lock1(mtx_3) ; unique_sentence_protected_by_mtx_3(); } // ... 2 } // ... 1 } But I think that in these cases the language-like macros make the code realy more readable, specially in the case of software transactional memory (STM), see (http://en.wikipedia.org/wiki/Software_transactional_memory) // language-like transaction with retry. try_atomic(t) { transaction_ptr(x) = val; } before_retry {} I wanted simply to share this trick with you, maybe someone wants to use something like that in its own application. Let me know however what do you think. Thanks to the authors of this excelent paper and the DracoSTM library. Hoping this would inspire some of you, Vicente ___________________________________ P.S. the exception based timed locks post http://www.nabble.com/-thread--Exception-based-timed-locks-tp21554444p21554… is also inspired from this article. [1] Toward Simplified Parallel Support in C++ Justin E. Gottschlich, Jeremy G. Siek, Paul J. Rogers and Manish Vachharajani

2 1

filesystem::remove_all error handling
by Zachary Turner 20 Jan '09

20 Jan '09

Has there been any discussion regarding the possibility of filesystem::remove_all allowing a second parameter, a functor or function, to be specified which on any file system error is called with the filename that was attempted to be removed as well as the error code? My application, for example, would like to log every single occurence of failure with a warning, but still delete every possible file that it can, but I see no way to handle this without rolling my own implementation of remove_all. Which is fine if that's what I have to do, but at the same time it doesn't seem that uncommon a case where someone would want to know about every single error, yet still attempt every deletion possible. I guess one tricky aspect of this is that you probably would not want to invoke the error callback if the error code means "directory not empty" and the reason it is not empty is because a file was unable to be deleted below the directory. Side note, but the implementation of remove_all does not appear to be tail recursive either, so even the best compiler will not be able to optimize this into a loop, leading to the potential for a stack overflow in deeply nested directory hierarchies. (Now that I think about it, I'm not even sure what, if any, C++ compilers optimize tail recursive calls). Apologies if either of these two issues has been addressed (I'm using 1.35.0), did not find anything in the archives. Thoughts?

2 1

[Serialization] Improving performance
by Hartmut Kaiser 20 Jan '09

20 Jan '09

Hi all, in one of my projects I have a lot of types (>1000) to be serialized using a pointer to a single base class. At some point we found the serialization/deserialzation time to be O(N*M), where N is the number of types and M the number of classes in the derivation hierarchy. Wondering why this is so significant I started digging and measuring. I found the type information registry used for the void_upcast() to be the culprit. It's a plain std::vector<const void_caster *> ($BOOST_ROOT_1_37/libs/serialization/src/void_cast.cpp:37) which is searched sequentially a lot (once for each derived/base pair for each serialization call). Moreover, this vector isn't even kept sorted. it = std::find_if( s.begin(), s.end(), void_cast_detail::match(& ca) ); ($BOOST_ROOT_1_37/libs/serialization/src/void_cast.cpp:180). Changing this to be a std::set improves the picture significantly! What's the reasoning behind using a std::vector<> instead of a std::set<> or a similar indexed structure? Regards Hartmut

4 3

[thread] Exception based timed locks
by vicente.botet 20 Jan '09

20 Jan '09

Hi, I've read recently about timed locks throwing an exception when there is a timeout. What do you think about this behaviour? Could the thread library provide both? Next follows a piece of code without exceptions while (polling) { t=now()+100; boost::unique_lock<boost::mutex> l1(m1, t); if (l1.has_lock() { boost::unique_lock<boost::mutex> l2(m2, t); if (l2.has_lock() { boost::unique_lock<boost::mutex> l3(m3, t); if (l2.has_lock() { foo(); polling = false; } else execute_on_failed(); } else execute_on_failed(); } else execute_on_failed(); } and now with exceptions while (polling) try { t=now()+100; boost::exception_unique_lock<boost::mutex> l1(m1, t); boost::exception_unique_lock<boost::mutex> l2(m2, t); boost::exception_unique_lock<boost::mutex> l3(m3, t); foo(); polling = false; } catch (timeout_exception& ex) {execute_on_failed(); } What do you think about a try_lock_until, try_lock_for functions while (polling) try { boost::try_lock_for(100, m1, m2, m3); foo(); polling = false; } catch (timeout_exception& ex) {execute_on_failed(); } Best, Vicente

4 6

[Fwd: [ublas] why is there no constructor that fills the matrix with a default value]
by Thorsten Ottosen 20 Jan '09

20 Jan '09

I didn't get any response to this, so I'll try again. Thanks -Thorsten

3 2

[test] Warnings and EDG compiler error patch.
by John Maddock 20 Jan '09

20 Jan '09

Geniydi, I hope you don't mind, but I'm about to apply the attached trivial patch to Boost.Test in Trunk to: 1) Quieten a minor blizzard of msvc warnings. 2) Get the code compiling with Intel C++. Regards, John.

2 2

How to structurate libraries ?
by Joel Falcou 20 Jan '09

20 Jan '09

I may have a few components to propose as library. They mostly deals with low-level, architecture-dependant problems that get homogeneized across compiler/platform. Things like class for padding a type to a given boundary, SIMD computation DSEL, traits concerning low-level properties of types and/or compilers and some more. What's the best way to handle this ? A series of small-scale libraries or a larger framework like boost::architecture or something ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

11 33