- Boost - lists.boost.org

[detail] Bug in is_postfix_incrementable
by Edward Diener 31 Mar '15

31 Mar '15

There is a rather bad bug in is_postfix_incrementable in the detail/is_incrementable.hpp header file. I noticed this when I was looking at how I can remove the dependncies in is_incrementable.hpp on the deprecated Type_traits header files in Version2 of type_traits. The bug looks totally obvious to me. It's that the is_postfix_incrementable metafunction is derived from the is_incrementable_::impl<T> implementation rather than the is_incrementable_::postfix_impl<T> implementation. I am sure this was just a copy-paste problem but evidently has been in the header file from the beginning. Can we fast forward the simple fix to the new release ? I posted this just to be sure I haven't missed anything in the file. I believe that only the iterator library currently uses the is_incrementable and is_postfix_incrementable metafunctions in its tests. Since it is Boost detail no end-user should be using it. Still we should have it correct, shouldn't we, in our release ?

1 0

Conflicts when building libraries at root
by Peter Dimov 31 Mar '15

31 Mar '15

On Windows, at least, when I do ./b2 toolset=msvc-8.0 at Boost root, I get error: Name clash for '<pstage\lib>libboost_system-vc80-mt-gd-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <warnings>all error: - <address-model>32 <architecture>x86 <warnings>on When I add --without-context --without-coroutine, I now get error: Name clash for '<pstage\lib>libboost_system-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>off error: - <asynch-exceptions>on So I add --without-test. error: Name clash for '<pstage\lib>libboost_timer-vc80-mt-1_58.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <asynch-exceptions>on <library>object(file-target)@10959 error: - <asynch-exceptions>off <library>object(file-target)@9953 Now where did _that_ come from. :-) Ah. --without-endian. Builds now. This is perhaps old news for some, but it looks like it doesn't play well with our simple build instructions. Or maybe it doesn't occur on the master branch, so we don't care? I haven't checked yet. It's also perhaps an indication of a deeper problem. I can use b2 --with-test and have 'test' built; it builds its dependencies (system, chrono and timer) with <asynch-exceptions>on in bin.v2, and if I use it from within Boost.Build, it will link to them. But if I stage (or install) Boost.Test, and then stage or install Boost.System separately, Boost.System will be built with <asynch-exceptions>off. So the library user who just has headers and binaries will link those, potentially creating a conflict, which may in this case be benign. Or not.

12 55

[Container] const boost::container::vector is mutable??
by Eric Niebler 31 Mar '15

31 Mar '15

Why are the elements of a const boost::vector mutable through its const_iterator? #include <boost/container/vector.hpp> int main() { using C = boost::container::vector<int>; C c{1,2,3,4}; C const & r = c; r[0] = 42; // Error, good. *r.begin() = 42; // Compiles! huh?? } -- Eric Niebler Boost.org http://www.boost.org

2 3

how to contact iterator developers
by Claas H. Koehler 31 Mar '15

31 Mar '15

Hi! About a week ago I sent a question about a specific bug to the iterator developers via this list and haven't received any feedback yet. Is this list not the right place to ask such questions or are there currently no active iterator developers managing the project ? Regards Claas

3 3

Release deadlines
by Marshall Clow 30 Mar '15

30 Mar '15

Just a reminder that we’re coming up on a release; and if you have changes that you want to see in the release (I know *I* do), you should get them in ASAP. Check them into develop, and then, once the tests have cycled successfully, merge them to master. Please do not merge anything to master w/o permission from the release managers after the start of April (11:59 PM next Tuesday PDT). Also, if you know of problems with the current state of the master branch that would preclude releasing it, please let us know (preferably *before* next Wednesday). Thanks for your help with the releases. — Marshall & the rest of the release managers.

7 9

[serialization] Passing literals to oarchive
by Bjorn Reese 30 Mar '15

30 Mar '15

