- Boost-users - lists.boost.org

[Boost.Container] flat_set constructor with ordered_unique_range
by dariomt＠gmail.com 08 Apr '16

08 Apr '16

Hi list, If I use the flat_set constructor passing ordered_unique_range, does the library assert in debug mode that the passed data range is indeed ordered and unique? I don't seem to find such assert, but I think it would be very useful, to catch programmer errors. Regards

3 2

seekable input filter definition
by Cherotek Music 07 Apr '16

07 Apr '16

Hey, I'm new to boost and need a seekable input filter that will operate on bytes read from an ifstream. This is what I currently have: struct my_filter : boost::iostreams::seekable_filter{ template<typename Source> int get(Source& src) { int byte = boost::iostreams::get(src); if(byte != EOF && byte != boost::iostreams::WOULD_BLOCK) { // Do something with byte } return byte; } template<typename Sink> bool put(Sink&, char) { // No need to actually implement put because this filter is only used with ifstream return true; } template<typename T> std::streampos seek(T& t, boost::iostreams::stream_offset off, std::ios_base::seekdir way, std::ios_base::openmode which = std::ios_base::in | std::ios_base::out) { return boost::iostreams::seek(t, off, way, which); }}; It works but I would like to get rid of the useless put method. The boost documentation here http://www.boost.org/doc/libs/1_60_0/libs/iostreams/doc/concepts/filter.html says there is an InputSeekableFilter refinement of Filter but I can't seem to understand how to use it (there are no input_seekable_filter_tag or input_seekable_filter structs that I could use). Thanks

2 2

[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 03 Apr '16

03 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