- Boost - lists.preview.boost.org

[graph] ranges used by boost.graph not compatible with c++11 range-based-for
by Nathan Ridge 03 Oct '13

03 Oct '13

>> Sadly, I don't think there s a way of turn an std::pair of iterators into >> a range-based-for-compliant range (see [1]). > > correct me if I'm missing something, but when performing ADL the > namespaces of the template parameters > are in the set of associated namespaces. So, one could simply overload > begin/end in the namespace where > the iterator types are defined ... You're right, a per-namespace solution is possible. I don't think it can be done in general, though (i.e. for all std::pairs of iterators in one stroke). I'm not familiar with BGL - are the iterator types in question defined in a namespace under the library's control, or could they be user-provided types (in which the case the user would have to put the begin()/end() in their own namespace)? Regards, Nate

2 1

[graph] ranges used by boost.graph not compatible with c++11 range-based-for
by Gabriel Redner 03 Oct '13

03 Oct '13

I noticed today that code of this form does not compile: typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, Node, Edge> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; Graph graph = ...; Vertex vertex = ...; for (Edge edge: boost::out_edges(vertex, graph)) {...} The reason is that out_edges returns a std::pair of iterators. This is a valid range in the sense of boost.range, and so is compatible with BOOST_FOREACH. However, this is not a valid range in the sense of c++11 range-based-for. It's not clear whether this can easily be changed. In a perfect world these functions should probably return something like boost::iterator_range which would be compatible with both boost- and language-level concepts of range-ness. However, the graph documentation explicitly names the return types of out_edges et. al. (see [1]) as std::pairs, which eliminates some wiggle room. Is there an alternate way to address this? -Gabe [1] http://www.boost.org/doc/libs/1_53_0/libs/graph/doc/IncidenceGraph.html

4 4

Heads up: 1.55.0 deadlines approaching
by Marshall Clow 02 Oct '13

02 Oct '13

See the calendar at: http://www.boost.org/development/index.html September 16: 1.55.0 Closed for new libs and breaking changes September 23: 1.55.0 Closed, except bug fixes and doc changes September 30: 1.55.0 Closed, except by permission October 7: 1.55.0 Beta release -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

6 10

[accumulators] Help understanding implementation of weighted accumulators
by Gabriel Redner 02 Oct '13

02 Oct '13

Hi folks, I am trying to implement a weighted accumulator, but I'm having trouble understanding a few things about the existing ones. Looking at the implementation of weighted_sum, I see (weighted_sum.hpp:37): template<typename Args> weighted_sum_impl(Args const &args) : weighted_sum_( args[parameter::keyword<Tag>::get() | Sample()] * numeric::one<Weight>::value ) { } My questions are: - It's taking the first sample from the args and multiplying it by a weight of 1. Isn't this wrong - ignoring the real weight of this sample? Shouldn't this produce incorrect results? - I've never understood anyways how there can be an initial argument during construction of the accumulator. I haven't found any explanation in the docs beyond "Maybe there is an initial value in the argument pack". Maybe? How? Probably more questions later. Thanks, -Gabe

2 4

[thread] semaphore
by Tim Blechmann 02 Oct '13

02 Oct '13

hi all, i've submitted an implementation of semaphores for boost.thread to trac [1]. they provide an interface similar to boost.interprocess semaphores, with the exception of having chrono-style try_wait_for and try_wait_until members for timed_wait. the patch provides the following implementations: * win32 semaphores (tested with windows 8) * posix semaphores (tested with linux) * dispatch semaphores (tested with osx 10.8) * mutex/condition_variable/counter emulation the native implementations are much faster than the fallback, in microbenchmarks with high contention, i've seen a speedup of 30 to 80. would be great if they can be incorporated into boost.thread. comments/suggestions on the API are highly appreciated. cheers, tim [1] https://svn.boost.org/trac/boost/ticket/8797

10 29

Is there interest in a Simulation library?
by Damian Vicino 01 Oct '13

01 Oct '13

