- Boost - lists.boost.org

[test]redefinition of boost::unit_test::ut_detail::auto_test_unit_registrar
by Takatoshi Kondo 14 Feb '17

14 Feb '17

Hello, I'm using Boost.Test. When I define BOOST_AUTO_TEST_SUITE, I got a compile error 'redefinition of boost::unit_test::ut_detail::auto_test_unit_registrar' if the all following conditions are satisfied: 1. The test suite names are the same. 2. BOOST_AUTO_TEST_SUITE are defined in different files. 3. The files are included by one file. 4. BOOST_AUTO_TEST_SUITE are defined at the same line number. For example, main.cpp #define BOOST_TEST_MODULE test #include <boost/test/unit_test.hpp> #include "one.ipp" #include "two.ipp" one.ipp BOOST_AUTO_TEST_SUITE(a) BOOST_AUTO_TEST_CASE(tc1) { } BOOST_AUTO_TEST_SUITE_END() two.ipp BOOST_AUTO_TEST_SUITE(a) BOOST_AUTO_TEST_CASE(tc2) { } BOOST_AUTO_TEST_SUITE_END() Here is a live demo: http://melpon.org/wandbox/permlink/R459VQ6apnQfapyw If I insert a line the top of two.ipp, no errors are occurred. http://melpon.org/wandbox/permlink/jPRTstNDVb7agjXl According to the following document http://www.boost.org/doc/libs/1_63_0/libs/test/doc/html/boost_test/tests_or… "The same test suite can be restarted multiple times inside the same test file or in a different test files." The compile error is caused by the following line: https://github.com/boostorg/test/blob/develop/include/boost/test/unit_test_… If I replace BOOST_JOIN( BOOST_JOIN( test_name, _registrar ), __LINE__ ) \ with BOOST_JOIN( BOOST_JOIN( test_name, _registrar ), __COUNTER__ ) \ , then the error is disappeared. However, __COUNTER__ is not portable. I know that I can compile one.ipp and two.ipp separately, but I also want to have the option that include them from one file. Is there any good way to solve the error? Thanks, Takatoshi Kondo

2 2

Lazy Spirit Generators?
by Christof Donat 14 Feb '17

14 Feb '17

Hi, In a hobby project, I am using Spirit Karma generators. As far as I have understood Spirit Karma, it is not designed to work lazily in the iterator based interface. It takes an output iterator and writes to it until it has finished. What I am thinking of is a kind of generating range. E.g.: for(auto& char: generator_range(double_ << " + " << double_ << "i", context, c.real(), c.imag())) { // do whatever with the single characters returned by the generator } Is there something like that, which I simply have not found? Christof

3 2

Fit - Request for formal review
by Paul Fultz II 13 Feb '17

13 Feb '17

Hi, So I’ve made a lot of updates to the Fit library since last review. There are a few more changes I would like to make, but most of the work has been done. So, I would like to request for a formal review, and get it on the schedule soon. Vicente Botet was the review manager last time, I don’t know if he would be interested in being the review manager again. Is there perhaps someone else that would be interested in being review manager? https://github.com/pfultz2/Fit Thanks, Paul

1 1

boost::aligned_storage is not a POD.
by Vicente J. Botet Escriba 11 Feb '17

11 Feb '17

Hi, boost::aligned_storage is not a POD. I suspect it is because of the declared constructors private: // noncopyable aligned_storage(const aligned_storage&); aligned_storage& operator=(const aligned_storage&); public: // structors aligned_storage() { } ~aligned_storage() { } Was this intentional? Why aligned_storage is not copyable? Best, Vicente

2 2

[exception] error: looser throw specifier
by Niklas Angare 11 Feb '17

11 Feb '17

On QNX 6.6.0 with GCC 4.7.3 and Dinkumware library in -std=gnu++0x mode, I get the following error: ../libs/exception/test/throw_exception_test.cpp:21:1: error: looser throw specifier for 'virtual exception2::~exception2()' In file included from ../libs/exception/test/helper2.hpp:9:0, from ../libs/exception/test/throw_exception_test.cpp:6: ../boost/exception/exception.hpp:303:5: error: overriding 'virtual boost::exception::~exception() throw ()' libs/exception/test/throw_exception_test.cpp has these definitions: struct exception1: std::exception {}; struct exception2: std::exception, boost::exception {}; There is no error for exception1. Is the bug in the Boost library, the test, the compiler or the Dinkumware library? Other regression runners with GCC 4.7 don't get the error. My regression test runner is NA-QNX660-x86 so you can see all details in the result matrix. Regards, Niklas Angare

1 0

Re: [boost] invalid access to stack memory?
by alexc 11 Feb '17

11 Feb '17

Original Message Sender:Bjorn Reese via Boostboost(a)lists.boost.org Recipient:boostboost@lists.boost.org Cc:Bjorn Reesebreese(a)mail1.stofanet.dk Date:Saturday, Feb 11, 2017 19:39 Subject:Re: [boost] invalid access to stack memory? On 02/11/2017 08:47 AM, alexc via Boost wrote: followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? From a quick look at the code, I do not think that it poses a problem. The idea, as I understand it, is to use RAII to push and pop a "stack frame" (call_stackT::context) onto a thread-local static "stack" (call_stackT::top_.) The context destructor will remove itself from the "stack". Oh, context class “recover” thecall_stackT::top_ indestructor, I miss this in the first place, thank you, Bjorn, it’s a very cool idea to me. _______________________________________________ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] invalid access to stack memory?
by Bjorn Reese 11 Feb '17

