- 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