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

[filesystem] thread safety on msvc 2010
by Jacob Schloss 28 Jan '13

28 Jan '13

Hi, I've been having some crashes in my code due to concurrent creation of boost::filesystem::path objects on several threads. The issue in short looks like function member static variable initialization is not thread safe in msvc 2010, but is in GCC. The main issue is with the construction of the std::locale and codecvt objects, I get crashes when some threads try to use a partially constructed instance of std::locale. I posted some details of my issue and possible fix at the end of bug 6320 https://svn.boost.org/trac/boost/ticket/6320, and would like to clean it up into a patch for consideration. Right now, I was looking at using boost::thread call_once to synchronize the std::locale and codecvt initialization code. I'm running locally with a boost::thread::call_once patch, and it seems to work for some simple test cases. I'd appreciate any thoughts, or pointers if anyone has worked on this issue, I saw some discussion at http://lists.boost.org/Archives/boost/2011/12/189183.php but it did not seem to move forwards. Thanks, Jacob Schloss

3 2

[1.53.0 beta] [type_traits] is_POD
by Cromwell Enage 28 Jan '13

28 Jan '13

Hi, all! I found out that Boost.TypeTraits defines a metafunction called is_POD that is essentially a template alias of is_pod, but it isn't documented. In particular, the documentation needs to mention that is_POD must be overridden in the same cases that is_pod must be overridden. Cromwell D. Enage

4 4

[accumulator] any news on serialization?
by Neal Becker 27 Jan '13

27 Jan '13

Last I heard was this: http://lists.boost.org/boost-users/2008/06/37586.php

2 1

[interprocess] [bimap] Using raw pointers
by Matias Capeletto 27 Jan '13

27 Jan '13

