- Boost - lists.preview.boost.org

Re: [boost] [cpo-proposal] presentation of the idea
by Santiago Tapia 10 Sep '13

10 Sep '13

> Date: Mon, 09 Sep 2013 11:57:43 -0500 > From: Larry Evans <cppljevans(a)suddenlink.net> > >> But because I am not an expert on alignment and memory >> optimization, I will try to use something "more standard", actually I am >> going trying to use the allocator to compute the "right" address to place >> an object of a given type that is greater that a "free" memory pointer. >> In that way, I also expect to take advantages of allocator such as >> tbb cache aligned allocator. > > I know nothing about how 'to use the allocator to compute the "right" > address'; hence, I'm afraid I can't be any help there. Could you maybe > give a brief summary of how that works? > No idea, I was just speculating, actually, I am not sure I will be able to do it. On the other hand, I suppose there should be a way to do it. Just need some time and thought. > Best of luck on this project, Santiago! > > -regards, > Larry Thank you!

2 1

[PREPROCESSOR] Possible improvement for BOOST_PP_VARIADIC_SIZE
by Brent Lewis 10 Sep '13

10 Sep '13

Currently, BOOST_VARIADIC_SIZE() evaluates to 1. Based on http://gustedt.wordpress.com/2010/06/08/detect-empty-macro-arguments/ it can be improved to return 0 for an empty argument list.

4 3

Quid pro quo for Boost peer review manager
by Niall Douglas 09 Sep '13

09 Sep '13

Dear Boost Devs, GSoC 2013 ends on 23rd September, and myself and Paul expect that Boost.AFIO will be ready for peer review at around that time after finishing the following features from your voting at http://boostafio.uservoice.com/: (i) Directory Monitoring (ii) Asynchronous Directory Enumeration (iii) Parts of Improved formal closure execution engine support based on the latest updated papers in the Sept WG21 mailing N3721 and N3731. It seems unfair to ask for someone to volunteer to do all the work to be a review manager for AFIO without me volunteering to be a review manager for another Boost library in exchange, so I was wondering: are there any similar sized libraries to AFIO (~800 active LOC, ~20,000 for everything including docs and testing) which are ready for peer review and need a review manager? Thanks, Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

1 0

[Thread] possible bug in Move emulation "portable interface"
by Gavin Lambert 09 Sep '13

09 Sep '13

I tried submitting this via Trac but for some reason it was convinced that my bug report contained spam, while refusing to tell me what part it was objecting to, and also refusing to give me a captcha or anything to convince it otherwise. Anyways: Bug 1: the Boost.Thread documentation and release history indicate that BOOST_THREAD_VERSION==3 is the default since v1.52. As far as I can tell this has never been true in any released version; the latest code still has ==2. (I found a thread in boost-devel that was debating consequences of making breaking changes by default, which I assume is why this change was not actually made; but the docs need correcting.) Bug 2: when writing code using the Boost.Thread "Portable Interface" for move support/emulation, it recommends using the BOOST_THREAD_DCL_MOVABLE_BEG macro to "avoid conflicts with Boost.Move". However regardless of C++11 or not or the BOOST_THREAD_VERSION it defines a template specialisation in a way that assumes that it is called only from "namespace boost". As this usage is unlikely for any code outside the boost library itself, I think this is a bug. namespace user { template<typename T> class test { public: BOOST_THREAD_COPYABLE_AND_MOVABLE(test) test() {} test(const test&) {} test& operator=(BOOST_COPY_ASSIGN_REF(test) o) { return *this; } test(BOOST_THREAD_RV_REF(test) o) {} test& operator=(BOOST_THREAD_RV_REF(test) o) { return *this; } }; BOOST_THREAD_DCL_MOVABLE_BEG(T) test<T> BOOST_THREAD_DCL_MOVABLE_END } The above code will not compile. It does compile if the DCL define is moved into a "namespace boost" block, but I do not regard this as an acceptable solution. Suggested fix is to explicitly specify the namespace in the macro, eg. replace "enable_move_utility_emulation" with "::boost::enable_move_utility_emulation".

6 12

Fwd: Re: [atomic] atomic<int>::is_lock_free() returns false on iPad 4 (armv7s)
by Tim Blechmann 09 Sep '13

09 Sep '13

-------- Original-Nachricht -------- Betreff: Re: [boost] [atomic] atomic<int>::is_lock_free() returns false on iPad 4 (armv7s) Datum: Mon, 09 Sep 2013 15:49:06 +0100 Von: Phil Endecott <spam_from_boost_dev(a)chezphil.org> An: Tim Blechmann <tim(a)klingt.org> Hi Tim, (My Boost list subscription is temporarily broken; feel free to forward this if you want.) Tim Blechmann wrote: >>> boost:atomic<int>::is_lock_free() returns false on iPad 4 (armv7s) but >>> returns true on iPad 3 (armv7). Yes. I thought this had been fixed. It's now too long ago for me to recall exactly what happened. I know that I filed a trac ticket to get it fixed in smart_ptr's spinlock; I think that at that time Boost.Atomic has still not been reviewed and merged, and I probably fixed it only in a local copy. > btw, it may be worth to note that on iOS devices std::atomic should be > available ... Absolutely! Few people have any reason to be using Boost.Atomic. Regards, Phil.

1 0

[format] convenient format wrapper
by Alexey Klimkin 09 Sep '13

09 Sep '13

