- Boost-users - lists.preview.boost.org

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

iostreams: streambuf class fails to compile on type check
by Dan Bloomquist 14 Mar '16

14 Mar '16

I'm trying to insert my own stream buffer into a boost stream. Here is the code <http://hostcode.sourceforge.net/view/5044> At the top are two arbitrary streambuf derived classes I copied from the web that are said to work with the std::stream. They don't work either. My work is in the rtf namespace. In main there is a test with my device, file_source, and std::ifstream derived, they all work. Then I've tried the likes of: rtf::basic_stream< char, char_array_buffer > io_4( input ); rtf::basic_stream< char, outbuf > io_4( input ); and the one I want to work: rtf::basic_stream< char, rtf::rtf_stream_buffer > io_4( input ); they all fail at: { BOOST_STATIC_ASSERT(is_std_io<T>::value); } line 66 in concept_adapter.hpp. All the classes are derived from std::basic_streambuf which is on the list #ifndef BOOST_IOSTREAMS_NO_STREAM_TEMPLATES And I could not find it defined with agent ransack So, I seem to be missing something fundamental and just don't know what it could be. Thanks. Dan.

2 2

errors in polymorphic_iarchive_route.hpp:155 (boost version 1.60)
by Stack User 14 Mar '16

14 Mar '16

I get the following error when compiling code that uses boost version 1.60: In function `boost::archive::detail::polymorphic_iarchive_route<boost::archive::naked_binary_iarchive>::load(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)': /usr/include/boost/archive/detail/polymorphic_iarchive_route.hpp:155: undefined reference to `boost::archive::basic_binary_iprimitive<boost::archive::naked_binary_iarchive, char, std::char_traits<char> >::load(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&)' Seems like the error is coming from polymorphic_iarchive_route.hpp at line 155: virtual void load(std::string & t){ ArchiveImplementation::load(t); } Can anybody point to a solution for this error? Thanks,

2 1

[Fit] formal review ends today, 13th March.
by Vicente J. Botet Escriba 13 Mar '16

13 Mar '16

Hi, The formal review of Paul Fultz II's Fit library ends today, 13th March. If you had not time to do the review and you plan to do it, please let us know so that we see if the review can be extended. Up to now we had 3 formal review (2 for conditional acceptance and 1 against, not now). I have not done a review myself, but I have created a lot of issues on Github. Best regards, 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 We await your feedback!

1 0

boost karma qi: skipper concept
by Matwey V. Kornilov 13 Mar '16

13 Mar '16

Hello, I don't fully understand skip parser concepts. I would like to parse key-value list in bash style, like the following: KEY1=VAL1 KEY2="V A L 2" The pairs are separated by one or more space symbols. What is the supposed way to parse such constructions? 1. -(pair % (+space)) 2. *pair with skip=space 3. anything else?

1 0

[INTERPROCESS] Message queues with hex names - in Windows
by Davies, John 11 Mar '16

11 Mar '16

I'm refactoring some code that has a pretty good suite of unit tests. Or at least I think it does, since I wrote them<g>. I have a process that dispatches messages to one or more other processes that have their own message queues. It's just a switchboard. The refactored code works, and runs much faster than the test code I had written before. Much faster. And passes the unit tests. But in the process I see a bunch of stuff in the boost-interprocess folder with long hex names. They get cleaned up when the tests are done. It seems the long hex names come when I'm destructing the queues. So is it part of garbage collection? It only concerns me because other times I saw names like that it was because I was trying to make two input queues with the same name. Thanks, John ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

2 1

Trouble building boost with Visual Studio 2010 (32 vs 64 bit issue)
by David Aldrich 09 Mar '16

09 Mar '16

Hi I am trying to build Boost 1.60 with Visual Studio 2010 Professional on Windows 10. I use the command: b2 toolset=msvc-10.0 --with-python link=shared and get the following error: python34.lib(python34.dll) : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' I guess this means I have a conflict of 32-bit and 64-bit libraries. I want to target 32-bit (X86). Do I need to install a 32-bit version of Python? I wonder if that can co-exist with the current version of Python? Best regards David

3 2

Boost python - pointers
by Daniel Burchardt 09 Mar '16

09 Mar '16

Hi, I have problem with pointer in function return. My code: using namespace boost::python; v8::Platform* InitializePlatform() { v8::Platform* platform = v8::platform::CreateDefaultPlatform(); return platform; } BOOST_PYTHON_MODULE(hello) { def("InitializePlatform", InitializePlatform, return_value_policy<manage_new_object>()); } Python code: import hello x = hello.InitializePlatform() Building is ok, but when i try call InitializePlatform i have error: Segmentation fault gdb: (gdb) run test.py Starting program: /usr/bin/python test.py [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7ffff45b8700 (LWP 21739)] Program received signal SIGSEGV, Segmentation fault. 0x00007ffff4924640 in __dynamic_cast () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6

1 0