Dear All, Following the on-going efforts on development and standardization of C++, especially application-oriented libraries, we are soliciting expression of interest within the C++ community for a new Boost library for building Discrete-Event simulators. We plan to build this new library on the latest features of the C++11 standard, for possible inclusion in a future version of the C++ standard. This work is based on our experience in building C++-based simulators for over 20 years, exploring various optimization and algorithms, and leading to a significant number of reseach publications. Writing a new version of a simulation library based on the latest features of the C++ language has started as new joint research project of University of Nice Sophia Antipolis, UMR CNRS 7172 (FR), INRIA Sophia Antipolis (FR), and Carleton University (CAN). Of course, anyone interested in joined this effort is more than welcome! Damian Vicino, PhD Candidate Université Nice Sophia Antipolis & Carleton University Dr. Olivier Dalle, Maître de Conférences, Université Nice Sophia Antipolis Pr. Gabriel Wainer, Carleton University

5 13

[polygon] Release testing stalled... Missing source file.
by Rene Rivera 01 Oct '13

01 Oct '13

I commented out one of the test cases in the release branch because the source file for the test is non-existent. Rene. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

2 1

testers blocked after changeset 85924 in trunk.
by Vicente J. Botet Escriba 01 Oct '13

01 Oct '13

Hi, the last change set that has been taken in account in trunk regression test is 85924. I'm expecting a lot of testers to cycle. Note that release regressing test are not blocked. Could someone explain what is happening? Best, Vicente

8 12

Review request: Require compiler support for partial template specialization.
by Stephen Kelly 01 Oct '13

01 Oct '13

Hi there, Following from http://thread.gmane.org/gmane.comp.lib.boost.devel/243923/focus=243924 I am posting a more focused and specific request to review a patch to bump compiler requirements to require support for partial template specialization. This allows the removal of a lot of workaround code: src/boost-trunk{master}$ ../kf5/remove_def.py BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION src/boost-trunk{master}$ git diff --shortstat 192 files changed, 4798 deletions(-) Obviously I would not commit all of that as a single patch. Any comments? Thanks, Steve.

4 8

Do/can we have a C++11 variadic integer list?
by Daryle Walker 01 Oct '13

01 Oct '13

I'm talking about this: template < std::size_t ...N > struct indices_too { using next = indices_too<N..., sizeof...(N)>; }; template < std::size_t N > struct make_indices_too { using type = typename make_indices_too<N - 1u>::type::next; }; template < > struct make_indices_too<0u> { using type = indices_too<>; }; I've written things like this 4 times for my prototype Boost classes, and I want it in Boost already so I can just reference that version. Something like it will come in C++14, but we could provide it here for C++11 users? Do we already have one? Here's how to use one: template < typename Function, typename T, class Tuple, std::size_t ...I > void apply_x_and_exploded_tuple_impl( Function &&f, T &&x, Tuple &&t, indices_too<I...> ) { using std::forward; forward<Function>( f )( forward<T>(x), forward<typename std::tuple_element<I, typename std::remove_reference<Tuple>::type>::type>(std::get<I>( t ))... ); } template < typename Function, typename T, class Tuple > void apply_x_and_exploded_tuple( Function &&f, T &&x, Tuple &&t ) { using std::forward; apply_x_and_exploded_tuple_impl( forward<Function>(f), forward<T>(x), forward<Tuple>(t), typename make_indices_too<std::tuple_size<typename std::remove_reference<Tuple>::type>::value>::type{} ); } Daryle W.

3 2

orphaned tickets
by Joel Falcou 01 Oct '13

01 Oct '13

What's the protocol to handle lingering tickets of un maintained components. I wish #9169 and #9170 could be merged to trunk soonish. I cna do it myself but i dont want to breach any protocol. Regards

3 2

REQ: Looking for access to a Haswell machine to test Boost memory transactions code
by Niall Douglas 30 Sep '13

30 Sep '13