I found this boost::format wrapper to be very convenient as replacement of sprintf. Can something like that be a part of the library? #include <boost/format.hpp> #include <string> #include <iostream> using namespace std; using namespace boost; format& my_format(format& fmter) { return fmter; } template <typename T, typename... Args> format& my_format(format& fmter, T value, Args... args) { fmter % value; return my_format(fmter, args...); } string my_format(string fmt) { format fmter(fmt); return my_format(fmter).str(); } template <typename... Args> string my_format(string fmt, Args... args) { format fmter(fmt); return my_format(fmter, args...).str(); } int main() { cout << my_format("%s %.6f", "pi", 3.14159) << endl; return 0; } -Alexey

3 2

[utility] Proposal to extract some components from Boost.Log
by Andrey Semashev 09 Sep '13

09 Sep '13

Hi, I'd like to extract some general-purpose components from Boost.Log to Boost.Utility so that they could be used in other libraries and user's code that is not related to logging. The components are mostly standalone already and are not tied to Boost.Log specifics. 1. BOOST_EXPLICIT_OPERATOR_BOOL() macro for defining explicit operator bool() for a class. For C++03 compilers the macro implements safe bool idiom or just a regular operator bool(), if the compiler doesn't handle safe bool well. The generated operator is implemented in terms of operator!(), which should be defined for the class: template< typename T > class my_ptr { T* m_p; public: BOOST_EXPLICIT_OPERATOR_BOOL() bool operator! () const { return !m_p; } }; Various different implementations of explicit/safe bool operator are present in different libraries. It would be good to unify them. Implementation: boost/log/utility/explicit_operator_bool.hpp 2. basic_string_literal< CharT, CharTraitsT > class template. String literal is similar to string_ref, but it only allows to be constructed from a string literal. Obviously, it doesn't allow to modify the literal and it doesn't allocate memory for the literal. It supports clear() though, which makes the literal object to refer to an empty literal. Otherwise it provides interface similar to std::string. Docs: < http://www.boost.org/doc/libs/release/libs/log/doc/html/log/detailed/utilit… > Implementation: boost/log/utility/string_literal.hpp 3. type_info_wrapper class. The class wraps a reference to std::type_info and provides equality and ordering operators. The wrapper implements value semantics (i.e. it can be constructed and copied), which allows it to be stored in containers, including as keys. Docs: < http://www.boost.org/doc/libs/release/libs/log/doc/html/log/detailed/utilit… > Implementation: boost/log/utility/type_info_wrapper.hpp 4. empty_deleter class. The class can be used as a deleter (e.g. for shared_ptr) that does nothing. It can be useful in some cases, when you need a shared_ptr but you know you will delete the referred object by other means. For example, with Boost.Log this deleter can be used to create shared_ptr< std::ostream > to std::cout. Another use case is to create a weak_ptr to an object to be able to test whether the object has already been deleted. Implementation: boost/log/utility/empty_deleter.hpp 5. BOOST_LOG_UNIQUE_IDENTIFIER_NAME(prefix) macro. This macro expands in a unique (within the current TU) token that starts with prefix. This can be useful for declaring unique variable and type names within other macros. Not that this macro has much value but it could be useful for other libraries that define macros. Implementation: boost/log/utility/unique_identifier_name.hpp

4 10

[Container] Strange flat_set crash with std::inserter
by Ben Pope 08 Sep '13

08 Sep '13