Hello, Currently Boost.Bimap does not work with interprocess allocators because it uses references to connect the views and the core. I want to change this but avoid any performance hit and I am wondering what is the best way to do it. It will be easy if Bimap interface will use .left() and .right() functions to access the map views (then I could just init the views at each call like Boost.MultiIndex get() index function does) but I am stuck with the left and right members (and I actually like them). So, what I want to be able to do is the following: template<class Bimap> class left_type { Bimap* core; public: left_type(Bimap* c) : core(c) {}; ... }; template<class Bimap> class right_type {...}; template<class LeftKey,class RightKey> class bimap { public: left_type<bimap> left; right_type<bimap> right; bimap() : left(this), right(this) {} }; This will not work because I am not using the proper offset_pointer abstraction, but I would love to be able to avoid it. In the case of Bimap, these pointers are very easy to maintain. Will it be possible to add an extension point to Boost.Interprocess to allow this idiom? Something like adding a call to the end of priv_find_impl of segment_manager so user classes can rewire themselves when they are loaded from shared memory. For example: template<class T> void rewire_after_loading_from_shared_memory(T* t) { } ... template <class T> std::pair<T*, size_type> priv_find_impl (const CharType* name, bool lock) { // find ret pointer T* t_ret = static_cast<T*>(ret) ; if( t_ret ) rewire_after_loading_from_shared_memory( t_ret ); return std::pair<T*, size_type>(t_ret ,sz); } ... Or maybe a better place. Then I will be able to rewire the map views pointers to the core if they are different from it: template<class L, class R> void rewire_after_loading_from_shared_memory(bimap<L,R>* t) { t->rewire(); } If this is not possible because inherent limitations of the interprocess mechanisms, do you know a good way to make Boost.Bimap compatible with its allocators? Thanks, Best regards Matias

3 12

program_options: Support for open-end options
by ST 27 Jan '13

27 Jan '13

Hi, It would be great to implement support for open-end options, something like that: item_1 = 23 item_2 = 45 ... item_N = 465 The idea is to to be able to provide following input: configOptions.add_options() ("item_", value<int>(), "items"); now if add_options() sees a key that ends with a "_" it accepts all options with keys that start with item_, no matter what comes after it, and treat all of them as int . Nesting should also be possible - like this: "item_.subitem_.subsubitem_" (item_3.subitem_FOO.subsubitem_34 should be a valid option key). I can try to implement it, however only if it will have a chance to be merged into the boost library. Whom should I contact regarding this? Thank you, Simone

5 13

New algorithm in Boost.Algorithm: "gather" -- looking for comments
by Marshall Clow 27 Jan '13

27 Jan '13

I have committed a new algorithm named "gather" into Boost.Algorithm. Actually, it's one I wrote for Sean Parent as part of ASL about five years ago, and it's the first (of hopefully many) of the bits oF ASL to be moved into boost. Here's a summary: gather() takes a collection of elements defined by a pair of iterators and moves the ones satisfying a predicate to them to a position (called the pivot) within the sequence. The algorithm is stable. The result is a pair of iterators that contains the items that satisfy the predicate. template <typename ForwardIterator, typename Pred> std::pair<ForwardIterator,ForwardIterator> gather ( ForwardIterator first, ForwardIterator last, ForwardIterator pivot, Pred pred ); Given an sequence containing: int [] arr = { 0 1 2 3 4 5 6 7 8 9 }; A call to gather ( arr, arr + 10, arr + 4, IsEven) will result in: 1 3 0 2 4 6 8 5 7 9 |---|-----| first | second pivot where first and second are the fields of the pair returned by the call. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

8 12

[context] permission to merge to release
by Oliver Kowalke 26 Jan '13

26 Jan '13

I'd like to ask to merge boost.context to boost.release - adding support for SPARC. Unfortunately we have no regression tests on trunk/release but I got the info that the code in trunk works for 32bit/64bit SPARC. regards, Oliver

2 1

[1.53.0] Release Notes
by Daniel James 26 Jan '13

26 Jan '13

Hello everyone, Please can you send me your library's release notes for 1.53. Or if you prefer you can add them yourself to: http://svn.boost.org/svn/boost/website/public_html/live/feed/history/boost_… thanks, Daniel

9 13

[utility] base_from_member variadic template error on gcc-4.6.0 c++0x
by Vicente Botet 26 Jan '13

26 Jan '13

Hi, I'm getting the following compiler error. gcc.compile.c++ ..\..\..\bin.v2\libs\chrono\test\stopwatch_reporter_example_h.test\gcc-mingw-4.6.0x\debug\stopwatch_reporter_example.o In file included from ..\..\../boost/format/alt_sstream.hpp:20:0, from ..\..\../boost/format/internals.hpp:23, from ..\..\../boost/format.hpp:38, from ..\..\../boost/chrono/stopwatches/formatters/elapsed_formatter.hpp:13, from ..\..\../boost/chrono/stopwatches/reporters/clock_default_formatter.hpp:11, from ..\..\../boost/chrono/stopwatches/reporters/stopwatch_reporter_default_formatter.hpp:11, from ..\..\../boost/chrono/stopwatches/reporters/stopwatch_reporter.hpp:23, from ..\example\stopwatch_reporter_example.cpp:10: ..\..\../boost/utility/base_from_member.hpp: In constructor 'boost::io::basic_oaltstringstream<Ch, Tr, Alloc>::basic_oaltstringstream(boost::io::basic_oaltstringstream<Ch, Tr, Alloc>::stringbuf_t*) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, boost::io::basic_oaltstringstream<Ch, Tr, Alloc>::stringbuf_t = boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> >]': ..\..\../boost/format/feed_args.hpp:175:57: instantiated from 'void boost::io::detail::put(T, const boost::io::detail::format_item<Ch, Tr, Alloc>&, typename boost::basic_format<Ch, Tr, Alloc>::string_type&, typename boost::basic_format<Ch, Tr, Alloc>::internal_streambuf_t&, boost::io::detail::locale_t*) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const boost::io::detail::put_holder<char, std::char_traits<char> >&, typename boost::basic_format<Ch, Tr, Alloc>::string_type = std::basic_string<char>, typename boost::basic_format<Ch, Tr, Alloc>::internal_streambuf_t = boost::io::basic_altstringbuf<char, std::char_traits<char>, std::allocator<char> >, boost::io::detail::locale_t = std::locale]' ..\..\../boost/format/feed_args.hpp:286:17: instantiated from 'void boost::io::detail::distribute(boost::basic_format<Ch, Tr, Alloc>&, T) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const boost::io::detail::put_holder<char, std::char_traits<char> >&]' ..\..\../boost/format/feed_args.hpp:296:9: instantiated from 'boost::basic_format<Ch, Tr, Alloc>& boost::io::detail::feed_impl(boost::basic_format<Ch, Tr, Alloc>&, T) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const boost::io::detail::put_holder<char, std::char_traits<char> >&]' ..\..\../boost/format/feed_args.hpp:308:95: instantiated from 'boost::basic_format<Ch, Tr, Alloc>& boost::io::detail::feed(boost::basic_format<Ch, Tr, Alloc>&, T) [with Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, T = const boost::io::detail::group1<boost::io::detail::group4<std::ios_base& (*)(std::ios_base&), std::_Setprecision, boost::chrono::duration_fmt, const boost::chrono::duration<double, boost::ratio<1ll, 1000ll> >&> >&]' ..\..\../boost/format/format_class.hpp:64:74: instantiated from 'boost::basic_format<Ch, Tr, Alloc>& boost::basic_format<Ch, Tr, Alloc>::operator%(const T&) [with T = boost::io::detail::group1<boost::io::detail::group4<std::ios_base& (*)(std::ios_base&), std::_Setprecision, boost::chrono::duration_fmt, const boost::chrono::duration<double, boost::ratio<1ll, 1000ll> >&> >, Ch = char, Tr = std::char_traits<char>, Alloc = std::allocator<char>, boost::basic_format<Ch, Tr, Alloc> = boost::basic_format<char>]' ..\..\../boost/chrono/stopwatches/formatters/elapsed_formatter.hpp:83:9: instantiated from 'void boost::chrono::basic_elapsed_formatter<Ratio, CharT, Traits, Alloc>::operator()(Stopwatch&) [with Stopwatch = boost::chrono::basic_stopwatch_reporter<char, boost::chrono::strict_stopwatch<boost::chrono::steady_clock>, boost::chrono::basic_elapsed_formatter<boost::ratio<1ll, 1000ll>, char> >, Ratio = boost::ratio<1ll, 1000ll>, CharT = char, Traits = std::char_traits<char>, Alloc = std::allocator<char>]' ..\..\../boost/chrono/stopwatches/reporters/stopwatch_reporter.hpp:88:9: instantiated from 'void boost::chrono::basic_stopwatch_reporter<CharT, Stopwatch, Formatter>::report() [with CharT = char, Stopwatch = boost::chrono::strict_stopwatch<boost::chrono::steady_clock>, Formatter = boost::chrono::basic_elapsed_formatter<boost::ratio<1ll, 1000ll>, char>]' ..\..\../boost/chrono/stopwatches/reporters/stopwatch_reporter.hpp:82:11: instantiated from 'boost::chrono::basic_stopwatch_reporter<CharT, Stopwatch, Formatter>::~basic_stopwatch_reporter() [with CharT = char, Stopwatch = boost::chrono::strict_stopwatch<boost::chrono::steady_clock>, Formatter = boost::chrono::basic_elapsed_formatter<boost::ratio<1ll, 1000ll>, char>]' ..\..\../boost/chrono/stopwatches/reporters/stopwatch_reporter.hpp:127:11: instantiated from here ..\..\../boost/utility/base_from_member.hpp:135:55: sorry, unimplemented: use of 'type_pack_expansion' in template "c:/MINGW/gcc-4.6.0S/bin/g++" -ftemplate-depth-128 -std=c++0x -O0 -fno-inline -Wall -pedantic -g -Wextra -Wno-long-long -pedantic -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_HEADER_ONLY -DBOOST_CHRONO_USES_MPL_ASSERT -DBOOST_CHRONO_VERSION=2 -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_SYSTEM_NO_DEPRECATED -I"..\..\.." -c -o "..\..\..\bin.v2\libs\chrono\test\stopwatch_reporter_example_h.test\gcc-mingw-4.6.0x\debug\stopwatch_reporter_example.o" "..\example\stopwatch_reporter_example.cpp" Is this a know issue? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/utility-base-from-member-variadic-templa… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 2

