March 2015 - Boost - lists.preview.boost.org

[log] [asio] Conflicting default configs
by Andrey Semashev 01 Apr '15

01 Apr '15

Hi, In Boost.Log I'm using Boost.ASIO to implement network-based syslog backend. Boost.ASIO is used in the compiled part of Boost.Log and, obviously, can be used in the user's code as well. By default Boost.ASIO is header-only, so we basically have a copy of Boost.ASIO in Boost.Log and another copy in the user's app. In Boost.Log I have the option to enable compiler-based TLS at the library build stage (BOOST_LOG_USE_COMPILER_TLS macro), which is by default not enabled. In Boost.ASIO there is a similar option (BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION macro) but the feature is enabled by default. I want Boost.Log built libraries to actually respect the BOOST_LOG_USE_COMPILER_TLS option, so I define BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION internally when BOOST_LOG_USE_COMPILER_TLS is not defined. The problem is that Boost.ASIO changes implementation in an incompatible way when BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION is defined. It is further worsened by a recent change that makes all of Boost.ASIO symbols externally visible. Basically, this means hard to debug trouble on user's end, when different versions of Boost.ASIO (one from Boost.Log binaries and the other used by the user's code directly) are used at the same time. I'd like to ask community what is the preferred resolution of this situation (and possibly similar ones in the future). I can see several ways of tackling this: 1. Introduce an inline ABI namespace in Boost.ASIO, much like the one I have in Boost.Log. The namespace name would depend on BOOST_ASIO_DISABLE_THREAD_KEYWORD_EXTENSION and other macros that affect binary compatibility. This would be my preferred solution, although I'm not sure how fast and easy it can be implemented. 2. Remove symbol visibility enforcement from Boost.ASIO, or at least make it optional. That way I could encapsulate my private copy of Boost.ASIO in Boost.Log binaries. 3. Change the defaults, either in Boost.Log or in Boost.ASIO, so that they are aligned by default. When the user changes Boost.Log config he would be expected to know that Boost.ASIO config also needs to be changed accordingly. If he doesn't, Boost.Log is still built consistently with its own config. Note, however, that since Boost.Log is a built library and in most distributions it is built with default options, the choice for Boost.Log is more significant and because of that should probably be more conservative. 4. Same as 3 but also remove the enforcement of Boost.ASIO config by Boost.Log. Whenever the user wants to change the default, he would have to define macros for the both libraries, otherwise Boost.Log can be built inconsistently. 5. Do not change the defaults but remove the config enforcement. BOOST_LOG_USE_COMPILER_TLS becomes Boost.Log-local and as such does not guarantee that the resulting binaries do not in fact use compiler-based TLS. Users can get surprised. 6. Do not change anything, let the users suffer because of ODR issues. Maybe document this somewhere... Opinions?

5 11

[serialization][release][teeks99] All MSVC tests for Boost.Serialization failing?
by Joaquín M Lopez Munoz 31 Mar '15

31 Mar '15

Hi All teeks99-* regression tests for Boost.Serialization in MSVC compilers appear as failing, yet when one clicks on any the information seems to indicate nothing went wrong: http://tinyurl.com/nf5bd9a Any clue? Thank you Joaquín M López Muñoz Telefónica

3 4

Transferring a library on Github
by Edward Diener 31 Mar '15

31 Mar '15

In order to get VMD under boostorg in order to begin the process of integrating the library into Boost for the release after the current pending one I tried to transfer the library as explained on the page https://svn.boost.org/trac/boost/wiki/NewLibFromGit. But I do not have the necessary admin rights for boostorg. How do I proceed ? I want to get VMD under boostorg and then do whatever is necessary to add it to the superproject and have it part of for regression testing.

2 4

[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