- Boost-users - lists.boost.org

[Fit] formal review is over
by Vicente J. Botet Escriba 21 Mar '16

21 Mar '16

Hi, The review of the Fit library finished yesterday 20 March. Thanks to all the people who participated in the review, as a reviewer or commenting the threads. I hope to announce the result soon ;-) Best, Vicente P.S. Of course you/we can continue with the discussion and add issues in github that would help to improve the library. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/

1 0

Re: [Boost-users] [boost] Boost 1.61.0 Beta 1 Release Candidate 1
by Marshall Clow 20 Mar '16

20 Mar '16

On Sat, Mar 19, 2016 at 12:38 PM, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: > > Release candidates for 1.61.0 beta 1 are now available: > > http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.zip > http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.bz2 > http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.tar.gz > http://boost.cowic.de/rc/boost_1_61_0_b1_rc1.7z > > As always, the release managers would appreciate it if you download > the candidate of your choice and give building it a try. Please report > both success and failure, and anything else that is noteworthy. > Packaging: The .gz file expanded to "boost_master_3a94cde635254f92fa87e0e11ef52d08684b8225", instead of "boost_1_61_0_b1" I successfully built the libraries with Apple's clang compiler. "Apple LLVM version 7.0.2 (clang-700.1.81)" with C++03, C++11, C++14, and c++1z I was not successful building the libraries with clang ToT. Boost.Python, in particular, had compile errors. I don't know if this is a problem in Boost.Python, or in libc++. (probably libc++) I will continue to investigate. In any case, I don't think that this should hold up the beta release. -- Marshall

3 3

[Fit] formal review ends 20th March.
by Vicente J. Botet Escriba 19 Mar '16

19 Mar '16

Hi, There have been some that would be able to write a review next week-end. Others said that they had not enough time. Maybe having an additional week can help. I have not received confirmation from the review withards, but as there is no planned reviews for this week, I propose to continue with the review until 20th. Please take the time to do a review and share your point of view. Best, Vicente Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here:http://www.boost.org/community/reviews.html

1 1

Boost graph library: brandes_betweenness_centrality() usage
by Sebastian Rinke 18 Mar '16

18 Mar '16

Dear all, I have a question regarding how to use the BGL brandes_betweenness_centrality() function for calculating the vertex betweenness centrality for a directed weighted graph. Below is my small example that fails to compile: —8>— /* Create graph */ typedef property<edge_weight_t, double> EdgeWeightProperty; typedef adjacency_list< vecS, // OutEdgeList vecS, // VertexList directedS, // Directed no_property, // VertexProperties EdgeWeightProperty // EdgeProperties > Graph; Graph graph(num_vertices); /* Add edges … */ std::vector<double> v_centrality_vec(num_vertices(graph), 0.0); // Create the external vertex centrality property map iterator_property_map<std::vector<double>::iterator, identity_property_map> v_centrality_map(v_centrality_vec.begin()); brandes_betweenness_centrality(graph, v_centrality_map, weight_map(get(edge_weight, graph))); —8>— The first compilation error I get is: boost_1_58_0/boost/graph/betweenness_centrality.hpp:248:7: error: no type named 'value_type' in 'struct boost::property_traits<boost::bgl_named_params<boost::adj_list_edge_property_map<boost::directed_tag, double, double&, long unsigned int, boost::property<boost::edge_weight_t, double>, boost::edge_weight_t>, boost::edge_weight_t, boost::no_property> >' centrality_type; ^ When using the following call instead, it compiles: brandes_betweenness_centrality(graph, v_centrality_map); I would be very grateful for any help on this issue. Best regards, Sebastian

1 0

Way to Promise the io_service.run() Is Running
by Bo Zhou 16 Mar '16

16 Mar '16