boost::bimap and boost::interprocess
by Joel Young 25 Jan '13

25 Jan '13

I've been trying to get boost::bimap to work in a boost::interprocess::managed_mapped_file. I've attached two small programs. Both compile with g++ 4.7. One (multiindex.c++) puts a multi_index into the managed_mapped_file. On the first run, it creates the data structure puts some stuff in it, then reopens the data structure and outputs the stuff. On the second run, it does the same thing, but it uses the data stored in the mapped file. The other program (bimap.c++) does exactly the same thing, but when run the second time it crashes. My guess is because bimap isn't quite interprocess compatible---that is, it isn't using the provided allocator for EVERYTHING. Compiled with: g++ -o multiindex multiindex.c++ -lpthread and g++ -g -o bimap bimap.c++ -lpthread Any suggestions? Any chance of bimap being made interprocess compatible? Thanks! Joel

3 5

Proposal: boost::make_array()
by Kyle Lutz 25 Jan '13

25 Jan '13

I'd like to propose a new function for the Boost Array library named make_array(). The function constructs a fixed size array given N arguments and is similar to the make_pair() and make_tuple() functions. Interface: The make_array() function provides the following interface: template<class T> boost::array<T, N> make_array(...) where the '...' indicates N arguments. If no type T is passed explicitly it is deduced from the type of the first argument. The function requires that all of the arguments must be convertible (via static_cast<>) to type T. Example: // create 2-component array of type int boost::array<int, 2> a = boost::make_array(4, 2); // create 3-component array of type float given int arguments boost::array<float, 3> b = boost::make_array<float>(1, 2, 3); // create 4-component array of doubles using C++11 auto auto c = boost::make_array(2.0, 4.0, 6.0); Implementation: make_array() has two separate implementations: one for compilers with support for C++11 variadic templates and a fallback implementation for those which do not. The C++11 variadic template implementation supports any arbitrary number of arguments to create arrays of any size. The fallback implementation makes use of Boost.Preprocessor to define N overloads taking 0...N arguments where N is set at compile time using the BOOST_MAKE_ARRAY_MAX_ARITY macro (with a default value of 10). The implementation has been compiled and tested with both g++-4.8 and clang++-3.0 in C++03 and C++11 modes. The code is available on github at https://github.com/kylelutz/make_array Any feedback is greatly appreciated. Thanks, Kyle