Hi all It seems that when I copy a sorted but non-unique range of randomly generated numbers to an output iterator generated from std::inserter to a boost::flat_set it crashes. At first I assumed it was because boost::flat_set doesn't have stable iterators, but it seems that the implementation of std::insert_iterator does the right thing by reassigning its internal iterator to the result of the insert operation before incrementing it. Apologies for not being able to reduce the problem further, but this one is a little strange, the following code demonstrates the problem (and some variations that do work) in boost 1.54: #include <boost/container/flat_set.hpp> #include <algorithm> #include <iterator> #include <numeric> #include <vector> template<typename ContainerT> void Populate(std::vector<size_t> const& input) { ContainerT container; std::copy( std::begin(input), std::end(input), std::inserter(container, std::end(container))); } int main() { const size_t Count = 1000000; std::vector<size_t> random_numbers; random_numbers.reserve(Count); std::generate_n( std::back_inserter(random_numbers), Count, &std::rand); std::vector<size_t> sorted_numbers(random_numbers); std::sort(std::begin(sorted_numbers), std::end(sorted_numbers)); std::vector<size_t> unique_sorted_numbers; unique_sorted_numbers.reserve(Count); std::unique_copy( std::begin(sorted_numbers), std::end(sorted_numbers), std::back_inserter(unique_sorted_numbers)); using namespace boost::container; Populate<flat_set<size_t>>(unique_sorted_numbers); // ok Populate<flat_multiset<size_t>>(sorted_numbers); // ok Populate<flat_set<size_t>>(sorted_numbers); // segfault, line 39 } It might be a little hard to reproduce with the rand() in there, I'm on 64bit Ubuntu 13.04 and it's reproducible with Clang 3.3 with libc++ and GCC 4.8.1. Here's the backtrace from Clang: #0 0x0000000000403aec in operator() (this=0x7fffffffd598, __x=@0x7ffff61c6320: 61595138, __y=@0x454000: <error reading variable>) at /usr/include/c++/v1/__functional_base:61 #1 boost::container::container_detail::flat_tree_value_compare<std::__1::less<unsigned long>, unsigned long, boost::container::container_detail::identity<unsigned long> >::operator() (this=0x7fffffffd598, lhs=@0x7ffff61c6320: 61595138, rhs=@0x454000: <error reading variable>) at ../yy/build/boost/boost/container/detail/flat_tree.hpp:66 #2 0x0000000000404367 in boost::container::container_detail::flat_tree<unsigned long, unsigned long, boost::container::container_detail::identity<unsigned long>, std::__1::less<unsigned long>, std::__1::allocator<unsigned long> >::priv_insert_unique_prepare (this=0x7fffffffd598, pos=..., val=@0x7ffff61c6320: 61595138, commit_data=...) at ../yy/build/boost/boost/container/detail/flat_tree.hpp:824 #3 0x0000000000404275 in boost::container::container_detail::flat_tree<unsigned long, unsigned long, boost::container::container_detail::identity<unsigned long>, std::__1::less<unsigned long>, std::__1::allocator<unsigned long> >::insert_unique (this=0x7fffffffd598, pos=..., val=@0x7ffff61c6320: 61595138) at ../yy/build/boost/boost/container/detail/flat_tree.hpp:354 #4 0x000000000040421d in boost::container::flat_set<unsigned long, std::__1::less<unsigned long>, std::__1::allocator<unsigned long> >::priv_insert<unsigned long const&> (this=0x7fffffffd598, p=..., x=@0x7ffff61c6320: 61595138) at ../yy/build/boost/boost/container/flat_set.hpp:688 #5 0x00000000004041bd in boost::container::flat_set<unsigned long, std::__1::less<unsigned long>, std::__1::allocator<unsigned long> >::insert (this=0x7fffffffd598, arg1=..., x=@0x7ffff61c6320: 61595138) at ../yy/build/boost/boost/container/flat_set.hpp:508 #6 0x0000000000401de4 in operator* (this=0x7fffffffd750, this=0x7fffffffd750, this=0x7fffffffd750, __value_=@0x7ffff61c6320: 61595138) at /usr/include/c++/v1/iterator:718 #7 __unwrap_iter<std::__1::insert_iterator<boost::container::flat_set<unsigned long, std::__1::less<unsigned long>, std::__1::allocator<unsigned long> > > > (__i=..., __first=..., __last=..., __result=...) at /usr/include/c++/v1/algorithm:1717 #8 end<boost::container::flat_set<unsigned long, std::__1::less<unsigned long>, std::__1::allocator<unsigned long> > > (__c=..., __x=..., __i=..., __first=..., __last=..., __result=...) at /usr/include/c++/v1/algorithm:1741 #9 Populate<boost::container::flat_set<unsigned long, std::__1::less<unsigned long>, std::__1::allocator<unsigned long> > > (input=...) at flat_set_crash.cpp:13 #10 0x00000000004017a6 in main () at flat_set_crash.cpp:39 or from GCC if you prefer: #0 0x0000000000404bed in std::less<unsigned long>::operator() (this=0x7fffffffdd10, __x=@0x7ffff62e7320: 61595138, __y=@0x453000: <error reading variable>) at /usr/include/c++/4.8/bits/stl_function.h:235 #1 0x00000000004047f9 in boost::container::container_detail::flat_tree_value_compare<std::less<unsigned long>, unsigned long, boost::container::container_detail::identity<unsigned long> >::operator() (this=0x7fffffffdd10, lhs=@0x7ffff62e7320: 61595138, rhs=@0x453000: <error reading variable>) at ../yy/build/boost/boost/container/detail/flat_tree.hpp:66 #2 0x0000000000404389 in boost::container::container_detail::flat_tree<unsigned long, unsigned long, boost::container::container_detail::identity<unsigned long>, std::less<unsigned long>, std::allocator<unsigned long> >::priv_insert_unique_prepare (this=0x7fffffffdd10, pos=..., val=@0x7ffff62e7320: 61595138, commit_data=...) at ../yy/build/boost/boost/container/detail/flat_tree.hpp:824 #3 0x000000000040420a in boost::container::container_detail::flat_tree<unsigned long, unsigned long, boost::container::container_detail::identity<unsigned long>, std::less<unsigned long>, std::allocator<unsigned long> >::insert_unique (this=0x7fffffffdd10, pos=..., val=@0x7ffff62e7320: 61595138) at ../yy/build/boost/boost/container/detail/flat_tree.hpp:354 #4 0x00000000004040ef in boost::container::flat_set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> >::priv_insert<unsigned long const&> (this=0x7fffffffdd10, p=..., x=@0x7ffff62e7320: 61595138) at ../yy/build/boost/boost/container/flat_set.hpp:688 #5 0x0000000000403fa5 in boost::container::flat_set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> >::insert (this=0x7fffffffdd10, arg1=..., x=@0x7ffff62e7320: 61595138) at ../yy/build/boost/boost/container/flat_set.hpp:508 #6 0x0000000000403b71 in std::insert_iterator<boost::container::flat_set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> > >::operator= (this=0x7fffffffdbd0, __value=@0x7ffff62e7320: 61595138) at /usr/include/c++/4.8/bits/stl_iterator.h:640 #7 0x000000000040350a in std::__copy_move<false, false, std::random_access_iterator_tag>::__copy_m<unsigned long const*, std::insert_iterator<boost::container::flat_set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> > > > (__first=0x7ffff62e7320, __last=0x7ffff6a50210, __result=...) at /usr/include/c++/4.8/bits/stl_algobase.h:335 #8 0x0000000000402c2f in std::__copy_move_a<false, unsigned long const*, std::insert_iterator<boost::container::flat_set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> > > > (__first=0x7ffff62af010, __last=0x7ffff6a50210, __result=...) at /usr/include/c++/4.8/bits/stl_algobase.h:390 #9 0x000000000040237f in std::__copy_move_a2<false, __gnu_cxx::__normal_iterator<unsigned long const*, std::vector<unsigned long, std::allocator<unsigned long> > >, std::insert_iterator<boost::container::flat_set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> > > > (__first=1210, __last=0, __result=...) at /usr/include/c++/4.8/bits/stl_algobase.h:428 #10 0x0000000000401b70 in std::copy<__gnu_cxx::__normal_iterator<unsigned long const*, std::vector<unsigned long, std::allocator<unsigned long> > >, std::insert_iterator<boost::container::flat_set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> > > > (__first=1210, __last=0, __result=...) at /usr/include/c++/4.8/bits/stl_algobase.h:460 #11 0x000000000040120f in Populate<boost::container::flat_set<unsigned long, std::less<unsigned long>, std::allocator<unsigned long> > > (input=std::vector of length 1000000, capacity 1000000 = {...}) at flat_set_crash.cpp:10 #12 0x0000000000400c50 in main () at flat_set_crash.cpp:39 (gdb) Since my refactoring of the code above, the crash location has changed, it used to be in: boost::container::vector::priv_forward_range_insert_at_end_expand_forward boost/container/vector.hpp:2205 unique_sorted_numbers.size() is 999752. Unfortunately producing a sequential list of numbers with std::iota and then changing one of them to the proceeding value didn't repro the problem. Ben

