May 2008 - Boost - lists.preview.boost.org

Compilation error in mutex.hpp
by Stas Khirman 13 May '08

13 May '08

Just found a compilation problem in include/boost-1_35/boost/pool/detail/mutex.hpp line 67. While compiling with VS2005 under WinXp, got compilation error "C2872: 'CRITICAL_SECTION' : ambiguous symbol". ( project is quite complicated, with many includes and soon) Fix is trivial: ::CRITICAL_SECTION mtx; // note "::" to resolve symbol mix-up.

1 0

How to review futures?
by John Phillips 13 May '08

13 May '08

I'm looking to see if there are any good ideas for how to review the two futures libraries that are both currently in the queue. Since they are two different approaches to the same problem domain, isolated sequential reviews does not seem to be a good idea. So far, the best thought I've had on the subject is to run a single review that includes both libraries, where it is explicitly part of the review to discuss which parts of which realizations are the best choice. This process will need to keep the proposals before the committee in mind, but it is a way to compare and contrast the strengths of the two in close proximity. If we do this, there are a couple of questions that should be added to the usual review process. * Which interface choices are best suited to the problem domain? * Should Boost offer competing implementations of this feature? * Should the libraries be melded together? * Should a subset of the approved library be restricted to only the facilities and interface in the standardization committee proposal? There are my initial thoughts. I would like to hear from others on this, as well. I especially would like to hear from the authors and from anyone who has been involved in the evolving standards proposal. Thanks for your ideas. John Phillips Review Wizard

5 7

[smart_ptr] Proposal to add new_shared function
by Andrey Semashev 12 May '08

12 May '08

Hi, I've seen this topic floating around but it seems it didn't make it into boost for some reason. I propose to add a new helper function for shared_ptr, namely new_shared. The function would dynamically allocate an object and return shared_ptr that points to it. The function provides the following benefits: - It may perform better than allocating the object and constructing shared_ptr explicitly. Obviously, it allows to get rid of the additional allocation for the counter object. - The function is effectively a safer replacement for the core operator new. It solves the frequently missed memory leak pointed out by Meyers: foo(shared_ptr< A >(new A), bar()); I've made a quick implementation that supports the following: - Arbitrary number of constructor arguments. C++0x features (variadic templates and rvalue references) are supported in addition to the traditional and more limited C++03 version. - Support for custom deleters, which are now more "destroyers" because a deleter used with the new_shared function should not free memory from the destroyed object. - Support for custom allocators. It is through allocators the memory for both the object and the counter are allocated and deallocated. - The shared_ptr implementation is intact, the new feature is a pure addition (however, it could be made a bit more effective with a little help from shared_ptr). The implementation is available in the Vault: http://tinyurl.com/6sxtpg Some quick examples of use: shared_ptr< A > p1 = new_shared< A >(); // default ctor shared_ptr< B > p2 = new_shared< B >(x, y, z); // parametrized ctor shared_ptr< C > p3 = new_shared< C >(ref(x)); // passing references // using custom deleter shared_ptr< D > p4 = new_shared< D >(use_deleter(d)); // using custom allocator shared_ptr< E > p5 = new_shared< E >(use_allocator(a)); // you can mix the above cases shared_ptr< F > p6 = new_shared< F >( use_deleter(d), use_allocator(a), x, ref(y)); shared_ptr< G > p7 = new_shared< G >( use_allocator(a), use_deleter(d), z); The use_allocator and use_deleter arguments may be in either order, but must be the first arguments of new_shared, if used. Do you think this would be a reasonable addition to Boost.SmartPtr?

2 2

GCC Visibility Support
by Steven Dodd 12 May '08

12 May '08