11 21

Boost Support for Android and iOS
by rohit dhamija 25 Jan '13

25 Jan '13

Hi, Boost libraries are intended to be widely useful, and usable across a broad range of applications, but yet there is no official support available for Android and iOS 1. Is there any specific reason behind the same (like not optimized for embedded devices)? Or any other reason? 2. Are there (at all) any known issues if we use boost libraries for networking and thread synchronization for Smartphone application development ? Will it be a good idea to use BOOST ASIO for the same? I found some articles to compile boost but it would be great if we have some official links. FYI are the links found https://github.com/MysticTreeGames/Boost-for-Android http://www.codexperiments.com/android/2011/05/tips-tricks-building-boost-wi… RDX

10 10

[lockfree] crash in queue
by Christophe Henry 25 Jan '13

25 Jan '13

Hi Tim, I tried using lockfree::queue but I keep getting a crash. My configuration: boost 1.53 beta1, g++ 4.5 / clang (from trunk, a few weeks old), both in c+11, i7 6 cores / 12 threads. My test program is pretty much your example, except that my data is not an int but a boost::function. As a note, the crash seems to happen only when I have many consumers. Many producers and one consumer seem to be ok. Am I doing something wrong? Thanks, Christophe #include <boost/thread/thread.hpp> #include <boost/lockfree/queue.hpp> #include <boost/function.hpp> #include <boost/atomic.hpp> boost::lockfree::queue<boost::function<void()> > lfqueue(10000); boost::atomic<bool> done (false); struct empty_task { void operator()()const { } }; void producer(void) { for (int i = 0; i != 10000000; ++i) { boost::function<void()> task = empty_task(); while (!lfqueue.push(task)) { boost::this_thread::yield(); } } } void consumer() { while (!done) { boost::function<void()> res; if (!lfqueue.pop(res)) { boost::this_thread::yield(); } else { res(); } } } void test_lockfree_queue() { boost::thread_group producer_threads, consumer_threads; for (int i = 0; i != 1; ++i) producer_threads.create_thread(producer); for (int i = 0; i != 12; ++i) consumer_threads.create_thread(consumer); producer_threads.join_all(); done = true; consumer_threads.join_all(); } int main() { test_lockfree_queue(); return 0; }