2 1

Re: [boost] [Boost.Interprocess] conditions variables get 10 times faster when opening a multiprocess browser
by Marcello Pietrobon 08 Sep '13

08 Sep '13

I've noticed the same 10 times acceleration even while I make a skyPE call... How can this have anything to do with interprocess programming? -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Interprocess-conditions-variables-… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 14

Problems with yield_k workaround. Still too slow.
by Marcello Pietrobon 07 Sep '13

07 Sep '13

Hello Boost team, As exposed by Gav Wood in http://boost.2283326.n4.nabble.com/Boost-Interprocess-Chronic-performance-o… Windows doesn't handle well the contest switching between threads. Basically if a thread is given a time to sleep for 1ms then the OS puts that thread on sleep for its entire timeslice (~20ms), no matter if the concurrent threads need a much shorter time to complete their job. The effect of this choice is that if you need to have two threads talking with each other through an emulated synchronization object, they take well 2 seconds to do just 100 back and forth. At least it seems to me that this problem arises only when *emulating * a synchronization object, which I understand is necessary, for example, in the interprocess library. It's not a problem of easy solution. There is an ongoing discussion in the interprocess library on how to fix this (see for example http://boost.2283326.n4.nabble.com/Boost-Interprocess-conditions-variables-… ) but clearly this is not a problem limited to it. The workaround http://www.boost.org/doc/libs/1_54_0/boost/smart_ptr/detail/yield_k.hpp improves the situation, yet only a bit. In order to isolate the problem I've run some tests using the interprocess library, with the example comp_doc_anonymous_conditionA.cpp (and B). This test is slowed down by this time of a factor ranging from 2 to 10, 100 or even 1000 or more times depending on how soon that infamous Sleep(1) is triggered. *The bottom line is that in yield_k.cpp we need to change the constant in the code * from 32 to *1000 * at least. I call this constant kMax: Here some test results, running XPsp3 on Xeon E5450 - dual socket 32bit CPU quad cores. 2GHz core speed. For test I changed comp_doc_anonymous_conditionA.cpp : that is 100000 iterations, while in comp_doc_anonymous_conditionB.cpp I've added the line just to emulate a job done by the thread while owning the mutex. That is: The results are (these numbers are representative of many tests I've run) : kMax = 32, jMax = 0 : time = 00:00:01.125000 kMax = 50, jMax = 0 : time = 00:00:00.403750 kMax = 100, jMax = 0 : time = 00:00:00.2803750 kMax = 65535, jMax = 0 : time = 00:00:00.203125 kMax ~= 64 is good kMax = 32, jMax = 10 : time = 00:00:32.843750 kMax = 100, jMax = 10 : time = 00:00:02.750000 kMax = 1000, jMax = 10 : time = 00:00:00.859375 kMax = 65535, jMax = 10 : time = 00:00:00.328125 kMax ~= 1000 is good kMax = 32, jMax = 100 : time = 00:04:01.953125 kMax = 50, jMax = 100 : time = 00:00:04.296875 kMax = 1000, jMax = 100 : time = 00:00:02.062500 kMax = 65535, jMax = 100 : time = 00:00:01.593750 kMax ~= 1000 is good If the job takes longer we need to increase kMax even more, but it seems that a value of 65535 cuts the problem and makes sure that a locked thread doesn't take most of the cpu time for more than one timeslice. -- View this message in context: http://boost.2283326.n4.nabble.com/Problems-with-yield-k-workaround-Still-t… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 6

[Graph] floyd_warshall crashes using optimzation
by Tim Keitt 06 Sep '13

06 Sep '13