Hi ! I have a program which has a following logic 1. Start the UDP listening in daemon thread 2. Send the UDP command from main thread, and wait the response, maybe from the local So the program itself might also receive the message from second step. But the problem is, on Windows, the receiving thread will be executed before the main thread starts to send message, so the behaviour is correct. On Linux that's opposite, the main thread will be in deadlock because the 1st thread is not running and 2nd step it's trying to receive something after sending the command. My question, in the main thread of my application, what could I do to detect the io_service is running ? I tried to call m_io_services.stopped() seems the state is not correct, so I'd like to know how can I wait until the event loop in 1st step is running ? Thank you very much !

2 1

[Fit] About supported C++ version
by Vicente J. Botet Escriba 16 Mar '16

16 Mar '16

Hi, I was wondering if Boost.Fit shouldn't be a library as Boost.Hana, a library that makes use of the last C++ version and avoids as much portability issues as possible. Which C++14 features will make the library simpler? Which adopted C++17 features will make the library simpler? Which other C++ features would be missing? Paul I guess that you are using a C++11 compiler and want to support this version, could you confirm? Best, Vicente

2 3

boost-mpi - Serious performance degradation with OpenMPI 1.10.1
by Nolen, Steven Douglas 16 Mar '16

16 Mar '16

My project has been using boost's mpi interface for a number of years and have recently encountered a significant performance obstacle moving to openmpi 1.10.1. We are seeing a factor of 7-10x slowdown in the communication portion of our calculation. Our communication patterns are mostly governed by all-to-one reductions and some all-to-all reductions. Colleagues who call mpi directly have not seen this behavior. We would be willing to work with someone to find a solution. Steve Nolen LANL

3 3

Using Boost.Geometry with Clang/LLVM & VC14
by degski 16 Mar '16

16 Mar '16