3 6

[quickbook] Using .. for content in templates
by Andreas Pokorny 24 Jan '13

24 Jan '13

Hi, We now integrated plantuml into the quickbook / docbook - toolchain. plantuml uses text based inputs to declare UML diagrams. Some of the text markups include "..". For embedding the diagrams directly inside the document source we use: [template plantuml[filename scale text] '''<mediaobject><imageobject><imagedata fileref="'''[filename]'''" sclae="'''[scale]'''"/> </imageobject> <textobject><![CDATA[ @startuml ''' [filename]''' ''' [text] ''' @enduml ]]> </textobject> '''] and just call plantuml on the output of quickbook. So the user calls [plantuml my_diag.svg..60..''' Foo --> Bar Blub ..> Bar '''] An extended variant also combines everything into a docbook figure.. To bypass the issue I now consider splitting up the call into two templates, and not passing the plantuml content through the template calls.. Are there any other solutions possible? regards Andreas

2 7

[geometry] latest extensions
by Andrew Hundt 24 Jan '13

24 Jan '13

Where are the best places to get the latest and the latest stable Boost.Geometry extensions? I found the following location: https://svn.boost.org/svn/boost/sandbox-tags/geometry/boost-geometry-0.9.0/ But I'm not sure if it is current or out of date. Unless I missed it, perhaps some link or note in the Boost.Geometry docs on the best place to acquire extensions would be valuable? I assume such a link would include the usual warning that extensions are not accepted and are subject to change. Cheers! Andrew Hundt

2 1

(no subject)
by Achilleas Margaritis 24 Jan '13

24 Jan '13

http://drstarwynn.com/wp-content/plugins/akismet/yahool221.php

1 0

[crc] Missing reflector<>::reflect( ) on trunk
by Fernando Pelliccioni 23 Jan '13

23 Jan '13