I'm getting seg faults when I use optimization with floyd_warshall_shortest_paths. Without optimization it works fine. d here is defined as struct dmat_t { typedef std::vector<edge_weight_t> storage_t; dmat_t(vertex_t n) : ncol(n), storage(n * n) {} storage_t::iterator operator[](vertex_t row) { assert(row < ncol); storage.begin() + row * ncol; } vertex_t ncol; storage_t storage; }; Is this from 'inf' getting optimized out or how I defined dmat_t? Program received signal SIGSEGV, Segmentation fault. 0x000000000040162a in floyd_warshall_all_pairs_shortest_paths<boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, boost::no_property, boost::property<boost::edge_weight_t, double> >, edge_thinning_diameter_t::dmat_t, boost::adj_list_edge_property_map<boost::undirected_tag, double, double const&, unsigned long, boost::property<boost::edge_weight_t, double> const, boost::edge_weight_t>, std::less<double>, boost::closed_plus<double>, double, double> ( zero=<optimized out>, inf=<optimized out>, combine=..., compare=..., d=<synthetic pointer>, g=..., w=...) at /usr/include/boost/graph/floyd_warshall_shortest.hpp:115 115 d[*firstv][*firstv2] = inf; Also, it does not seem that floyd_warshall_shortest_paths is compatible with bundled properties. THK -- Timothy H. Keitt http://www.keittlab.org/

2 2

[atomic] atomic<int>::is_lock_free() returns false on iPad 4 (armv7s)
by Taylor Holliday 06 Sep '13

06 Sep '13

Hi, boost:atomic<int>::is_lock_free() returns false on iPad 4 (armv7s) but returns true on iPad 3 (armv7). Is this expected or did I build boost incorrectly? thanks! - Taylor W. Taylor Holliday, Owner/Founder Subatomic Software, San Francisco

3 3

[boost.chrono] Slow down process (if specifing c++11)
by Gaetano Mendola 06 Sep '13

06 Sep '13

Hi have tried the following code compiling it with gcc 4.6.3, with four combinations: 1) -O3 2) -O3 (commeting out the chrono call) 3) -O3 -std=c++0x 4) -O3 -std=c++0x (commenting out the chrono call) and I'm obtaining the following runtime values: 1) 8921 ms 2) 8915 ms 3) 9400 ms 4) 8933 ms as you can see the combination: "c++11 and chrono call" slows down the entire process. I have tried the same with gcc 4.8.1 and all times are more or less the same. At this point I'm not sure if it's a problem of chrono with gcc 4.6.3 or simply an issue of 4.6.3 disappeared in 4.8.1 series. Regards Gaetano Mendola Here the code I have used: #include <iostream> #include <boost/chrono.hpp> #include <sys/time.h> #include <math.h> int main() { cpu_set_t myAffinityMask; CPU_ZERO( &myAffinityMask ); CPU_SET(0, &myAffinityMask ); sched_setaffinity(0, sizeof(myAffinityMask), &myAffinityMask); volatile float* myMemoryA = new float[(1<<24)]; volatile float* myMemoryB = new float[(1<<24)]; struct timeval myStart; struct timeval myStop; struct timeval myResult; boost::chrono::time_point<boost::chrono::steady_clock> t1 = boost::chrono::high_resolution_clock::now(); gettimeofday(&myStart, 0); for (size_t i = 0; i < (1<<24); ++i) { myMemoryA[i] = i; myMemoryB[i] = i+1; } delete []myMemoryA; delete []myMemoryB; for (size_t j = 0; j < 100; ++j) { volatile float* myMemoryA = new float[(1<<24)]; volatile float* myMemoryB = new float[(1<<24)]; for (size_t i = 0; i < (1<<24); ++i) { myMemoryA[i] *= sqrtf(myMemoryB[i]); } delete []myMemoryA; delete []myMemoryB; } gettimeofday(&myStop, 0); timersub(&myStop,&myStart,&myResult); std::cout << "Time: " << myResult.tv_sec*1000 + myResult.tv_usec/1000.0 << std::endl; std::cout << "t1: " << t1 << std::endl; }

3 5

bjam assertion failure: does it really need stack alignment?
by Steve M. Robbins 05 Sep '13

05 Sep '13

Hi, A question for the bjam maintainers about https://svn.boost.org/trac/boost/ticket/8993 The file tools/build/v2/engine/function.c contains this check: static void check_alignment( STACK * s ) { assert( (size_t)s->data % sizeof( LIST * ) == 0 ); } However, things other than LIST* are allocated on the stack. For example expand_modifiers() allocates VAR_EDITS objects, whose size turns out not to be a multiple of sizeof(LIST*) on some architectures (m68k in the above ticket). Does check_alignment() still make sense? Thanks, -Steve

1 0

[thread] Can boost::this_thread::sleep_for() totally stop the thread?
by Klaim - Joël Lamotte 03 Sep '13

03 Sep '13

