- Boost - lists.preview.boost.org

permission to merge docu ?
by Oliver Kowalke 29 Jan '13

29 Jan '13

The release branch is closed because of building boost-1.53. I'd like to add a comment to boost.context documentation. Would this be possible? Oliver

2 1

[log][phoenix][spirit] Cygwin compiler crashes in actor_operator_10.hpp
by Bernd Prager 29 Jan '13

29 Jan '13

All, I am trying to compile the trunk version of Andrey Semashev's great Boost.Log library in Cygwin 1.7.17 with g++ 4.5.3. The line that crashes compiling his code is: $ "g++" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -mthreads -fno-strict-aliasing -ftemplate-depth-1024 -DBOOST_ALL_NO_LIB=1 -DBOOST_CHRONO_STATIC_LINK=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_LOG_SETUP_BUILDING_THE_LIB=1 -DBOOST_LOG_USE_NATIVE_SYSLOG=1 -DBOOST_SPIRIT_USE_PHOENIX_V3=1 -DBOOST_SYSTEM_NO_DEPRECATED -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_BUILD_LIB=1 -DBOOST_THREAD_DONT_USE_CHRONO=1 -DBOOST_THREAD_POSIX -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE -DNDEBUG -I"." -c -o "bin.v2\libs\log\build\gcc-4.5.3\release\link-static\threading-multi\formatt er_parser.o" ./libs/log/src/formatter_parser.cpp The result is: ... >> ./libs/log/src/formatter_parser.cpp:447:95: instantiated from here >> ./boost/phoenix/core/detail/preprocessed/actor_operator_10.hpp:31:2307: >> internal compiler error: Segmentation fault Andrey suggests it might be related to the Boost.Spirit parser rather then Boost.Phoenix. Could somebody please have a look at this? Thank you so much, -- Bernd

4 10

boost::filesystem::path frustration
by Dave Abrahams 29 Jan '13

29 Jan '13

I'm finding that boost::filesystem::path seems to be a strange mix of different beasts, unlike any entity we have in the STL. For example, when you construct it from a pair of iterators, they're expected to be iterators over characters, but when you iterate over the path itself, you are iterating over strings of some kind (**). Even though, once constructed, this thing acts sort of like a container, it supports none of the usual container mutators (e.g. push_back, pop_back, erase) or even queries (e.g. size()), making it incompatible with generic algorithms and adaptors. In particular, this comes up because I'm trying to find the greatest common prefix of two paths. I thought this would be easy; I'd just use std::mismatch. But even once I've found the mismatch I don't see any obvious way to chop off the non-matching parts of one of the paths. I end up having to resort to some really ugly code (or I just haven't figured out how to use this thing correctly). Why should paths be so different from everything else? I think, if the design is actually right, some rationale is sorely needed. Also, * (**) the docs don't say what the value_type of path::iterator is. A string value? A range that becomes invalid when the path is destroyed? Ah!?! How surprising; inspecting the code shows it iterates over paths! A container whose element type is itself is very unusual! * the docs claim you can construct a path from a "A C-array. The value type is required to be char, wchar_t, char16_t, or char32_t", but doesn't say how that array will be interpreted. From the wording I might have assumed it accepts a CharT(&)[N] and the length of the input is taken as N, but inspecting the code shows it expects a CharT* and interprets the source as null-terminated. Thanks, -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

15 32

[1.53.0] Beta release candidates 2 now available for testing
by Marshall Clow 28 Jan '13

28 Jan '13

Updated release candidate files for 1.53.0 beta 1 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 579b680bf55f53cd6d50adc391cb6c23 *boost_1_53_0_beta1_rc2.tar.gz 02098bb6da0e9c10712ae63c16e6aeea *boost_1_53_0_beta1_rc2.tar.bz2 998e2616a66c50e5693f563afb899002 *boost_1_53_0_beta1_rc2.zip e4fde6a869a3e21f8751ba8b7fd471a8 *boost_1_53_0_beta1_rc2.7z There were three changes between rc1 and rc2: * Fixes for compilation errors in Boost.Serialization * Documentation updates for Boost.SmartPtr * Updates to Boost.Threads Thanks, --The release managers

9 16

[release] permission to merge
by Vicente J. Botet Escriba 28 Jan '13

28 Jan '13

Hi, could I merge https://svn.boost.org/trac/boost/changeset/82659 (ticket https://svn.boost.org/trac/boost/ticket/7940) svn diff rel/boost/chrono/config.hpp Index: rel/boost/chrono/config.hpp =================================================================== --- rel/boost/chrono/config.hpp (revision 82662) +++ rel/boost/chrono/config.hpp (working copy) @@ -96,6 +96,9 @@ # undef BOOST_CHRONO_HAS_THREAD_CLOCK # undef BOOST_CHRONO_THREAD_CLOCK_IS_STEADY # endif +# if defined(__VXWORKS__) +# undef BOOST_CHRONO_HAS_PROCESS_CLOCKS +# endif # endif Best, Vicente

2 1

[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