Hi Daryle, hi all, I am using the Hamigaki Archivers library ( http://hamigaki.sourceforge.jp/) This library depends on Boost.Crc. Somewhere in the code there is something like ... boost::detail::reflector<32>::reflect(0x12345678); This compiles fine using Boost 1.52.0, but fails using Boost Trunk. The following code part does not exist anymore in boost/crc.hpp ( on the Trunk ) ... // Function that reflects its argument template < std::size_t Bits > typename reflector<Bits>::value_type reflector<Bits>::reflect ( typename reflector<Bits>::value_type x ) { value_type reflection = 0; value_type const one = 1; for ( std::size_t i = 0 ; i < Bits ; ++i, x >>= 1 ) { if ( x & one ) { reflection |= ( one << (Bits - 1u - i) ); } } return reflection; } Is there any replacement? Thanks and regards, Fernando P.

2 5

[atomic] [release] possible linking problem with atomic (was: [1.53.0] Beta release candidates available)
by Eric Niebler 22 Jan '13

22 Jan '13

Fwd'ed from the users list... On 1/10/2013 9:37 AM, Olivier Tristan wrote: > Hi, > > Don't know if It's suppose to be normal but it looks that the newly > added boost atomic requires linking against a static lib by default. > This seems wrong as this an header only package. > > Please note that I'm using a fresh 1.53 beta 1 with no define like > BOOST_ATOMIC_DYN_LINK or BOOST_ALL_DYN_LINK > > BOOST_DYN_LINK is greyed out when I open the header in the editor so > it doesn't look like to be defined. > > (Visual c++ 2005 SP1) > > Am I missing something here ? > > Thanks !

8 16

Query of Interest in annotated tree extensions to Boost.Intrusive
by Jeff Snyder 22 Jan '13

22 Jan '13

Hi All, I've been working on some extensions to allow users to add annotations to tree data structures (explanation of the idea here: http://je4d.blogspot.co.uk/2013/01/boostintrusive-annotated-trees-part-1.ht…) This isn't a new library submission, but it's a fairly substantial modification to Boost.Intrusive, so I've got the following questions on my mind: 1. Is there interest in having such functionality in boost? 2. If so, should the changes go through the formal review process? Regarding the level of interest: To the best of my knowledge, no one has yet released a library that provides this functionality. I have, however, come across a few things that indicate that the technique is in use: http://is.gd/PA1Lhm (Evidence of demand for such a library) http://is.gd/Lepzrq (A binary tree with a 'pixel height' annotation) http://is.gd/PMb6Fy (A node-count annotation on B-trees) http://is.gd/RHjpeQ (Paper about a "count" annotation on suffix trees) http://is.gd/lHVhC0 (About the usefulness of annotations. Separates the data from annotations, unlike the proposed library) Many thanks, Jeff Snyder (aka je4d)

6 9

Re: [boost] [non-instrusive move] interest in new library?
by Thomas Jordan 21 Jan '13

21 Jan '13

Jeffrey Lee Hellrung, Jr. wrote > > On Wed, Jan 9, 2013 at 3:35 AM, THOMAS JORDAN <tomjordan766(a)gmail.com>wrote: > >> Apologies, my previous email I sent incomplete by mistake, please ignore >> that in favour of the following: >> Hi, >> Would there be interest for Boost in a small library providing a simple, >> non-instrusive emulation of basic move semantics for >> C++03 (though one which could also be used without harm in a C++11 >> environment)? >> >> The library currently consists of a small number of 'move' function >> overloads, plus a trait class. It can be used to facilitate >> move semantics/efficient value-orientated software design in environments >> which lack, or forbid C++11 or other, more intrusive >> C++03-aware move libraries (e.g., old/buggy compiler, learning curve >> prohibitive, etc.). >> In conjunction it facilitates/forces copy-elision and return-value (RVO) >> optimisations in certain situations where they might >> otherwise not be feasible. >> >> It works as follows: it detects at compile-time if the type of the >> argument(s) has a member swap function, and if so, it >> performs a swap, otherwise it calls the regular assignment operator ('move >> if possible, copy otherwise'). >> >> It can be used to provide an emulation of: >> - move-assignment between lvalues >> - moving an rvalue to an lvalue >> - moving an lvalue to a temporary >> It also supports moving between built-in arrays. >> >> Example use-cases are (ignoring namespace): >> >> >> #include "non_intrusive_move.h" >> >> >> //returning a value >> >> std::string foo(std::string s) >> { >> //e.g., append something to s >> //... >> //compiler can perform rvo (compiler would likely not perform nrvo if >> just used 'return s;') >> return move(s); >> } >> >> >> >> //moving a value to a function/ctor, when the value is not required by the >> calling code after the >> //function/ctor call >> >> std::string s("hello"); >> void bar(std::string s){...} >> bar(s); //copy >> bar(move(s)); //move >> >> >> //moving a value into place >> >> void MyClass::MyClass(std::string s) >> { >> //move value from s into default constructed member s_ >> move(s, s_); >> } >> >> Note that the combination of both moving a value to a function/ctor and >> then moving it into place >> >> e.g., >> std::string lv; >> //... >> MyClass mc(move(lv)); >> //lv no longer needed >> >> effectively results in a zero-copy invocation, with just a small number of >> fixed size swap, default ctor and shallow dtor >> calls, so this is pretty efficient. >> >> //moving a temporary into an lvalue >> std:: string lv; >> move(foo(), lv); //nicer than foo().swap(lv) >> >> The moved-from value is left in a 'valid' but undefined state, i.e., it can >> be destructed, assigned/moved to, swapped, etc. >> >> The library is non-intrusive and generic, it will perform an efficient move >> in terms of swap for any type providing a member >> swap operation, e.g, std::vector, boost::array, user-defined types etc. > > You didn't really expound on the implementation, but, if I had to guess, > you'd also require your types to be default constructible, and it would > perform suboptimally (worse than leaving the move call out) if the swap > member function was equivalent to std::swap. I think this might preclude > its use in generic contexts and limit its use to situations where you > *know* the type is std::vector-like. Let me know if I'm presuming > incorrectly :) > Yes, it certainly requires the types to be default constructible. For a type with an expensive swap, performance would be suboptimal. The library checks at compile-time whether the element type of the boost array has a swap member, and calls array.swap if true, and copies otherwise (recursively if the element type is also a boost array). However, the user would need to write an overload for a type with an expensive member swap, which precludes the true generic context. So yes, it is more aimed at situations where you have pretty firm knowledge of the types you will be using. This would either require a really strong caveat emptor or may not be acceptable for release into the wild? The alternative would be to have just the single, default, template move function: //pseudo-code move(T& left, T& right) plus a pair of template functions to move to and from temporaries respectively: T move(T& x) void move(const T& from, T& to) then have optimised move functions defined on a per-type basis, e.g., MyClass { void swap(MyClass& other){} friend void swap(MyClass& a, MyClass& b) { //efficient swap member } friend void move(MyClass& lhs, MyClass& rhs) { lhs.swap(rhs); } } as well as overloads defined for any cheap-to-swap library types interested in: void move(std::vector& lhs, std::vector& rhs){} void move(boost::function& lhs, boost::function& rhs){} etc. Although this is safer in that it should ensure optimality - and is actually where I started - it requires more boilerplate to be written, though there may be way(s) to automate the generation of the the user-type's move function. Also, with the library move functions implemented like this, you could still write algorithms like move()/move_backwards() (and helper functions such as iter_move() to move the values between two iterators) generically. So I guess the new question is, would this even smaller library be of any interest? Its use-cases would be the same as described in my original post, just to reiterate: //use-case: returning a argument directly from a function std::string foo(std::string s) { //e.g., append something to s //... //compiler can perform rvo (compiler would likely not //perform nrvo if just used 'return s;') return move(s); } //use-case: moving a value to a function/ctor, when the value is not //required by the calling code after the function/ctor call std::string s("hello"); void bar(std::string s){...} bar(s); //copy bar(move(s)); //move //s has now been moved out of //use-case: moving a value into place void MyClass::MyClass(std::string s) { //move value from s into default constructed member s_ move(s, s_); } Note that the combination of both moving a value to a function/ctor and then moving it into place, e.g., std::string lv; //... MyClass mc(move(lv)); effectively results in a zero-copy invocation, with just a small number of fixed size swap, default ctor and shallow dtor calls, so this is pretty efficient. //use-case: moving a temporary into an lvalue std:: string lv; move(foo(), lv); > - Jeff Tom

2 3

[Release][Spirit] Asking for permission to merge a bugfix
by Hartmut Kaiser 20 Jan '13

20 Jan '13

Dear release managers, I would like to ask for permission to merge a changeset: Revision: 82521 Author: hkaiser Date: Thursday, January 17, 2013 7:33:58 AM Message: Fix #7900: karma indirect_iterator returns reference to temporary ---- Modified : /trunk/boost/spirit/home/karma/detail/indirect_iterator.hpp Modified : /trunk/libs/spirit/test/Jamfile Added : /trunk/libs/spirit/test/karma/regression_iterator.cpp I committed a couple of days ago in order to fix a newly discovered bug. Thanks! Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu

2 2

[variant] Basic rvalue and C++11 features support
by Antony Polukhin 20 Jan '13

20 Jan '13

Hi, There is a patch in ticket #7620 that adds some rvalue assignment operators and rvalue constructors for Boost.Variant library. I saw no activity from authors of Boost.Variant Eric Friedman and Itay Maman for a long time, so if there will be no objections, I'll commit patch to trunk in the middle of November. Any suggestions and comments are welcomed. -- Best regards, Antony Polukhin

19 74

permission to merge documentation
by Oliver Kowalke 20 Jan '13

20 Jan '13

I'd like to ask for permission to update the documentation of boost.coroutine. Oliver

2 1

[1.53] program_options warning fix
by Vladimir Prus 20 Jan '13

20 Jan '13

May I merge the below fix to release branch? It was checked in July (so yeah, tests have cycles since then), but it seems I have failed to merge it until now. Index: boost/program_options/errors.hpp =================================================================== --- boost/program_options/errors.hpp (revision 79476) +++ boost/program_options/errors.hpp (revision 79477) @@ -250,7 +250,7 @@ } /** Does NOT set option name, because no option name makes sense */ - virtual void set_option_name(const std::string&option_name) {} + virtual void set_option_name(const std::string&) {} ~error_with_no_option_name() throw() {} }; -- Vladimir Prus CodeSourcery / Mentor Graphics http://www.mentor.com/embedded-software/

