- Boost - lists.boost.org

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

Futures - Reviews Needed (January 5, 2009)
by Tom Brinkman 19 Jan '09

19 Jan '09

Futures Join the review and discussion starting January 5, 2009. I need commitments for reviews from threading experts on the two Futures library candidates. Braddock Gaskill - http://braddock.com/~braddock/future Anthony Williams - http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp Early comments are welcome.

9 16

Lazy list
by Zachary Turner 19 Jan '09

19 Jan '09

It occured to me that boost is lacking a true lazy list. I feel like this should be possible to implement on most compilers, although I doubt I have the metaprogramming expertise to be able to implement such a data structure myself. But nonetheless I think this would be extremely useful. Lazy lists are basically lists that don't store the actual values of the list, instead they store a -function- that is called each time the next element of the list is requested, and the result of that list is returned. Most likely there is a caching mechanism as well, so that accessing recently accessed (or preceding) elements would return a cached value if it had already been accessed. I guess it would not cache arbitrarily large amounts of elements though for memory usage reasons, otherwise it would defeat the whole purpose, which is the ability to expose truly infinite sequences to the user in the form of a list. Has this been considered before, and can anyone think of any technical limitations that would prevent such a class to be written?

8 13

[filesystem] operator == performance
by Konstantin Litvinenko 19 Jan '09

19 Jan '09

Hi! I am developing an application with very intensive boost::filesystem::path usage. At certain moment application start to be slowly and I start profiler. Profiler shows me that std::map<fs:path, ....> is painfully slow due path::operator <() that do lexicographical compare , that do void iterator_helper<Path>::do_increment( iterator & itr ) that is really slow. So I have replaced std::map on boost::unordered_map.. and didn't get expected performance gain. Profiles show me that path::operator <() hit count 200000 and now only 100000. That tooooo much. Further investigation shows that problem was path::operator ==() used in unordered_map. I understand that operator == can be implemented using strict weak ordering concept, but for filesystem::path. Why not implement it as: bool path::operator == (const path& lhs, const path& rhs) const { return lhs.string() == rhs.string(); } ?

2 2