Dear Boost Devs, Last night I may have implemented some Boost macro based support for simple memory transactions. Basically one does this: STLLockable lockable; ... BOOST_BEGIN_MEMORY_TRANSACTION(lockable) { // Transaction code } BOOST_END_MEMORY_TRANSACTION(lockable) This can turn into __transaction_relaxed, or Intel TSX falling back onto a spin lock. It's very simple, but it ought to work and with very significant performance improvements on TSX capable hardware. The problem is that I don't have access to an Intel Haswell CPU to test the code upon. I think its design is correct through introspection, but if a kind Boost dev could lend me access to their Haswell machine via SSH - or even just offer to debug some binaries for me, I would be very grateful. Thanks, Niall -- Currently unemployed and looking for work. Work Portfolio: http://careers.stackoverflow.com/nialldouglas/

2 2

[release][interprocess] regression in Windows
by Joaquin M Lopez Munoz 30 Sep '13

30 Sep '13

As indicated by the regression testers, see for instance: http://tinyurl.com/qabv7dm This is affecting also Boost.Flyweight, which uses <boost/interprocess/detail/intermodule_singleton.hpp> for its intermodule_holder component. Thank you, Joaquín M López Muñoz Telefónica Digital

2 1

Boost and clang under Windows
by Edward Diener 30 Sep '13

30 Sep '13

First off I am not of course proposing any changes to the upcoming release build of Boost 1.55 for clang under Windows. It turns out that clang under Windows, possibly to support the ability to use Windows header file, becomes another compiler which defines _MSC_VER. I believe the Intel compiler also does this but there may be some others. However clang is a much more strictly conforming to the C++ standard compiler than VC++ and does not have VC++'s quirks. This presents a problem in Boost. The Boost header files have numerous places where testing the macro _MSC_VER produces slightly different behavior based on the fact that the code is being used by VC++ or a compiler with the same behavior as VC++. But clang does not have the same behavior as VC++ despite defining _MSC_VER. Can I go ahead and change some of these situations as necessary to get clang under Windows to work properly with Boost code ? The usual change will be to test not only _MSC_VER but also that __clang__ is not defined for keeping the current implementation which assumes a VC++ compatible compiler with VC++ behavior. I am willing to make those changes in 'trunk' and keep an eye out for any significant failures in unit tests for our current regression tests. I have already made a slight change to Boost PP config.hpp on 'trunk' so that clang for Windows will pass the preprocessor tests. I am willing to work on other changes but I do not want to go ahead and do so if the maintainers of other libraries see any reasons for me not making the changes on 'trunk'. Of course I will test any changes I make locally to make sure they do not affect any other _MSC_VER defined compilers as well as with VC++. But the changes themselves should be fairly simple, just adding a check that __clang__ is not defined as part of the VC++ type behavior. Obviously something like the many tests for _MSC_VER in order to specify #pragma once will not change but some other situations will to exclude clang from the _MSC_VER functionality.

9 20

[clang][Windows] Volunteer for a Boost regression test runner for Clang on Windows
by Beman Dawes 30 Sep '13

30 Sep '13

Chandler Carruth has asked for a volunteer to start running boost regression tests for the Clang on Windows project. For more about this project, see http://blog.llvm.org/2013/09/a-path-forward-for-llvm-toolchain-on.html. Chandler cornered me at the C++ committee meeting last week, and emphasized how much they would like to see boost tests passing using Clang in a Visual Studio environment. This would be a big plus for boost developers and users in the Windows environment IMO, so I hope we can help them out. This project is at an early stage, and many boost tests currently fail, so there is a lot of work to be done. --Beman

4 7

[scope_exit] D-style scope(failure) and scope(success) in C++
by Evgeny Panasyuk 30 Sep '13

30 Sep '13

Hello all, D language has scope(exit), scope(success) and scope(failure) features - http://dlang.org/statement.html#ScopeGuardStatement : "... scope(exit) executes NonEmptyOrScopeBlockStatement when the scope exits normally or when it exits due to exception unwinding. scope(failure) executes NonEmptyOrScopeBlockStatement when the scope exits due to exception unwinding. scope(success) executes NonEmptyOrScopeBlockStatement when the scope exits normally. ..." Andrei Alexandrescu describes some of uses cases for scope(exit), scope(success), scope(failure) at his recent talk : http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2012/Three-Unlikely-Suc… There is Boost.ScopeExit library which emulates D's scope(exit) via BOOST_SCOPE_EXIT macro, but there are no analogues for D's scope(failure) and scope(success). Current alternative for these features is ScopeGuard idiom ( http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Scope_Guard , http://www.drdobbs.com/cpp/generic-change-the-way-you-write-excepti/1844037… ). Boost.ScopeExit library itself suggests to use ScopeGuard - http://www.boost.org/doc/libs/1_51_0/libs/scope_exit/doc/html/scope_exit/al… : " Boost.ScopeExit is similar to scope(exit) feature built into the D programming language. A curious reader may notice that the library does not implement scope(success) and scope(failure) of the D language. Unfortunately, these are not possible in C++ because failure or success conditions cannot be determined by calling std::uncaught_exception (see Guru of the Week #47 for details about std::uncaught_exception and if it has any good use at all). However, this is not a big problem because these two D's constructs can be expressed in terms of scope(exit) and a bool commit variable (similarly to some examples presented in the Tutorial section). " I have made small library ( https://github.com/panaseleus/stack_unwinding#d-style-scope-guardsactions ) which supplies primitives (class unwinding_indicator, UNWINDING_AWARE_DESTRUCTOR macro) to determining when object destructor is called due to stack-unwinding or due to normal scope leaving. Currently it is implemented on top of platform-specific implementation of uncaught_exception_count function and tested on: {MSVC2005, MSVC2008, MSVC2010, MSVC2012, GCC4.1.2, GCC4.4.6, Clang3.2}x{x32, x64}x{default settings}. uncaught_exception_count is a function similar to std::uncaught_exception from standard library, but instead of boolean result it returns unsigned int showing current count of uncaught exceptions. Such primitives allow us to implement scope(success) and scope(failure) features in C++. I have made several proof-of-concepts: * https://github.com/panaseleus/stack_unwinding/blob/master/examples/scope_ac… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/example_… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/scope_gu… * https://github.com/panaseleus/stack_unwinding/blob/master/examples/boost_sc… boost_scopes.cpp example shows usage of BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS: try { cout << "Case #1: stack unwinding" << endl; BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END throw 1; } catch(int){} { cout << "Case #2: normal exit" << endl; BOOST_SCOPE_EXIT(void) { cout << "exit" << endl; } BOOST_SCOPE_EXIT_END BOOST_SCOPE_FAILURE(void) { cout << "failure" << endl; } BOOST_SCOPE_FAILURE_END BOOST_SCOPE_SUCCESS(void) { cout << "success" << endl; } BOOST_SCOPE_SUCCESS_END } Output is: " Case #1: stack unwinding failure exit Case #2: normal exit success exit " Currently BOOST_SCOPE_FAILURE and BOOST_SCOPE_SUCCESS are implemented based on boost_1_51_0/boost/scope_exit.hpp by copy-paste and replace (just for proof-or-concept, of course it is possible solution with much less duplication). Semantically meaningful changes can be viewed as diff at https://github.com/panaseleus/stack_unwinding/commit/d5513404323490ea99d9b6… Before posting here, I made posts on several C++ forums, but unfortunately get only a few feedbacks regarding ScopeFailure and ScopeSuccess. What do you think? Thank you. P.S. Related discussion: http://lists.boost.org/Archives/boost/2010/09/171051.php Best Regards, Evgeny Panasyuk

6 27

Program Options library and Unicode compliance
by munsingh 30 Sep '13

30 Sep '13

I noticed that the class option_description does not work with wstring, instead works with string. Does anyone has any idea why is it so? Regards, Manish -- May the force be with you

2 1

[clang] How to use CLang for Windows?
by Daryle Walker 30 Sep '13

30 Sep '13

There was a recent conference where the Clang team announced a version of Clang that's supposed to work on Windows (as opposed to kind-of working if you try real hard). It's accessible from the command line if you put Clang in the PATH. I just found out it's supposed to be used from Visual Studio ('10 or '12) after tweaking a project's settings. Can it be used from out BJam system? How will it find right header files to use? (Does it automatically use the ones from MSVC?) Daryle W.

8 36

Code to address the requirement 7(a) of Boost.IOStreams Roadmap
by Gene Panov 29 Sep '13

29 Sep '13

Colleagues, I posted this before, but didn't get answers to some questions so far. I think I possibly addressed the "output" part of requirement 7(a) from the IOStreams Roadmap https://svn.boost.org/trac/boost/wiki/IostreamsRoadmap in this library https://code.google.com/p/async-ostream/ Does it make sense if I create a patch for Boost.IOStreams to add those five files and ask the maintainer (or volunteers) for feedback? Regards, Gene

1 0

[variant] Stalled testing, from missing file.
by Rene Rivera 29 Sep '13

29 Sep '13

Note to the variant maintainers.. I commented out a test which was referring to a non-existent source file. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

3 2

[range][algorithms] How about making the range algorithms pipeable as the range adaptors are?
by Viktor Sehr 28 Sep '13

28 Sep '13

It would be syntactically really nice if the stl-algorithms wrapped in boost range were pipeable, as with the adaptors, making it seamless to combine them in left-to-right statements For non-mutating algorithms I think it's an obvious evolvement const auto& max_pos = some_range | filtered(..) | max_element; const auto& num_elements = some_range | filtered(..) | count(42); ...instead of inside out as it is now const auto& max_pos = max_element(some_range | filtered(..)); const auto& num_elements = count(some_range | filtered(..), 42); For non-mutating algorithms it might not be an obvious solution, as the range beneath is modified, but I still think it should be possible boost::erase(my_vector | sort | unique); ...instead of boost::erase(unique(sort(my_vector)); *Implementation example with std::accumulate:* // Tag to be recognized by the global pipe operatortemplate <typename value_type>struct accumulate_argument_tag { accumulate_argument_tag(const value_type& value) : value_(value) {} const value_type& value_; }; struct accumulate_tag { // Put the regular algorithm as an operator() function where the first argument is the range template <typename range_type, typename value_type> value_type operator()(const range_type& range, const value_type& start) { return std::accumulate(std::begin(range), std::end(range), start); } // If no range is provided, return a tag which contains the argument, which can then be identified by the global pipe operator template <typename value_type> accumulate_argument_tag<value_type> operator()(const value_type& value) { return accumulate_argument_tag<value_type>(value); } };static accumulate_tag accumulate; // Global pipe operator which takes one argumenttemplate <typename range_type, typename value_type>value_type operator|(const range_type& range, const accumulate_argument_tag<value_type>& argument_holder) { return std::accumulate(std::begin(range), std::end(range), argument_holder.value_); } // Global pipe operator which can accept 'accumulate' without any parenthesis// (assuming that std::accumulate can be used without arguments)template <typename range_type>typename range_type::value_type operator|(const range_type& range, const accumulate_tag&) { return std::accumulate(std::begin(range), std::end(range), range_type::value_type(0)); } // Usage std::vector<int> vec;for(size_t i = 0; i < 135; ++i) vec.push_back(i);auto a = accumulate(vec, 0);auto b = vec | accumulate(0);auto c = vec | accumulate; /Viktor

6 10

Borland and metrowerks compiler requirements?
by Stephen Kelly 27 Sep '13

27 Sep '13

Hello, In the work I've done so far on removing ifdefs for obsolete compilers, some compilers which have come up a few times are __BORLANDC__ and __MWERKS__. I have never used either of those compilers. Can old versions of either of them be dropped at this point in boost trunk? Thanks, Steve.

8 29

"Remove obsolete MSVC checks" and _MSC_VER
by Peter Dimov 26 Sep '13

26 Sep '13

One general note about these changes. This: #if defined( _MSC_VER ) && _MSC_VER >= 1310 doesn't mean "compiler is MS VC++ 7.1". It means "compiler claims to support MSVC 7.1's features." Many Windows compilers define _MSC_VER for compatibility. I'm not positive that the removal of the _MSC_VER >= part would break something nowadays, but if it does, this would be why. I'd have left these alone; it's not clear what purpose removing the check is intended to serve, apart from breaking code. Actual MSVC-specific code is guarded by BOOST_MSVC and not _MSC_VER.

3 11

[Container] Memory leak from allocation of 0 sized memory
by Evan Wallace 26 Sep '13

26 Sep '13

I recently tracked down a major memory leak in a system that I am working on to a bug in Boost.Container. The bug is that the following code leaks memory: #include <boost/container/vector.hpp> int main() { while (true) { boost::container::vector<int> vec; boost::container::vector<int> vec2(vec); } } I have submitted a ticket to trac, but since this is a major issue and the release date for 1.55.0 is very soon, I am also posting to the mailing list. https://svn.boost.org/trac/boost/ticket/9166 For reference: the leaked memory is allocated in allocator_version_traits::allocation_command Evan Wallace

2 1

mpl broken after removal of nttp.hpp in 85956
by Jürgen Hunold 26 Sep '13

26 Sep '13

Hi Stephen, the message is: home/hunold/src/devel/boost/boost/mpl/aux_/nttp_decl.hpp:17:42: fatal error: boost/mpl/aux_/config/nttp.hpp: No such file or directory It seems that even nttp_decl.hpp is obsolete, as is only contains: // Obsolete. Remove. # define BOOST_MPL_AUX_NTTP_DECL(T, x) T x /**/ Maybe incomplete quick patch attached. Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1