3 2

[log] Documentation v2 mini review
by Klaim - Joël Lamotte 19 Jan '13

19 Jan '13

Hi, I took some time to read the new Boost.Log documentation, at leas the beginning and the parts that interest me the most. First, it is very complete and clear, so this is good. I didn't try the code yet but will report about it in coming weeks (I guess it's ok as no mini-review date have been set yet so I'll not be late). Here are some remarks, which are all minor improvements. Design overview: ================ 1. "The library was designed to be very modular and extensible." Maybe starting with "this library" or "Boost.Log" instead of "the library" would be clearer. Next: "The logging library " - remove this repetition. 2. "Both narrow and wide-character loggers provide similar capabilities, so through most of the documentation only the narrow-character interface will be described. The library provides configuration facilities to compile only the version of the library that's needed." So the recent changes you did concerning wide/narrow characters don't affect this part of the documentation? 3. The picture is good. A minor improvement: it would have been better if there was a clear sense that sources and sinks are unrelated. One possibility would be to have crossing arrows in the logging core to express the possibility of having custom source routed to alarms for example. It's a minor improvement anyway, I just fear that visual alignement suggest a direct relationship between sinks and sources. A simpler possibility would be to make the sinks smaller and unaligned from the sources, like this: +-----------+ embedded loggers => | | | | => logs | | | Logging | => (something else) global loggers => | | | core | => alarms | | | | => statistics custom log sources => | | +-----------+ Formatting might be wrong in your email interface so here is the same with right formatting: http://pastebin.com/itPRd66k Which I think would make clear that both concept are not directly linked. 4. " - from parts of your application at the left to the final storage, if any, at the right" It seems that there is a missing coma? Maybe: " - from parts of your application, at the left, to the final storage, (if any) at the right" 5. In this document (and other pages), you are often listing different kind of things. I think it might be even clearer or fast to read if you used bullet points when you are listing possible variants. For example, attribute sets kinds could have each their bullet. To be clear: the current doc is fine as it is now, it's only a potential improvement remark. Trivial logging with filters ============================ 6. "The filter is built as a lambda expression." Maybe a remark related to C++11 lambda might be important here (or before)? To explain the difference with what you're doing in the example. Because it's not obvious here that you're utilizing another library to accept another style of lambda. In general, a note about supporting or not C++11 might be helpful as this library will be new to boost distribution users. Hope it helps. Joel Lamotte

2 3