I think it would be worthwhile to extend Boost to support GCC's (relatively) new visibility features. For those unfamiliar with GCC's visibility features, please read the following articles for background: http://gcc.gnu.org/wiki/Visibility http://developer.apple.com/technotes/tn2007/tn2185.html Please forgive any ignorance displayed in the following proposal - I'm new to Boost, and only more-so to Boost library development! I've reviewed all of the messages I could find on the mailing list related to this subject, but didn't see one that provided a comprehensive proposal for adding full visibility support. So here goes: There are essentially two use-cases which need to be addressed: ( 1 ) Compiling Boost with restricted visibility In this case, the user wants to gain the full benefits of restricted symbol visibility, and so they want to compile both their own code and Boost with restricted symbol visibility. That is, they want to build Boost with some combination of the GCC flags: -fvisibility=hidden, -fvisibility-inlines-hidden, and -fvisibility-ms-compat (OS X specific). In order to build Boost properly with restricted symbol visibility, Boost needs to be configured to mark all public symbols as such. On Windows, Boost already does this by (A) defining BOOST_HAS_DECLSPEC in <config/platform/win32.hpp>, and (B) defining and using library-specific _DECL macros (e.g. BOOST_FILESYSTEM_DECL = __declspec(dllexport) or __declspec(dllimport) depending on whether the library is being built, or used). What needs to be done to support GCC's symbol visibility restriction is to generalize the support already in place for Windows, along the following lines: - Rename BOOST_HAS_DECLSPEC to BOOST_HAS_SYM_CONTROL, and define this symbol in appropriate config headers. For GCC, this should be an optional feature, and I'm not sure of how to best allow users to enable/disable it (e.g. how to integrate it as a Boost.Build option). Change all locations to use the new name. - Introduce macro, BOOST_SYM_EXPORT, and define as __declspec(dllexport) on Windows, and as __attribute__((visibility("default"))) for GCC. Change all locations currently hard-coding __declspec( dllexport ) to use BOOST_SYM_EXPORT instead. - Introduce macro, BOOST_SYM_IMPORT, and define as __declspec(dllimport) on Windows, and as __attribute__((visibility("default"))) for GCC. Change all locations currently hard-coding __declspec( dllimport ) to use BOOST_SYM_IMPORT instead. This approach should work "out-of-the-box" when using GCC's -fvisibility-ms-compat mode (MSVC++ compatibility mode), since it already works on Windows. However, this approach will likely be incomplete when using GCC's -fvisibility=hidden mode. Reason being, unlike the visibility-ms-compat mode, this mode does not automatically mark types with "vague linkage" as visible (e.g. type_info). As a result, exceptions thrown in one DSO will not be caught in other DSOs. It is beyond my understanding of Boost to propose a comprehensive set of changes required to address the problem. ( 2 ) Compiling Boost with normal visibility, but enabling linkage into user-code compiled with restricted visibility In this case, the user wants to build their own code with restricted symbol visibility, but wants to link against a copy of Boost compiled with default visibility (e.g. most likely, a pre-built Boost binary). Presently, upon doing so, the user will find themselves faced with a slew of linker warnings regarding the mismatch in visibility levels between Boost symbols compiled into user-code vs. in the Boost libraries. In order to resolve this issue properly (e.g. not just silence the linker), Boost needs to be modified to wrap all Boost types in "default" visibility instructions, like so: #pragma GCC visibility push(default) ... boost types ... #pragma GCC visibility pop Boost's existing ABI facility is sufficient for this task, were it employed consistently by all Boost libraries (unfortunately, as far as I can tell, it is not): - Create file <boost/config/abi/gcc_default_visibility_prefix.hpp> with the following contents: #pragma GCC visibility push(default) - Create file <boost/config/abi/gcc_default_visibility_suffix.hpp> with the following contents: #pragma GCC visibility pop - In the appropriate config header, define BOOST_ABI_PREFIX as "boost/config/abi/gcc_default_visibility_prefix.hpp", define BOOST_ABI_SUFFIX as "boost/config/abi/gcc_default_visibility_suffix.hpp", and define BOOST_HAS_ABI_HEADERS. Note: this should be the default for GCC, however, if the user has requested restricted symbol visibility, as in use-case (1), then these BOOST*ABI macros must not be defined, or the prefix/suffix headers at least need to conditionally define the visibility based on some other macro definition... I look forward to comments! Cheers, Steven Dodd sdodd<at>view22<dot>com

1 0

[graph] [serialization] serialized descriptors
by Carlos Rafael Giani 12 May '08

12 May '08

Hello, there is utility code for serializing an adjancency_list graph to an archive in the BGL. But I wonder about two things: 1) I have a list of descriptors in my program. This list is a selection of vertices. If I want to serialize my program's states, I need to serialize the graph as well as this selection. This means I have to serialize references to vertices. Now AFAIK I cannot simply serialize descriptors, because they essentially are pointers. I need a persistent ID. Is there existing functionality for this? If not, I have to either use one of the vertex properties as ID, or autogenerate IDs (for example, by using casting the descriptors to an intptr_t and using this value as ID) and upon deserialization use these for mapping the right descriptors back into the list. 2) One vertex property is a map of boost::any values. map < string, any > to be exact. Does the BGL serialize the properties? If so, how does it deal with boost::any constructs?

