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

Re: [Boost-users] [type traits] Using Boost.Geometry with Clang/LLVM & VC14
by degski 05 Apr '16

05 Apr '16

I've successfully compiled Boost 1.61.0 Beta 1 Release Candidate with VC14 (no Clang-Cl.exe) in debug and release. This has exposed the "hacks" I mentioned earlier in this thread. When compiling my test program with Clang-Cl (latest) and VC14, the following errors are reported. (in my hacks I just added std:: to the boost code in the appropriate places, untill Clang stopped complaining. 1>------ Rebuild All started: Project: test, Configuration: Debug x64 ------ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/geometry.hpp:17: 1> In file included from z:\vc\x64\include\boost/geometry/geometry.hpp:28: 1> In file included from z:\vc\x64\include\boost/geometry/core/coordinate_type.hpp:23: 1> In file included from z:\vc\x64\include\boost/geometry/util/promote_floating_point.hpp:19: 1> In file included from z:\vc\x64\include\boost/type_traits.hpp:62: 1>z:\vc\x64\include\boost/type_traits/has_nothrow_assign.hpp(64,7): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 1> BOOST_HAS_NOTHROW_ASSIGN(T) 1> ^ 1> z:\vc\x64\include\boost/type_traits/intrinsics.hpp(199,96) : note: expanded from macro 'BOOST_HAS_NOTHROW_ASSIGN' 1> # define BOOST_HAS_NOTHROW_ASSIGN(T) (__has_nothrow_assign(T) && !is_volatile<T>::value && is_assignable<T&, const T&>::value) 1> ^ 1> C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\type_traits(577,9) : note: 'std::is_assignable' declared here 1> struct is_assignable 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/geometry.hpp:17: 1> In file included from z:\vc\x64\include\boost/geometry/geometry.hpp:28: 1> In file included from z:\vc\x64\include\boost/geometry/core/coordinate_type.hpp:23: 1> In file included from z:\vc\x64\include\boost/geometry/util/promote_floating_point.hpp:19: 1> In file included from z:\vc\x64\include\boost/type_traits.hpp:63: 1>z:\vc\x64\include\boost/type_traits/has_nothrow_constructor.hpp(26,84): error : no template named 'is_default_constructible'; did you mean 'std::is_default_constructible'? 1> template <class T> struct has_nothrow_constructor : public integral_constant<bool, BOOST_HAS_NOTHROW_CONSTRUCTOR(T)>{}; 1> ^ 1> z:\vc\x64\include\boost/type_traits/intrinsics.hpp(193,80) : note: expanded from macro 'BOOST_HAS_NOTHROW_CONSTRUCTOR' 1> # define BOOST_HAS_NOTHROW_CONSTRUCTOR(T) (__has_nothrow_constructor(T) && is_default_constructible<T>::value) 1> ^ 1> C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\type_traits(539,9) : note: 'std::is_default_constructible' declared here 1> struct is_default_constructible 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/geometry.hpp:17: 1> In file included from z:\vc\x64\include\boost/geometry/geometry.hpp:28: 1> In file included from z:\vc\x64\include\boost/geometry/core/coordinate_type.hpp:23: 1> In file included from z:\vc\x64\include\boost/geometry/util/promote_floating_point.hpp:19: 1> In file included from z:\vc\x64\include\boost/type_traits.hpp:74: 1>z:\vc\x64\include\boost/type_traits/has_trivial_assign.hpp(28,7): error : no template named 'is_assignable'; did you mean 'std::is_assignable'? 1> BOOST_HAS_TRIVIAL_ASSIGN(T) 1> ^ 1> z:\vc\x64\include\boost/type_traits/intrinsics.hpp(187,96) : note: expanded from macro 'BOOST_HAS_TRIVIAL_ASSIGN' 1> # define BOOST_HAS_TRIVIAL_ASSIGN(T) (__has_trivial_assign(T) && !is_volatile<T>::value && is_assignable<T&, const T&>::value) 1> ^ 1> C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\type_traits(577,9) : note: 'std::is_assignable' declared here 1> struct is_assignable 1> ^ Then there are more errors, but they are either the same as the ones I've reported earlier, or the result of the above errors. Have a good day, degski

