- Boost - lists.preview.boost.org

[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

[voronoi]medial axis
by Louis Lavery 29 Aug '13

29 Aug '13

Hello, I'm hoping to use boost voronoi to construct the (internal) medial axis for closed shapes (with holes). I need to work out which vertices of the voronoi are inside, outside and on a boundary. So my first goal is to determine which vertices correspond to the ends of the input segments (boundary vertices). The way I do this at the moment, is to look at each edge and test if its source vertex, vertex0(), is equal to either end point of the segment contained by the edge's cell. (1) If it is then it's a boundary vertex otherwise it's not. Is that correct? (2) When comparing a vertex with an input point can I do an exact compare (==) or should I use a tolerance (epsilon)? Thanks, fuzzy.

1 0

[RPC] Boost.Asio to write *concurrency ready* code
by Niall Douglas 28 Aug '13

28 Aug '13

On 27 Aug 2013 at 12:00, boost-request(a)lists.boost.org wrote: > I am *not sure* if anyone else has made such discovery, anyway, > comment is welcomed. What you have discovered is well known I am afraid. Indeed, proposed Boost.AFIO from this year's GSoC implements an asynchronous chainable closure execution engine on ASIO, and you can read documentation on how AFIO is equivalent to Google's and Microsoft's WG21 closure execution engine proposals here: https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho w_boost_afio_relates_to_exisit.html Paul did up a great matrix mapping APIs from those engines to AFIO equivalents at https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho w_boost_afio_relates_to_exisit/comparison_of_afio_with_other_cl.html and https://ci.nedprod.com/job/Boost.AFIO%20Build%20Documentation/Boost.AF IO_Documentation/doc/html/afio/quickstart/closure_execution_engines/ho w_boost_afio_relates_to_exisit/other_useful_comparisons.html. If we get time before GSoC closes, we may just go ahead and implement N3562 (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3562.pdf) using AFIO as it would be incredibly trivial to do so. However, the Boost community only voted closure execution support as third most important - they ranked directory change monitoring as highest, so that's what me and Paul are implementing now. (FYI to those interested, we're going to deliver some *seriously* performant directory monitoring. Testing of our direct kernel syscall based implementation suggests watching a 1 million file entry directory for changes will actually work on Windows, albeit pegging a 3.5Ghz 4 core machine at 75-85% of all CPUs. Linux sadly lacks the syscalls to match Windows, but a 100,000 entry directory may well work just fine) Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

4 10

Problem with boost::function on BlackBerry10
by Jens Weller 28 Aug '13

28 Aug '13

Hi boost Community, I've got a little problem with getting boost::function to run on BlackBerry10. So far, I was able to compile, link and run successfully when I do comment out some stuff in boost. Surely not the right way to do it, but proves to me that those lines are the problem, I'm looking for a fix, maybe a define I need to add to let this compile without changing boost headers. In total its only 3 errors, where 2 boil down to the same macro: /home/jweller/cpp/libraries/boost_1_54_0/boost/type_traits/detail/cv_traits_impl.hpp:25: Parenthesis/brace mismatch between #if and #else branches; using #if branch /home/jweller/cpp/libraries/boost_1_54_0/boost/type_traits/detail/cv_traits_impl.hpp:93: Excess closing brace in C++ code (or abuse of the C++ preprocessor) /home/jweller/cpp/libraries/boost_1_54_0/boost/type_traits/msvc/typeof.hpp:43: Ignoring definition of undeclared qualified class These two are in cv_traits_impl.hpp in boost/type_traits/detail/, caused by this line: #if !(BOOST_WORKAROUND(__GNUC__,== 3) && BOOST_WORKAROUND(__GNUC_MINOR__, <= 2)) This line is twice in this fiel, hence the 2 errors. qcc version is gcc 4.6.3. It looks to me like BOOST_WORKAROUND isn't doing the right thing here to me. The 2nd error is more strange. /home/jweller/cpp/libraries/boost_1_54_0/boost/type_traits/msvc/typeof.hpp:43: Ignoring definition of undeclared qualified class Somehow typeof.hpp of msvc is getting pulled in. I've tried also the from BlackBerry provided boost version from https://github.com/blackberry/Boost, which shows exact the same errors. And is the one I (cruely) patched currently. Commenting out the #if !(is < 3.2) resolves the problem, but msvc is still pulled in. Also commenting in this header the cause out lets it compile, but thats nothing then a bad workaround. Currently I have only build for the simulator, but the problem is most likely also existing for the device build chain. At least the first two errors might be caused by BOOST_WORKAROUND, maybe there is a value that isn't configured correctly on this platform. Also how do I get closer to the source of the msvc code being dragged in? So, question is, is there maybe a define to help boost getting digested by the qcc toolchain? kind regards, Jens Weller

2 4

Migrating lists.boost.org
by DongInn Kim 28 Aug '13

28 Aug '13

Dear Boost community, I think it is time to move mailing lists and mail archives of lists.boost.org to the new server (wowbagger.crest.iu.edu) If it is not a bad time, can we migrate the services at 9am (E.T.) on Aug 28th? Date: Wednesday, Aug 28th, 2013 Time: 6:00am-8:00am Pacific US time 7:00am-9:00am Mountain US time 8:00am-10:00am Central US time 9:00am-11:00am Eastern US time 1:00pm-3:00pm GMT The following services may not be available during the migration. - Web services (e.g., http://lists.boost.org/) - Mailing lists: boost boost-announce boost-bugs boost-build boost-cmake boost-commit boost-docs boost-interest boost-mpi boost-test boost-testing boost-users geometry glas proto threads-devel ublas Please let me know if you have any questions or concerns about this migration. Regards, -- - DongInn

2 2

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

28 Aug '13

>Date: Tue, 13 Aug 2013 07:42:03 -0500 >From: Larry Evans <cppljevans(a)suddenlink.net> >To: boost(a)lists.boost.org >Subject: Re: [boost] [cpo-proposal] presentation of the idea > > What if the class hierarchy is used to model a graph that > contains cycles. For example, something like a spirit grammar > where a non-terminal on the rhs of a non-terminals definition? I don't see any problem, as long as they fulfill the requirements of the classifier container, i.e. the objects to be inserted should be copyable and derived from the base class in the template argument of the classifier. > Wouldn't this require some sort of smart pointer or other > garbage collection method with the ability to collect cycles? > I don't think so, the classifier container should be able to replace any occurence of something like: vector< shared_ptr <base> > in almost in any circunstance. Beside, you could avoid virtual destructors because the classifier will destroy the object directly not from a base* pointer.

5 6