- Boost - lists.boost.org

[Fusion][Parameter] Some unused parameters warning in gcc
by Joel Falcou 05 Jul '10

05 Jul '10

Following files have obnoxious warnings due to unused parameters. Fix is trivial. trunk/boost/fusion/sequence/intrinsic/has_key.hpp line 70 trunk/boost/fusion/algorithm/query/detail/any.hpp line 112 trunk/boost/parameter/aux_/tagged_argument.hpp trunk/boost/parameter/parameters.hpp Will put up trac item+patches soon

1 0

[thread] A few submissions
by Andrey Semashev 05 Jul '10

05 Jul '10

Hi, I would like to propose the following components for inclusion into Boost.Thread: 1. Once-blocks. This is a flavor of the "once" concept. One can define a block of code that should be executed only once, like that: void foo() { BOOST_LOG_ONCE_BLOCK() { puts("Hello, world once!"); } } The code within the block can access names (e.g. variables) as if it was a usual code block. Why not call_once: * The once-code is defined in-place, which greatly simplifies usage in many cases. One of the main goals of the "once" concept is the dynamic initialization, which involves the variables being initialized. With once-blocks there is no need bind these variables into a functor. Once-blocks are also easier to be used within a macro. * The resulting code is much shorter since the thread synchronization code is separated from the once-code. call_once is instantiated with each once-functor, although the synchronization code is the same. * The once-flag is smaller on Windows. In fact, unlike call_once, the behavior on Windows is equivalent to POSIX. * It has ticket #4225 fixed. If this component is accepted, I would also like to port call_once to once-blocks. Source code: <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/libs/…> 2. Lightweight read/write mutex. Basically, I want a portable analogue for pthread_rwlock_t, with minimum dependencies, code size and memory footprint. Naturally, it is compatible with Boost.Thread locks. Why not shared_mutex: * shared_mutex.hpp depends on a lot of other headers. It brings in a great deal of Boost.DateTime, although I don't need the timed methods at all. * It offers more than I ever use. I don't need upgradeability. * It is larger than pthread_rwlock_t on POSIX systems (on Linux x64 it's 192 bytes vs 56). On Windows NT 6 it can be implemented through SRWLOCK, which is of size of one pointer. * I remember there were reports that shared_mutex is slower than pthread_rwlock_t. But I haven't done testing, so I won't press it. Source code: <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/libs/…> 3. Lightweight thread-local storage for small POD values. Allows to store POD values of size up to sizeof(void*) with least possible overhead, memory and performance-vise. thread_specific< int > tls; Why not thread_specific_ptr: * thread_specific_ptr performance depends on the total number of ptrs within the application as it involves an additional lookup among them on access. thread_local does nothing more than abstracting away the native API for TLS, so it provides better performance. * thread_specific_ptr requires to dynamically allocate memory even for tiniest things, like bool or int. This is inconvenient and awkward, especially when memory and exception safety matters. <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/libs/…> A few notes up-front. There are extensions in some compilers for TLS support. It offers even better performance and easier to use. Also, C++0x will bring this feature into the language. But: * It is known to have problems with dynamically-loaded modules. * It is not portable. Even when C++0x it out, not all compilers will support it right away. * thread_specific does not require the variable to have a static storage duration. 4. shared_lock_guard. A light analogue to shared_lock, which allows to generate a more efficient code. Ticket #3567. Source code: <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> As a part of this addition I would like to improve segregation of boost/thread/locks.hpp by extracting every component within it into a separate header in a new "locks" directory. 5. The strictest_lock metafunction. Given the list of lock types, it selects the one that offers the strictest concurrency guarantees (i.e. shared lock is stricter than no lock at all, exclusive lock is stricter than shared lock). This metafunction can be useful in generic code, where the final lock type must be deduced. Source code: <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> I understand that some of these tools might seem specific to my case, but I think they could be useful in general. If any of these tools is accepted into Boost.Thread, the code is not set in stone - namings and implementation details can be changed, if needed. I can do the code transition, write docs and a few tests, if needed. Just let me know if either of these is of interest and whether I am allowed to do so. PS: If you want SVN access to all these things, it is available on the SourceForge: <http://sourceforge.net/scm/?type=svn&group_id=199644>