4 9

Boost.Fit review Mars 3-20 result
by Vicente J. Botet Escriba 03 Apr '16

03 Apr '16

Hi, I will be out for two weeks and I wanted to at least give the result of the Boost.Fit library review even if I would need more time to have a complete report. Summary ======= The review of the proposed Boost.Fit library ended on Mars 20, 2016. The verdict is: Conditional acceptance (a new review is needed) There were too much concerns about the documentation and what exactly this library is proposing and not enough reviews commenting the design, code and test for each one of the proposed functions. From the review discussion I deduce that there is some interest in the library, and that some people don't understand yet what the library is proposing. Paul has started already to take in account some if the issues raised during the review and a lot of them must be resolved before we re-try a new review. There were some discussion about the name of the library, but there were no consensus. Paul is free to change the name of his library and see how people react. On behalf of the Boost community, I would like to thank Paul Fultz for the work he has put into the Fit library so far. I encourage him to continue to evolve this library and to bring it back for a new review. We had seven 6 formal votes, and 2 more votes without a complete review abbreviated here: Steaven Watanabe: No in his current state Zach Laine : Conditinal acceptance Krzysztof Jusiak: Accepted Artyom Beilis : Rejected Peter Dimov : Accepted (no review) Manuel Sancher : Accepted (no review) Rob Stewart : Conditinal acceptance ??? Louis Dionne : Conditinal acceptance There were other people that participated on the review giving their advice respect to a specific issue. I thank each of these reviewers, and indeed everyone who invested some time participating in the discussions. If you feel that I have misrepresented your position, or have omitted or garbled an important point, please respond: the archived mail thread should accurately reflect the will of the community, even if this message does not. Detailed Report =============== You will need to wait yet for a month before I will be able to do it. On the mean time there are a lot of issues that must be addressed and that are part of the github issues. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Issues:https://github.com/pfultz2/Fit/issues Documentation:http://pfultz2.github.io/Fit/doc/html/ Hopping this helps, Vicente Botet Escriba

1 0

[Python] exec_file double delete
by Albert Yiamakis 03 Apr '16

03 Apr '16

Hello, Working with Boost 1.58, I am using Boost.Python to interpret python code. eval() and exec() are working as expected, however exec_file results on a double delete upon finishing reading the script. This can be observed in the following minimal: #include <boost/python.hpp> int main() { Py_Initialize(); boost::python::exec_file("foo.py"); } where foo.py contains a single line: print "hello" hello is printed on the screen - i.e. the script is completed before the crash. Valgrind also finds a number of invalid reads in the exec_file line before an invalid free/delete. Is there something I'm missing in exec_file usage, or do you think there might be a mismatch of dependencies? (using boost and python both from my package manager). Thank you, Albert

1 0

Re: [Boost-users] Weird code in lockfree::queue::reserve (compilation error)
by Bjorn Reese 02 Apr '16

02 Apr '16

On 04/02/2016 05:08 PM, Aurelien Regat-Barrel wrote: > I'm trying to use lockfree::queue, and I get a compiler error when calling reserve(). The following code does not compile with VC++ 2015: What error are you getting? Have you checked that the type T you use as the template argument to lockfree::queue<T> fulfills the documented requirements? > void reserve(size_type n) > { > pool.template reserve<true>(n); > } > > And indeed... what does this syntax mean: "pool.template reserve"? You can see it here: The use of the template keyword above is correct. It is used to help the C++ compiler resolve an otherwise ambiguous syntax. See the section "The template disambiguator for dependent names" at: http://en.cppreference.com/w/cpp/language/dependent_name

2 1