11 Feb '17

On 02/11/2017 08:47 AM, alexc via Boost wrote: > followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? From a quick look at the code, I do not think that it poses a problem. The idea, as I understand it, is to use RAII to push and pop a "stack frame" (call_stack<T>::context) onto a thread-local static "stack" (call_stack<T>::top_.) The context destructor will remove itself from the "stack".

1 0

invalid access to stack memory?
by alexc 11 Feb '17

11 Feb '17

Hi all, followed detail of the case, an object constructor store this pointer to a static variable. could it be a problem? detail/call_stack.hpp explicit context(Key* k) : key_(k), next_(call_stackKey, Value::top_) { value_ = reinterpret_castunsigned char*(this); call_stackKey, Value::top_ = this; // == store this to a static variable } detail/impl/strand_service.ipp void strand_service::do_complete(io_service_impl* owner, operation* base, const boost::system::error_code ec, std::size_t /*bytes_transferred*/) { if (owner) { strand_impl* impl = static_caststrand_impl*(base); // Indicate that this strand is executing on the current thread. call_stackstrand_impl::context ctx(impl); // == local variable ctx, its this pointer will be stroed in a static variable. Regards, Alex

1 0

Review Request : Boost.SIMD
by Joel FALCOU 10 Feb '17

10 Feb '17

Can Boost.SIMD please be added to the review queue? Michael Caisse has volunteered to act as the review manager. Boost.SIMD is an efficient modern C++ wrapper for SIMD instructiosn sets and computations that aims at providing a standard way to write code taking advantages of SIMD enabled hardwares. Boost.SIMD repository https://github.com/NumScale/boost.simd Documentation https://developer.numscale.com/boost.simd/documentation/develop/ Thanks in advance Joel Falcou - CTO @ NumScale

6 8

Testing DMARC spam binning
by Niall Douglas 10 Feb '17

10 Feb '17

Dear Boost, You all probably noticed that boost-dev now sends you emails from "Your Name via Boost <boost(a)lists.boost.org>" with your original email listed as CC. This should finally mean that DMARC protected email addresses are no longer flagged as Spam by many email services, including this email from me, as boost-dev is no longer sending email with a protected From: address. The list should be made aware that fixing this has taken nine months or so for good reason. A whole ton of work went into making this happen, not least relocating Boost's mailing list services from wowbagger where it had been for almost forever to new hosting partially donated to us for free. What wasn't obvious here was that there were problems of ownership transfer, arranging service donation and the change over and getting many, many long seized up cogs to turn, ones indeed I have failed to turn in many years of trying myself. The fact it all happened without service interruption is an amazing achievement. I'd like to ask the list to formally thank Michael Caisse and his team of many diligent workers who did all of this just to get mail posted here to not get flagged as Spam (there were other motivating factors too of course, but the Spam issue got the ball rolling). It was an awful lot of work for not a very obvious gain here on boost-dev. So thank you. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 1