3 14

Bug Sprint merge from trunk to release branche
by vicente.botet 05 Jul '10

05 Jul '10

Hi maintainers, have you merged the tickets solved in trunk branch during the last Bug Sprint? If not, it will be very kind of you to do this before the release branche is frozen. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

Changelog
by David Bellot 04 Jul '10

04 Jul '10

Hi everybody, I'm a new maintainer for ublas and before the deadline on monday, I still have a last question: we made a few changes in ublas for 1.44 and I would like to report them to the boost official changes. However, I don't know where to write my information ? Is there a file or do I have to send an email to the boost release managers ? Cheers, David -- David Bellot, PhD david.bellot(a)gmail.com http://david.bellot.free.fr

2 1

[Docs] Should remove_pointer doc make mention of and link to pointee doc?
by Mostafa 03 Jul '10

03 Jul '10

Hi all, Shouldn't the remove_pointer doc [tinyurl.com/336cmlp] under type_traits library make mention of and link to the pointee doc [http://tinyurl.com/339n3f4]? (I must say that I've been wholly ignorant of the latter in the couple of years that I've been using boost, since I always expected it to be under type_traits.) Additionally, it would be great if it was explained why it's not part of the type_traits library, since, at least I believe, it's not very obvious. One last question, why is pointee under the iterator library docs, when it also deals with shared_ptrs? Shouldn't it fall under the utility doc? (The iterator doc would be the last place I would look if I wanted to find something on shared_ptrs.) Thanks, -Mostafa

2 2

[mpi] Boost.MPI broken
by Jeremiah Willcock 03 Jul '10

03 Jul '10

Almost all of the regression tests for Boost.MPI on the Boost trunk are failing, and this is leading to failures in Boost.Graph.Parallel as well. Is this a known problem? Could someone please work on fixing it? Thank you. -- Jeremiah Willcock

8 15

[BGL] BGL named parameters - how to proceed?
by Daniel Trebbien 02 Jul '10

02 Jul '10

Hello all, I am writing documentation for my implementation of the Stoer–Wagner min-cut algorithm. Attached is an HTML file of what I have so far, which also outlines how I would like the interface of `stoer_wagner_mincut` using named parameters to be. How do I proceed in adding support for BGL named parameters `weight_map`, `parity_map`, `vertex_index_map`, `assignment_map`, `index_in_heap_map`, and `wA_map`? I have looked through sources of other BGL algorithms and am not sure how the named parameters functionality works, let alone how to add it to my code. Daniel

2 2

Query on the Boost Library Support
by Alapkumar Sinha 02 Jul '10

02 Jul '10

Hi, I am analyzing the different IPC mechanism of Boost. Can someone help me with the following queries? 1. Is there something available in boost similar to windows "events". I mean where one thread can wait on one event and another thread signals the event. I was going through Boost.signals2, but it seems more of a function call back. 2. Is there support for FIFO, PIPE & POSIX signals Thanks, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

3 2

spirit mini_c example 1 broken
by Dirk Griffioen 02 Jul '10

02 Jul '10

Hi, (Sorry if this is the wrong list) The mini_c example 1 in Boost.Spirit v2.3 seems to be broken: all I get is a Error! Expecting <statement-list> here: " int a = 2; And with some debugging added it says: <statement-list> <try>\n int a = 2;\n </try> <statement> <try>\n int a = 2;\n </try> <variable-declaration> <try>\n int a = 2;\n </try> <fail/> </variable-declaration> <assignment> <try>\n int a = 2;\n </try> <variable-reference> <try>\n int a = 2;\n </try> <fail/> </variable-reference> <fail/> </assignment> <fail/> </statement> <fail/> </statement-list> Error! Expecting <statement-list> here: " int a = 2; I am a bit confused now, as it is straight from the examples ... and my guess is it should work. Any hints? Best, Dirk

1 0

svn-commit mail failing
by Thomas Heller 02 Jul '10

02 Jul '10

Hi, I just noticed that the svn commit mailing list seems to have some problems. The last commit notification I got was from revision 63466. The current revision is 63522. Can someone confirm?

1 0