I'm having, sometime, trouble with a rare heisenbug (rare but appearing several times a week). I described it there: http://stackoverflow.com/questions/17918548/can-windows-totally-stop-a-thre… There I ask if it's possible for windows to totally stop a thread that is sleeping too often. As I'm using boost::thread for sleeping this specific thread that, for unknown reason, sometime totally stop working, I'm also wondering if the boost::this_thread() implementation could not be doing something that the OS might not like? ----- I'll report the content of the page here: Can Windows totally stop a thread if it's sleeping too often? I have a rare heisenbug in a multi-threaded application where the main thread, and only this thread, will just do nothing. As it's an heisenbug it's really hard to understand why this is happening. The main thread is basically just looping. In the loop, it check several concurrent priority queues which contain tasks ordered by time to be executed. It pop a task, see if it's time to execute it. If it's time, it will just schedule it into TBB's task scheduler (using a root task which is the parent of all other tasks). If it's not time, the task is pushed again in the priority queue. That's for one cycle. At the end of the cycle, the main thread is put to sleep for a very short time that I expect will be longer in practice but it's not really a problem, I just don't want it to use too much resources when not necessary. Litterally: static const auto TIME_SCHEDULED_TASKS_SPAWN_FREQUENCY = microseconds(250); while( !m_task_scheduler.is_exiting() ) // check if the application should exit { m_clock_scheduler.spawn_realtime_tasks(); // here we spawn tasks if it's time this_thread::sleep_for( TIME_SCHEDULED_TASKS_SPAWN_FREQUENCY ); } m_clock_scheduler.clear_tasks(); m_root_task.wait_for_all(); I have a special task that just log a "TICK" message each second. It is automatically rescheduling until the end of the program. However, when the heisenbug appear, I can see the "TICK" disappearing and the application not doing anything else than the work that occurs in non-main threads. So it appear that only the main thread is touched. The problem can come from different places, maybe in the scheduling logic, but then it's also the only thread that have a sleep call. That sleep is a boost::this_thread::sleep_for(). My question is: **Is it possible that Windows (7 64bit) consider the main thread to be sleeping often and decide that it should sleep for a longer period of time than asked or be definitely ended?** I expect that it is not possible but I would like to be sure. I didn't find any precision on this in online documentation so far. ----- I really suspect that the problem can't come from the sleeping function but I need to eliminate each potential source of problem to isolate it. Thanks for your time. Joel Lamotte

2 9

smart_ptr doesn't work when built with gcc on AIX
by Florent Guiliani 03 Sep '13

03 Sep '13

Hi, The Boost 1.54 smart_ptr atomic API code only supports the IBM xlC compiler under AIX. The attached patch make it also support the gcc compiler. I wanted to fill in a ticket for it on https://svn.boost.org/trac/boost/newticket but for some reason the ticket was classified as a spam by Trac. Anyone could help me here? One issue is the _sync*() APIs doesn't work when built optimized with GCC 4.8.0 on AIX 6.1 and 7.1 (and so the patch assume they don't work with all versions of GCC on AIX), so the patch undefine BOOST_SP_HAS_SYNC to prevent using those APIs. Another issue is the builtins.h file that Boost uses is missing, because it is installed as part of xlC. Under gcc, this patch will define assembly versions of the 2 builtins that are used in sp_counted_base_aix.hpp. Hope this gets through, -- Florent

1 0

[git] b2 headers not producing headers
by Ahmed Charles 02 Sep '13

02 Sep '13

I've tried following the instructions here: https://svn.boost.org/trac/boost/wiki/TryModBoost The 'b2 headers' command doesn't see to actually produce a boost directory. Is this supposed to work or is it just too soon?

3 2

[smart_ptr] Proposal to extract intrusive_ref_counter from Boost.Log
by Andrey Semashev 01 Sep '13

01 Sep '13

Hi, I'd like to move intrusive_ref_counter class from Boost.Log to Boost.SmartPtr. The class is intended to be used as a base class for a user's class that is intended to be used with intrusive_ptr. The class implements a reference counter and the related intrusive_ptr_add_ref/intrusive_ptr_release operations, so the user doesn't have to do that himself. Usage example: class my_class : public intrusive_ref_counter { }; intrusive_ptr< my_class > p = new my_class(); Besides just simplifying intrusive_ptr usage, the base class can be used as a sort of "void" as in shared_ptr< void >. I.e. intrusive_ptr< intrusive_ref_counter > can refer to object of any class that follows this protocol. Implementation: boost/log/utility/intrusive_ref_counter.hpp

5 10

Re: [boost] [utility] Proposal to extract some components from Boost.Log
by Daryle Walker 01 Sep '13

01 Sep '13

I don’t think you need a “constexpr_if.” You can unconditionally put BOOST_CONSTEXPR in the definition. This will unconditionally add “constexpr” to the member operator (for C++11 systems), which will be ignored if the compiler determines that the attached function (or a particular call) is disqualified from being used in constant expressions. So any extra preprocessor work, or a variant macro, is unnecessary. Sent from Windows Mail From: Andrey Semashev Sent: ‎Sunday‎, ‎September‎ ‎01‎, ‎2013 ‎4‎:‎40‎ ‎AM To: boost(a)lists.boost.org On Sunday 01 September 2013 03:27:06 Daryle Walker wrote: > > Date: Wed, 28 Aug 2013 12:14:51 +0400 > > From: andrey.semashev(a)gmail.com > > > > 1. BOOST_EXPLICIT_OPERATOR_BOOL() macro for defining explicit operator > > bool() for a class. > > a. It isn't marked "constexpr." I can add that myself before using > "BOOST_EXPLICIT_OPERATOR_BOOL" in "boost/rational.hpp," but what happens if > someone corrects it in "explicit_operator_bool.hpp"? Will the (temporary) > double definition cause an error? Well, since there isn't a constexpr_if or something, I don't see a way to add it to BOOST_EXPLICIT_OPERATOR_BOOL. I could add BOOST_EXPLICIT_OPERATOR_BOOL_PP(pre, post), which would add pre() and post() before and after the operator signature. For example:

