- Boost - lists.boost.org

Schedule update request
by Antony Polukhin 06 Sep '18

06 Sep '18

Schedule at https://www.boost.org/development/index.html does not show next release dates and close of merge window. Please update it. Thanks in advance!

1 0

Assistance debugging compile time isomorphism failure to get PR #114 working
by Joshua Marshall 05 Sep '18

05 Sep '18

Hello all, Since Saturday I've been banging my head against this one. Over at https://github.com/anadon/graph/tree/isomorph-fix I've been trying to fix some of the newly enables travisCI failures. I'm getting a persistent type mismatch that may not be resolvable sanely, but I want to get another set of eyes before I just the gun and start suggesting ripping out tests.

1 0

Deprecation of detail endian macros.
by Rene Rivera 03 Sep '18

03 Sep '18

This is a general announcement that I'm deprecating the following that is part of Predef: Header: boost/detail/endian.hpp Macros: BOOST_BIG_ENDIAN, BOOST_LITTLE_ENDIAN, BOOST_PDP_ENDIAN, and BOOST_BYTE_ORDER You can use the equivalents from Predef < https://www.boost.org/doc/libs/1_68_0/doc/html/predef/reference.html#predef…> as follow: BOOST_BIG_ENDIAN == BOOST_ENDIAN_BIG_BYTE BOOST_LITTLE_ENDIAN == BOOST_ENDIAN_LITTLE_BYTE BOOST_PDP_ENDIAN == BOOST_ENDIAN_LITTLE_WORD There is no equivalent for BOOST_BYTE_ORDER. But there are no uses in Boost as far as I could tell. In the develop branch of Predef I've added a deprecation message indicating as such. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

pending vs detail headers
by James E. King III 03 Sep '18

03 Sep '18

Is there any general guidance for moving headers out of boost/pending? Do we really need to include a forwarding stub for these? I'd like to consider headers in boost/pending as "not final" and therefore we should be able to move headers out of there without leaving a forwarding stub. Example: https://github.com/boostorg/dynamic_bitset/pull/24 - Jim

5 4

No Viable function warning
by randydom 03 Sep '18

03 Sep '18

Hello i've the bellow function : __declspec(dllexport) int TrySendData(_isocket * isocket,char * ibuff,int ilen) { boost::system::error_code ignored_error; boost::asio::write(isocket->socket(), boost::asio::buffer(ibuff,ilen), boost::asio::transfer_all(), ignored_error); if(ignored_error) return 0; return 1; } I get a *No Viable function* warning , can someone tells me why or helps me in fixing this warning . Thank you . -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Original STL Library Documentation has been recovered and is now safe forever.
by Robert Ramey 02 Sep '18

02 Sep '18

The Standard Template Library is the foundation of modern C++. The creation and publication of this code and its documentation set a new standard for the formal specification of what a computer program should do, how it should be designed and how it should be formally documented. These pages were maintained first by Silicon Graphics and then later by Hewett-Packard. In January of 2018 these pages were removed by H-P. This is a historic blunder. I have recovered the original STL Library Document and hosted them here: http://www.rrsd.com/software_development/stl/index.htm Robert Ramey

8 10

[vcpkg] Support non-Windows build. #4169
by degski 02 Sep '18

02 Sep '18

FYI: https://github.com/Microsoft/vcpkg/pull/4169#issuecomment-417867673 degki -- *“If something cannot go on forever, it will stop" - Herbert Stein* *“No, it isn’t truth. Truth isn’t truth" - Rudolph W. L. Giuliani*

1 0

[integer] CMT assume responsibility for Boost.Integer?
by James E. King III 01 Sep '18

01 Sep '18

The maintainer of Boost.Integer has no commits since 2008, and I was unable to get a hold of him by email (waited 10 days for a reply). I suggest we transfer responsibility of this repository to the CMT. - Jim

3 3

Gsoc 2019
by Shubham Verma 01 Sep '18

01 Sep '18

Hey I'm new, but I'd like to contribute to your organisation, can someone please guide me along?

5 4

Let's stop distributing binaries
by Robert Ramey 31 Aug '18

31 Aug '18

The fact is that users of boost use compilers with differing levels of C++ standard conformance. This creates a number of problems including (but probably not limited to) a) Using libraries built with different levels of C++ conformance may create ABI issues. b) it creates a discussion about "dropping C++03 support". Actually it creates a discussion about that the above actually means. c) It's motivated a suggestion that all libraries move to header only. This is not great idea - but I won't address that here. I believe all these issues - and more - would disappear if we just stopped distributing binaries. Each user would be building his own boost version with (presumably) the same compiler. Since C++03 compatible libraries are C++?? compatible, each library author can maintain the level of backward compatibility that he wishes. But if we're not going to distribute binaries, then users might as well just clone the latest "certified - good - tagged" version in the master branch from the github repo. That is, let's just stop or truncate the whole release circus. Replace with an occasional "certification/versioning procedure" which would make available a "squashed" master suitable for efficient cloning. This would make everyone's life easier. Robert Ramey

19 63