2 2

[thread] thread_group create_thread template function
by vicente.botet 12 May '08

12 May '08

Hi, the thread_group::create_thread takes a const function0<void> parameter: thread* create_thread(const function0<void>& threadfunc); The function0 implies already a memory allocation. The templated version look like: template <class Threadable> thread* thread_group::create_thread(Threadable threadfunc) { // No scoped_lock required here since the only "shared data" that's // modified here occurs inside add_thread which does scoped_lock. std::auto_ptr<thread> thrd(new thread(threadfunc)); add_thread(thrd.get()); return thrd.release(); } Which works faster because no need to allocate memory for the boost::function0<void()>. Anthony, if there is nothing wrong, could this substitute the create_thread function in next Boost::thread release? Best regards _____________________ Vicente Juan Botet Escriba

2 2

GCC 4.3/ia64 build of 1.35 fails on polymorphic_iarchive
by Steve M. Robbins 12 May '08

12 May '08

Bernd, Did you solve the issue reported in [1]? The Debian build for ia64 fails in the same way [2]: In file included from libs/serialization/src/polymorphic_iarchive.cpp:18: ./boost/archive/polymorphic_iarchive.hpp:88: error: 'virtual void boost::archive::polymorphic_iarchive_impl::load(int64_t&)' cannot be overloaded ./boost/archive/polymorphic_iarchive.hpp:84: error: with 'virtual void boost::archive::polymorphic_iarchive_impl::load(long int&)' ./boost/archive/polymorphic_iarchive.hpp:89: error: 'virtual void boost::archive::polymorphic_iarchive_impl::load(uint64_t&)' cannot be overloaded ./boost/archive/polymorphic_iarchive.hpp:85: error: with 'virtual void boost::archive::polymorphic_iarchive_impl::load(long unsigned int&)' ...failed gcc.compile.c++ bin.v2/libs/serialization/build/gcc-4.3.1/release/polymorphic_iarchive.o... [1] http://article.gmane.org/gmane.comp.lib.boost.devel/172455 [2] http://buildd.debian.org/fetch.cgi?&pkg=boost1.35&ver=1.35.0-1&arch=ia64&st… Thanks, -Steve

1 0

[thread] is this reverse_lock class a source of errors?
by vicente.botet 11 May '08

11 May '08

Hi, Consider the following situations: { unique_lock<mutex> lock(smtx); // ... some writing operations { // non locked block reverse_lock< unique_lock<mutex> > rlock(lock); // ... some code not needing the mutex to be locked } // locked again // ... } or { shared_lock<mutex> lock(smtx); // ... some reading operations { // non locked block reverse_lock< shared_lock<mutex> > rlock(lock); // ... some code not needing the mutex to be locked } // locked again // ... } Do you think this usage is souhaitable or is this source of errors? The class reverse_lock can be defined as follows: template <typename Locker> class reverse_lock { BOOST_CONCEPT_ASSERT((MovableLockConcept<Locker>)); public: reverse_lock(Locker& locker) : locker_(locker) /*< Store reference to locker >*/ , tmp_locker_(locker.move()) /*< Move ownership to temporaty locker >*/ , was_locked_(false) { #ifndef BOOST_SYNC_REVERSE_LOCK_DONT_CHECK_OWNERSHIP /*< Define BOOST_SYNC_REVERSE_LOCK_DONT_CHECK_OWNERSHIP if you don't want to check locker ownership >*/ if (tmp_locker_.mutex()==0) { locker_=tmp_locker_.move(); /*< Rollback for coherency purposes >*/ throw lock_error(); } #endif if (tmp_locker_) { /*< ensures it is unlocked >*/ tmp_locker_.unlock(); was_locked_=true; } } ~reverse_lock() { if (was_locked) { tmp_locker_.lock(); } locker_=tmp_locker_.move(); /*< Move ownership to nesting locker >*/ } private: Locker& locker_; Locker tmp_locker_; bool was_locked_; reverse_lock(); }; Comments? _____________________ Vicente Juan Botet Escriba

5 6

[future] Integrating recent future lib into old-ish threadpool lib
by Chris Fairles 10 May '08

10 May '08

There's a nice threadpool library (http://threadpool.sourceforge.net) mentioned on a previous thread that I took a look at and noticed it had a basic future impl. of its own. Given that there's a future library under review, I swapped out the original future impl. in the schedule function, plus added a lazy_schedule (from the examples @ http://braddock.com/~braddock/future/ ) for fun. I replaced everything in future.hpp from the threadpool lib with: /* * Copyright (c) 2005-2007 Philipp Henkel * * Use, modification, and distribution are subject to the * Boost Software License, Version 1.0. (See accompanying file * LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) * * http://threadpool.sourceforge.net * * Chris Fairles, May 2008 - Modified to replace custom future implementation with boost-reviewed version */ #pragma once #include <boost/future/future.hpp> namespace boost { namespace threadpool { template<class Pool, class F> future<typename result_of< F() >::type> schedule(Pool& pool, F const& task) { typedef typename result_of< F() >::type result_type; promise<result_type> prom; pool.schedule(future_wrapper<result_type>(task, prom)); return future<result_type> (prom); } template<class Pool, class F> future<typename result_of< F() >::type> lazy_schedule(Pool& pool, F const& task) { typedef typename result_of< F() >::type result_type; promise<result_type> prom; future<void> guard = prom.get_needed_future(); guard.add_callback(bind(&Pool::schedule, pool, future_wrapper<result_type>(task, prom))); return future<result_type> (prom); } } } // namespace boost::threadpool where #include <boost/future/future.hpp> is the header for the lib under review (and pardon the pragma windowism). I haven't tested it throughly but on msvc9, the most trivial of cases work (including catching exceptions) so YMMV. Ex. int task_int_1() { throw std::exception("task_int_1 exception"); return 1; } int task_int_2() { return 2; } int main() { pool tp; tp.size_controller().resize(2); future<int> result1 = schedule(tp, &task_int_1); future<int> result2 = schedule(tp, &task_int_2); try { int val = result1 + result2; std::cout << "you will never see this value... " << val << std::endl; } catch (std::exception const& ex) } std::cerr << ex.what() << std::endl; } } Something to play around with anyway. Cheers, Chris

1 0

[thread] lockable traits and concepts classes adding proposal
by vicente.botet 10 May '08

10 May '08

Hello boosters , While writtig a synchronization library I have needed some lockable traits and concepts. If you think that these classes are of general use it will be a pleasure for me, if Anthony accepts, to included them on the Boost.Thread library. Otherwise I will left them in my sync library. For the moment all is defined in a sync (as synchronization) namespace and directory but this is without importance. Attached a short introduction as well as the header files. Of course all this is subject to discusion, naming and file structure changes, ... For each one of the mutex in the thread library, we need to * make the mutex inherit from the helper lock_traits_base or * have nested typedefs or * specialize each one of the traits templates As an external library I have do this in a non-intrusive way as for example: template<> struct timed_interface_tag<boost::mutex> { typedef hasnt_timed_interface_tag type; }; template<> struct reentrancy_tag<boost::mutex> { typedef non_recursive_tag type; }; template<> struct category_tag<boost::mutex> { typedef exclusive_lock_tag type; }; template<> struct scope_tag<boost::mutex> { typedef multi_threaded_tag type; }; But if included in the Thread library it will be better to use one of the intrusive methods. I have also other classes that could be of general interest. * A make_..._lockable set of mixin class will make lockable the derived class. It can be used as follows: class X : public make_exclusive_lockable<X, boost::mutex> { } X x; unique_lock<X> lock(x); * a ..._synchronization_family set of classes that can be used as follows: template <class SyncFamily> message_queue; typedef message_queue<thread_synchonization_family> my_mt_message_queue; typedef message_queue<null_synchonization_family> my_st_message_queue; The null_synchonization_family needs a null_mutex and a null_condition classes. * To finish, I'm working on a filter_matching_lockables meta-function which take as parameter a vector of lockables types and will filter the lockables types not satisfying a list of traits. The use shoul be somthing like typedef filter_matching_lockables<vector<boost::mutex, boost::recursive_mutex, ...>, and_<is_exclusive_lock<_>, not_<is_recursive_lock<_> > >::type candidates. and a find_best_lock which choose between the lockables given as parameter the best one following a given criterium. Of course, there is yet a lot of work to complete, add lock concepts, document, tests, document, tests ... between others, that I will be please to do even if included in the Thread library. As you see there is nothing new, neither complex, only some helper classes that currently are missing in boost. Have a good code reading and please let me know what do you think. _____________________ Vicente Juan Botet Escriba

1 0