Currently we cannot pass literals directly to an oarchive like this: oarchive << 42; since compilation fails in interface_oarchive.hpp, as the operator<< only takes parameters by reference. We can remedy this by changing operator<< to take the parameter by const-ref instead, as show below. Is there any reason not to do this? --- a/include/boost/archive/detail/interface_oarchive.hpp +++ b/include/boost/archive/detail/interface_oarchive.hpp @@ -59,7 +59,7 @@ public: } template<class T> - Archive & operator<<(T & t){ + Archive & operator<<(const T & t){ this->This()->save_override(t, 0); return * this->This(); }

3 9

[mpl] Is BOOST_MPL_PP_TOKEN_EQUAL publicly usable ?
by Damien Buhl 30 Mar '15

30 Mar '15

Dear Boost.MPL developers, I was coming up to something really similar to BOOST_MPL_PP_TOKEN_EQUAL ( http://www.boost.org/doc/libs/1_57_0/boost/mpl/aux_/preprocessor/token_equa… ) in Boost.Fusion to fix warnings that my changes generate in MSVC 8 ( As discussed on this list as *[boost] MSVC warnings for BOOST_PP_IS_EMPTY in Boost.Phoenix* ) Instead of having a second implementation of the same macro within Boost.Fusion, is it ok if I use BOOST_MPL_PP_TOKEN_EQUAL from MPL ? I'm asking this because it isn't documented anywhere and is in mpl/include/boost/mpl/aux_/preprocessor/token_equal.hpp which sounds like a private header. Possibly there are reasons for not being documented ? Cheers, -- Damien Buhl

2 2

Re: [boost] [Locale] Boost.Locale cannot Run in Visual Studio 2010
by Artyom Beilis 30 Mar '15

30 Mar '15

> >I have been trying to learn Boost.Locale Module. Consider this >http://www.boost.org/doc/libs/1_55_0/libs/locale/doc/html/conversions_8cpp-… >example. The code gets successfully compiled but when I try to run it, it >gives the error > >Unhandled exception at 0x74d34b32 in LearningCPP.exe: Microsoft C++ >exception: std::bad_cast at memory location 0x00a6fa48.. > >I have attached the stack-trace of the program also. Here it is: > > [snip] > > Did anyone faced this issue when using Boost.Locale in Visual Studio 2010? > If so, how do I resolve this issue? 1. Do you use latest version of MSVC or public beta (there was facet related bug there)2. Make sure you don't mix debug and release code (which can be very likely stuff there) on both boost and its dependencies (icu if you use one) Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.com/ CppDB - C++ SQL Connectivity: http://cppcms.com/sql/cppdb/

2 1

[GSOC] Request for proposal review and feedback
by Divyansh Gupta 30 Mar '15

30 Mar '15

Hi BOOST, I had submitted my proposal for the enhanced vector and deque project on 17th March, but I haven't received any comments yet. It would be great if I could get some feedback on the proposal, so that I can make any necessary changes while that's allowed. Thanks a lot. Regards, Divyansh Gupta PS- Here's the link to the proposal: https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2015…

1 0

[thread] Alternate future implementation and future islands.
by Giovanni Piero Deretta 29 Mar '15

29 Mar '15

[cc'ing a few of the participants of the old thread] Hi All, Back in January, there was an interesting long thread about the problem of interoperation between futures of different libraries and the ability wait for heterogeneous futures. Different solutions were discussed like standardizing the future shared state or having an unified kernel wait object. I just wanted to share my attempt on a solution on the problem. The code can be found at https://github.com/gpderetta/libtask/blob/master/future.hpp (other interesting files are shared_future.hpp event.hpp and tests/future_test.cpp). It is an implementation a subset of the current boost and std future interface. In particular it has promise, future, shared_future, future::then, wait_any, wait_all. Most important missing piece are timed waits (for lack of, ahem, time, but should be easy to implement). The implementation requires c++14 and is only lightly tested, it should be treated as a proof of concept, not production-ready code. A few key design points: * The wait strategy is not part of the future implementation (although a default is provided). future::get, future::wait, wait_all and wait_any are parametrized by the wait strategy. * The design aims to streamline and make as fast as possible future and promise at the cost of a slower shared_future (although there is room for improvement). * The wait strategy only deals with 'event' objects, which act as a bridge between the future and the promise. The event object is really my the core of my contribution; it can be thought of as the essence of future<void>::then; alternatively it can be seen as a pure user space synchronization primitive. Other features of this implementation: * Other than in the blocking strategy itself, the future and promise implementation have no sources of blocking (no mutexes, not even spin locks). * The shared state is not reference counted. To demonstrate the generality of the waiting concept, I have implemented a few waiter objects. * cv_waiter: this is simply a waiter on top of an std::mutex + cond var. * futex_waiter (linux): an atomic counter + a futex, possibly more efficient than the cv_waiter * sem_waiter (posix): a waiter implemented on top of a posix semaphore. More portable than the futex waiter and possibly more efficient than the cv_waiter * fd_waiter(linux, possibly posix): a waiter implemented on top of linux eventfd (for portability it can also be implemented on top of a pipe); you can use select with futures! * task_waiter: a completely userspace based coroutine waiter which switches to another coroutine on wait and resumes the original coroutine on signal. * scheduler_waiter: another coroutine based waiter, but on top of an userspace task scheduler. On wait switch to the next ready task, on signal enqueue the waiting task to the back of the ready queue. I know that there is a plan to reimplement a new version of boost::threads, hopefully this implementation can contribute a few ideas. HTH, -- gpd

4 18