Weird code in lockfree::queue::reserve (compilation error)
by Aurelien Regat-Barrel 02 Apr '16

02 Apr '16

Hello, I'm trying to use lockfree::queue, and I get a compiler error when calling reserve(). The following code does not compile with VC++ 2015: void reserve(size_type n) { pool.template reserve<true>(n); } And indeed... what does this syntax mean: "pool.template reserve"? You can see it here: http://www.boost.org/doc/libs/1_60_0/boost/lockfree/queue.hpp Regards, Aurélien Regat-Barrel

1 0

Boost.Spirit's Greedy Fundamental Type Parsers
by Daniel Hofmann 01 Apr '16

01 Apr '16

Suppose I want to parse a list of ";"-separated floating point pairs with "," being the pair separator as in "1,2;3,4". Following this list comes a string literal representing a file extension, such as ".txt". Therefore what I want to successfully parse input like the following: 1,2;3,4.txt (For the record, the input could also be 1.1,2.2;3.3,4.4.txt) The parser I came up with is the 1:1 translation of above's description into the Spirit DSL and shows Spirit's expressive power: ((double_ % ",") % ";") >> ".txt" Unfortunately, the parser fails on the input with the integral values above. Why? Because the fundamental parser for double_ greedily matches on the "4." in "4.txt". Changing the "4" to "4.0" as in 1,2;3,4.0.txt parses successfully (but is not an option as it requires the user to always add a trailing ".0" in case the last digit is integral. I read about Spirit's DSL mapping to Parsing Expression Grammar (PEG) with the choice operator | being evaluated in order. So the next logical step for me was to try making use of it and adapting the parser: (((int_ | double_) % ",") % ";") >> ".txt" which works on 1,2;3,4.txt but no longer on 1,2;3,4.0.txt Is there a way to adapt the parser to handle both cases? I asked this on IRC and got the answer to try a solution based on ((double_ >> ".") | (int_ >> ".")) >> "txt" but when I use use this to parse "4.txt" into a std::vector<double> via parse(first, last, ((double_ >> ".") | (int_ >> ".")) >> "txt", into); the vector contains: {4, 4} and its size() is 2, which I can make no sense of at all (but this may be a different problem). Cheers, Daniel J H

3 4

Is there any ongoing work to support toolset Clang 3.7 with Microsoft CodeGen (v140_clang_3_7)
by forumer＠smartmobili.com 01 Apr '16

01 Apr '16

Hi, Microsoft has released a new toolset mixing clang for the code analysis part and VS2015 for the code generation. https://blogs.msdn.microsoft.com/vcblog/2015/12/04/clang-with-microsoft-cod… https://blogs.msdn.microsoft.com/vcblog/2016/01/20/clang-with-microsoft-cod… Is there any ongoing work to support this new compiler and properly support it ? Thanks

1 0

Re: [Boost-users] [boost] Boost 1.61.0 Beta 1
by Tom Kent 31 Mar '16

31 Mar '16

On Thu, Mar 31, 2016 at 3:05 AM, Vladimir Prus <vladimir.prus(a)gmail.com> wrote: > > The first beta packages for 1.61.0 beta 1 are now available: > <snip> > > It was discovered that the .zip and .7z archives actually have LF line > endings, > at least in some places. Fixing this is not quite trivial, as Travis uses > ancient version of Ubuntu and Git, and is not deemed critical, as most > Windows > editors handle LF just fine. We might do something for the final release, > or > might not. > I would vote for leaving it, I've always thought it would be preferable if all the releases were the same. I think notepad.exe is the only app that still has issues with line endings, though I'd be interested in hearing some history on why was different for the windows releases. Tom

1 0

Looping through variadic macro arguments
by Florian Lindner 31 Mar '16

31 Mar '16

Hello, I have this macro: #define vmacro(expr, ...) \ cout << "n macro = " << BOOST_PP_VARIADIC_SIZE(__VA_ARGS__) << endl; \ cout << BOOST_PP_VARIADIC_ELEM(0, __VA_ARGS__) << endl; \ cout << BOOST_PP_VARIADIC_ELEM(1, __VA_ARGS__) << endl; \ for (int i = 0; i < BOOST_PP_VARIADIC_SIZE(__VA_ARGS__); i++) { \ cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \ } The VARIADIC_SIZE is correct and I can access elements using BOOST_PP_VARIADIC_ELEM as long as I use a literal. The loop body produces error messages when compiling. BOOST_PP_VARIADICS is 1. The goal is to concatenate all variadic macro arguments to a string. If there a more clever solution, I'm very eager to hear them. Thanks! Florian ERROR MESSAGES: % clang++ -std=c++11 -g3 -rdynamic -ldl test.cpp test.cpp:154:3: error: expected expression vmacro(4, 5, 6); ^ test.cpp:120:26: note: expanded from macro 'vmacro' cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \ ^ /usr/include/boost/preprocessor/variadic/elem.hpp:26:101: note: expanded from macro 'BOOST_PP_VARIADIC_ELEM' # define BOOST_PP_VARIADIC_ELEM(n, ...) BOOST_PP_CAT(BOOST_PP_VARIADIC_ELEM_, n)(__VA_ARGS__,) ^ 1 error generated. g++ -std=c++11 -g3 -rdynamic -ldl test.cpp In file included from test.cpp:9:0: test.cpp: In function 'void f(int)': test.cpp:120:26: error: expected primary-expression before ')' token cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \ ^ test.cpp:154:3: note: in expansion of macro 'vmacro' vmacro(4, 5, 6); ^ test.cpp:120:26: error: 'BOOST_PP_VARIADIC_ELEM_i' was not declared in this scope cout << i << ": " << BOOST_PP_VARIADIC_ELEM(i, __VA_ARGS__) << endl; \ ^ test.cpp:154:3: note: in expansion of macro 'vmacro' vmacro(4, 5, 6); ^

2 16

Boost 1.61.0 Beta 1 Release Candidate 2
by Vladimir Prus 31 Mar '16

31 Mar '16

Second set of release candidates for 1.61.0 beta 1 are now available: http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.zip http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.tar.bz2 http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.tar.gz http://boost.cowic.de/rc/boost_1_61_0_b1_rc2.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. The changes from RC1 are: * Top-level directory in the archive matches the name * Zip and 7z archives use CRLF line endings The known issues are: * Documentation build has some wrong-location, extra-files and broken-links issues. * There was a report of Boost.Context issue on OSX Release managers believe these issues are not blocking beta 1. The SHA1 checksums are as follows: 4d3c83d3a802d3dd12d4f2d516b3fcf076f6f6ba boost_1_61_0_b1_rc2.7z 8c6ac7326a3cabcabf6c7876052b73e0d41fc36d boost_1_61_0_b1_rc2.tar.bz2 e82b8ff7c3ad5b08c7dbeac1ea85fcf707a1cd4d boost_1_61_0_b1_rc2.tar.gz 7292e8fdac0566fe098a60a197a5722d381842d3 boost_1_61_0_b1_rc2.zip The SHA256 checksums are as follows: bc8341bfb8c6621319ad9eb732179fc7ec4da35c3cefc31b613f83ec3df10361 boost_1_61_0_b1_rc2.7z c0f06c78c195af9079773a2b250674244f1899ec81e84d5455f0761f1d888a16 boost_1_61_0_b1_rc2.tar.bz2 400fa0949aa201d993bf116461365e5d44904a3f8db6412f4f40f2b4ab490405 boost_1_61_0_b1_rc2.tar.gz d75688ecad601303dda2658e9a3d06f406dd4dc8e2c13c36bdadcac0a11dcffa boost_1_61_0_b1_rc2.zip Thanks! -- The release managers

2 2