GGL does not compile with the combo of Clang/LLVM (http://llvm.org/builds/) and VC14 out of the box. There seem to be comflicts in the resolution of old MSVC bugs and Clang. On windows __clang__ is defined at the same time as _MSVC_VER. Undefining the macro _MSVC_VER before #include <boost/geometry/geometry.hpp> does however solve the problem (in my use case): file: boost/geometry.hpp // Boost.Geometry (aka GGL, Generic Geometry Library) // Copyright (c) 2007-2011 Barend Gehrels, Amsterdam, the Netherlands. // Copyright (c) 2008-2011 Bruno Lalande, Paris, France. // Copyright (c) 2009-2011 Mateusz Loskot, London, UK. // Parts of Boost.Geometry are redesigned from Geodan's Geographic Library // (geolib/GGL), copyright (c) 1995-2010 Geodan, Amsterdam, the Netherlands. // Use, modification and distribution is subject to the Boost Software License, // Version 1.0. (See accompanying file LICENSE_1_0.txt or copy at // http://www.boost.org/LICENSE_1_0.txt) #ifndef BOOST_GEOMETRY_HPP #define BOOST_GEOMETRY_HPP #if defined(__clang__) && defined(_MSC_VER) #define __BOOST_GEOMETRY_MSVC_CLANG_WORKAROUND__ _MSC_VER #undef _MSC_VER #endif #include <boost/geometry/geometry.hpp> #if defined(__clang__) && defined(__BOOST_GEOMETRY_MSVC_CLANG_WORKAROUND__) #define _MSC_VER __BOOST_GEOMETRY_MSVC_CLANG_WORKAROUND__ #undef __BOOST_GEOMETRY_MSVC_CLANG_WORKAROUND__ #endif #endif // BOOST_GEOMETRY_HPP I've run into similar problems before (cannot remember where) with other boost libraries (which I hacked in other ways). Clang/LLVM with MSVC (and the IDE) works extremely well for a while now. The advantages of Clang/LLVM are well known, no need to spell them out It produces far faster code (almost twice as fast on simple matrix multiplication f.e.. It also gives the best of two worlds as it supports Clang and GCC extensions on Windows (calculated goto), while maintaining (although with a suppressable warning) M$ extensions as well, f.e. in-class template specialization. Clang/LLVM (3.9.0 as it stands) is much faster than Clang/CL2 (CodeGen) (3.7.0). I would herewith like to request the development team to integrate Clang/LLVM on Windows as another supported platform. Have good day to you all, degski -- (\___/) (+'.'+) (")_(") This is Bunny. Copy and paste Bunny into your signature to help him gain world domination!

3 5

Warning message using Boost.Atomic char pointer with GCC 4.8
by Isaac To 16 Mar '16

16 Mar '16

Hi all, It looks like Boost.Atomic (in Boost 1.60) uses constructs that GCC 4.8 (in CentOS 7) really dislike. With the following simple test program... #include <boost/atomic.hpp> int main() { boost::atomic<const char*> p1("abc"), p2; p2 = p1.load(); } What I see is: $ g++ -std=c++11 -I ~/opt/1/include t.cpp In file included from /home/foo/opt/1/include/boost/atomic/detail/atomic_template.hpp:25:0, from /home/foo/opt/1/include/boost/atomic/atomic.hpp:22, from /home/foo/opt/1/include/boost/atomic.hpp:12, from t.cpp:1: /home/foo/opt/1/include/boost/atomic/detail/bitwise_cast.hpp: In instantiation of ‘To boost::atomics::detail::bitwise_cast(const From&) [with To = long unsigned int; From = const char*]’: /home/foo/opt/1/include/boost/atomic/detail/atomic_template.hpp:426:139: required from ‘boost::atomics::detail::base_atomic<T*, void*>::base_atomic(T* const&) [with T = const char; boost::atomics::detail::base_atomic<T*, void*>::value_type = const char*]’ /home/foo/opt/1/include/boost/atomic/detail/atomic_template.hpp:686:101: required from ‘constexpr boost::atomics::atomic<T>::atomic(boost::atomics::atomic<T>::value_arg_type) [with T = const char*; boost::atomics::atomic<T>::value_arg_type = const char*]’ t.cpp:4:40: required from here /home/foo/opt/1/include/boost/atomic/detail/bitwise_cast.hpp:45:5: warning: casting ‘const char* const’ to ‘const char&’ does not dereference pointer [enabled by default] ); ^ The offending code is boost/atomic/detail/bitwise_cast.hpp:45, looking like this: &reinterpret_cast< const char& >(from) Here "from" is of type From = const char*. The code needs to find the address storing the pointer. It reinterprets the pointer as a const char reference, where address is to be found. In actual production code I use -Werror, so this stops the compiler from producing an executable. Most other warnings caused by Boost can be opted out, but apparently not this particular one. Should this be considered too funny a use of the C++ language to be considered a bug? For now I change the const char* to const void* with extra reinterpret_cast's, which the compiler won't complain about. Regards, Isaac

1 0

[Fit] function object variables and ADL
by Vicente J. Botet Escriba 14 Mar '16

14 Mar '16

Hi, Fit library make use of constexpr function object. These function objects don't work well when the user is requiring ADL and the same symbol is used. Next follows an example namespace N1 { struct F1 { void operator()(int) const {} }; constexpr F1 f; } namespace N2 { struct A{}; void f(A) {} } namespace N3 { struct A{}; void f(A) {} } The following find N3::f(A) { N3::A a; f(a); // calls N3::f(A) } Adding another namespace that doesn't introduce a better match works yet { N3::A a; using namespace N2; f(a); // calls N3::f(A) } However a namespace that contains a function object with the smae name even if overload doesn't match make the code ill-formed { N3::A a; using namespace N1; f(a); // compile fails } : error: reference to 'f' is ambiguous f(a); ^ : note: candidate found by name lookup is 'N1::f' constexpr F1 f; ^ : note: candidate found by name lookup is 'N3::f' void f(A) {} boost::fit contains a lot of such a function objects variables, so this means that the user should be careful while introducing the namespace boost::fit, as ADL will not be used for a lot of symbols. This is not something specific to Fit library, Hana and range-v3 make use of a lot of such global function objects. A good stryle will be to use Fit/Hana function objects always qualified with their respective namespapce or an alias. I believe it will be worth adding something in the documentation preventing the users of this case. Best, Vicente

1 0