3 4

[multimethods] Proposal: Open Multi-Methods
by Jean-Louis Leroy 01 Sep '13

01 Sep '13

Hi, I am working on library that pretty much implements what Pirkelbauer, Solodkyy and Stroustrup describe in their paper "Open Multi-Methods for C++" - although there are some divergences. I have posted it on GitHub: https://github.com/jll63/multimethods. Please examine the files in the "examples" directory to get an idea of how to use it. Salient features are: * syntax: is relatively uncluttered. There are no limitations on the number of virtual arguments. Virtual and non-virtual arguments can be arbitrarily mixed. Multiple inheritance is supported, with some limitations - see below. * speed: close to a virtual function call when the hierarchies involved in the virtual arguments collaborate with the library. Calling a method that does nothing, with a single virtual argument in a single inheritance hierarchy is 33% slower than the equivalent virtual function call. The difference becomes unnoticeable if the functions perform a few simple maths operations. See tests/benchmarks.cpp. * size: the dispatch table is constructed in terms of class groups. This results, most of the time, in a table devoid of redundancies. The size is bounded by the product of the number of specializers - not classes - in each dimension. * support for "foreign" class hierarchies: the library can be used without modifications to existing classes, at the cost of lower performance. Collaborating and foreign arguments can be freely mixed. Performance is still quite good, see the benchmarks. * next: a pointer to the next most specialized method is available inside method specializations - see examples/next.cpp. Alternatively, it is possible to call a specialization directly. Current limitations are: * restrictions on hierarchy: the classes involved in a method call must have a single root. Repeated inheritance is not supported. Multiple inheritance is supported, provided that the two conditions above are respected. * no overloading: multi-methods are implemented as constexpr function objects. This does not allow for overloading. This restriction can be easily side-stepped by wrapping multi-methods with different names in a set of overloaded functions. I know how to make multi-methods functions instead of objects, at the cost of a slightly less nice syntax for specializers. This is open to discussion. Besides, the library differs from Stroustrup et al's paper on the following points: * a specializer specializes only one multi-method: what would "next" mean otherwise? What would its static type be? * pure multi-methods are allowed: if called, an exception is thrown. This seems a better choice given that most of the time the declared virtual arguments will be abstract classes anyway. The library is essentially feature complete (if anything ever is). I am now going to work on the documentation, a build system, some clean up and compatibility (I tested it only with g++ 4.7.2 only so far). Is there interest in the Boost community for this stuff? If yes, I will adapt it to the guidelines and submit it for formal review. Of course, suggestions are welcome. Thank you for your time, Jean-Louis Leroy

5 10

[thread] MinGW/gcc compile error in thread.cpp
by Emil Dotchevski 01 Sep '13

01 Sep '13

Building the trunk version, I get this on MinGW: gcc.compile.c++ ..\..\..\bin.v2\libs\thread\build\gcc-mingw-4.7.2\debug\link-sta tic\threading-multi\win32\thread.o ..\..\..\libs\thread\src\win32\thread.cpp: In member function 'bool boost::threa d::start_thread_noexcept()': ..\..\..\libs\thread\src\win32\thread.cpp:238:9: error: reference to 'uintptr_t' is ambiguous In file included from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/stdint.h:3:0 , from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/../../../../include/ wchar.h:479, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/cwchar:4 6, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/bits/pos types.h:42, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/bits/cha r_traits.h:42, from c:\mingw\bin\../lib/gcc/mingw32/4.7.2/include/c++/string:4 2, from ..\..\../boost/date_time/c_time.hpp:18, from ..\..\../boost/date_time/time_clock.hpp:16, from ..\..\../boost/thread/thread_time.hpp:9, from ..\..\../boost/thread/win32/thread_data.hpp:10, from ..\..\../boost/thread/thread_only.hpp:15, from ..\..\..\libs\thread\src\win32\thread.cpp:17: Emil

3 2

[gil::io] clang compiler error
by Christian Henning 31 Aug '13

31 Aug '13

Hi all, I'm trying to fix some compiler errors with clang and the new gil::io. The following trivial code just wont compile: extern "C" { #include <stdio.h> #include <jpeglib.h> } int main() { jpeg_create_compress(NULL); return 0; } The error is: undefined reference to `jpeg_CreateCompress' I guess it's a very simple solution but I'm not much experienced with clang and gcc. Thanks, Christian

2 3

[cpo-proposal] presentation of the idea
by Santiago Tapia 29 Aug '13

29 Aug '13

