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

[asio] Error code by io_service.run(ec) not the same as in async_read_handler
by Michael Weise 06 Apr '16

06 Apr '16

Hello, my question is about the error code returned by io_service.run_one. I expect the error code returned by run_one to be the same as the one in the handler - but they are not. Inside my handler I check the error code, which is equal to operation aborted: void ConnectionBase::ReadUntilHandler( const boost::system::error_code & ec, std::size_t bytes_transferred) { // ec == boost::asio::error::operation_aborted ... } At some other point I call io_service.run_one, which calls the above handler: ... m_asioService.run_one(ec); assert(ec == boost::asio::error::operation_aborted); ... The assertion fails - for some reason the error code is not the same as in the handler. What's the reason for this? Maybe my assumtion that run_one(ec) returns the error code of the handler is simply wrong? If so, what error does io_service.run(ec) actually report? Thanks for help, Michael PS: boost::asio version is 1.56.0

2 1

Using Boost.ASIO with Boost.Coroutine2
by Carlos Ferreira 06 Apr '16

06 Apr '16

Hello to all! Is it possible to use Boost.ASIO with Boost.Coroutine2? For what I understood upon reading the documentation, using Boost.Corouine2 is preferable, due to issues present in Coroutine that were solved in Coroutine2. The documentation is scarse and I'm having some trouble in making things work. Thank you! -- Carlos Miguel Ferreira Researcher at Telecommunications Institute Aveiro - Portugal Work E-mail - cmf(a)av.it.pt Skype & GTalk -> carlosmf.pt(a)gmail.com LinkedIn -> http://www.linkedin.com/in/carlosmferreira

1 0

[Q] piecewise_construct for boost::container::map::emplace()
by dave m. 05 Apr '16

05 Apr '16

I recently tried (but failed) to use boost::container::map::emplace() with the piecewise_construct tag to forward constructor args as tuples. After some fiddling around, it appears that piecewise_construct is not implemented for boost::container::detail::pair (see boost/container/detail/pair.hpp:151). I couldn't find any discussion in the mailing list archives. Is there a good reason not to use emplace() this way, or unreasonable difficulty in implementing piecewise_construct for pair<U,V>? (I ended up making constructors for my K, V elements that take tuples<>, so emplace() is working for me, but I'm not completely sure that I have avoided all possible copy/move operations. Using gcc-4.9.2, fwiw.) Thanks, dhm

1 0

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