Hi everyone, I would like to make a proposal for a new library. I only have a draft without documentation but I would like to know people’s opinion about the idea before making a formal proposal. The library will be named CPO (containers for polymorphic objects) and it will provide containers to store dynamic allocated objects from a class hierarchy. I have drafted one container and I have two more in process. The cpo library could be an alternative solution for boost pointer container library or some other solutions that use pointers. In order to understand the idea, I think that the following example of the use of the library might be better than a long explanation: #include <boost/cpo/classifier.hpp> #include <iostream> using namespace boost::cpo; class base { public: virtual int do_something(int a) const = 0; }; class derived_A : public base { public: derived_A(int b) : data(b) {} virtual int do_something(int a) const { return a + data; } protected: int data; }; class derived_B : public base { public: derived_B(int b) : data(b) {} virtual int do_something(int a) const { return a - data; } protected: int data; }; int main(int argc, char** argv) { classifier<base, std::allocator> collection; collection.insert( derived_A(21) ); collection.insert( derived_B(40) ); classifier<base, std::allocator>::iterator i, e = collection.end(); for ( i = collection.begin(); i != e; ++i ) { const base& x = *i; std::cout << x.do_something(6) << std::endl; } return 0; } ---- Program output: 27 -34 ---- Some details and advantages must be remarked in the provided example: - There are not any pointers in the client code (the example). - The container's name is classifier because it classifies objects internally using the RTTI. - The container classifier is _not_ a sequence. - Any iterator of the classifier dereferences to the base class. - The allocator argument in the classifier will be applied to every object added to the classifier. Thus, the allocator is provided without its argument. The std::allocator is the default argument. - The classifier uses continuous storage in memory for objects of the same type, therefore it is expected to improve cache efficiency with respect to solutions that use pointers (and new to allocate objects), especially if the client code uses some cache-aware allocator. I think that the idea will be interesting and useful. Although I have registered a project in sourceforge, classifier_container, I must insist: the library is under development and without documentation. I look forward to your comments and I thank you for them in advance. Best Regards, Santiago Tapia CITEF CENTRO DE INVESTIGACIÓN EN TECNOLOGÍAS FERROVIARIAS | RAILWAY TECHNOLOGY RESEARCH CENTRE UNIVERSIDAD POLITÉCNICA DE MADRID ESCUELA TÉCNICA SUPERIOR DE INGENIEROS INDUSTRIALES Santiago Tapia Fernández José Gutiérrez Abascal, 2 | 28006 Madrid TEL + 34 91 336 4267 | FAX + 34 91 561 8618 E-MAIL stapia(a)etsii.upm.es; www.citef.industriales.upm.es

8 45

about serialization
by lz＠sina 29 Aug '13

29 Aug '13

hi! I'm wonding if I can change the in "interface_oarchive.hpp": template<class T> Archive & operator<<(T & t){ this->This()->save_override(t, 0); return * this->This(); } to template<class T> Archive & operator<<(const T & t){ this->This()->save_override(t, 0); return * this->This(); } and in "polymorphic_oarchive_route.hpp" template<class T> polymorphic_oarchive & operator<<(T & t){ return polymorphic_oarchive::operator<<(t); } to template<class T> polymorphic_oarchive & operator<<(const T & t){ return polymorphic_oarchive::operator<<(t); } , so I can write code like this: enum E {}; class C { private: E e; public: E getE() const; void setE(const E e); }; template<class Archive> inline void save_construct_data(Archive & ar, const C * t, const unsigned int file_version) { // save data required to construct instance ar << t->getE(); // without changing the liberary code, I'll have to write like this: //int x = t->getE(); //ar << x; } I'm not sure about the changes, can anybody verify it? -------------- lz@sina

1 0

FW: [cfe-dev] Documenting Clang: question about how best to deliver the doc
by Paul A. Bristow 29 Aug '13

29 Aug '13

I've copied the posting below because it shows that Doxygen comments syntax are being even more widely used to add documentation of code (as opposed to writing tutorial and other descriptive text). Doxygen comments are post-processed to produce a C++ Reference section in many Boost program docs prepared using Quickbook. I suggest that this is a good method for future proposed libraries. In case you are not familiar with Doxygen, http://www.stack.nl/~dimitri/doxygen/manual/index.html here is a silly example to give the flavour of the comments (they start with the backslash trip character and are within C/C++ comments with an added !). template <typename T> int donowt(int I, char j) { /*! The ! shows that this is a Doxygen-syntax comment. Non-member free function that does nowt useful at all describing the function. \tparam T unused template parameter. \param i is an argument that is ignored completely. \param j Another argument. \pre No preconditions. \post No side effects. \returns -1 always. \throws std::exception if the unthinkable happens. \sa See also another function. */ return -1; } // int donowt(int i) Of course, the value from all this comes from the quality of the *information provided as comments*, describing the use of the parameters, templates, pre and post conditions (documenting but not enforcing concepts) and returns... Doxygen also analyses the code (now optionally using the Clang compiler - it used to get confused by some code, especially code that didn't compile!) and provides many cross-referencing links automatically, a great benefit to the authors and the readers. Doxygen remains under active development thanks to <http://www.stack.nl/%7Edimitri/doxygen/index.html> Dimitri van Heesch. It is Open-Source and entirely free and very widely used for several languages. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com From: cfe-dev-bounces(a)cs.uiuc.edu [mailto:cfe-dev-bounces@cs.uiuc.edu] On Behalf Of Morrison, Michael Sent: Tuesday, August 27, 2013 10:40 PM To: cfe-dev(a)cs.uiuc.edu Subject: Re: [cfe-dev] Documenting Clang: question about how best to deliver the doc Thanks to everyone on this thread who replied to our query about what approach to take for our Clang documentation. Your thoughtful comments were very helpful to our understanding of the issues and of the preferences of the community. We’ve reviewed your responses to the options that we proposed, and we’ve decided to pursue the following option: > 1a) Maintain the documentation in Doxygen. Any other formats required (HTML, XML, reST/Sphynx, and so on) can be generated on-the-fly from the Doxygen comments as needed. We have a good idea about how to proceed with this option, and we expect that we can begin submitting our updated Doxygen documentation later this summer. Cheers, Michael

1 0