August 2018 - Boost - lists.boost.org

Re: [boost] A possible date for dropping c++03 support
by Glen Fernandes 28 Aug '18

28 Aug '18

Peter Dimov wrote: > Edward Diener wrote: > > Peter Dimov wrote: > > > If I post "Boost is dropping support for C++03" f.ex. on Twitter or > > > Reddit, every single user will immediately understand what that means. > > > :-) > > > > I am not a participant of either so some of your humor is lost on me, but > > I can guess that it suggests that you do not consider the intelligence of > > the average Twitter or Reddit participant to be very high. > > No, that's not at all what I meant. I meant what I said. Users will > immediately understand "Boost is dropping support for C++03". I doubt hat. After the "Boost is moving to CMake" announcement on Reddit, I have a different interpretation of what Reddit will understand from "Boost <anything>". We should do things first, then announce that we've done them. Glen

2 1

1.68 Getting Started links to 1.67
by Olaf van der Spek 28 Aug '18

28 Aug '18

Hi, > The most reliable way to get a copy of Boost is to download boost_1_67_0.7z or boost_1_67_0.zip and unpack it to install a complete Boost distribution.1 1.67? Actually the best way is to use vcpkg if possible (IMO). https://www.boost.org/doc/libs/1_68_0/more/getting_started/windows.html -- Olaf

6 18

Add an adapter to cover fast bit functions
by Evgeny Shulgin 28 Aug '18

28 Aug '18

Hi all, some days ago I opened a thread about DynamicBitset[1] (where I noted that a small piece of code may double the speed of a function), which received some interesting answers (you guys rock!) I looked deeper and realized that Boost doesn't have functionality to do common bit operations *really* fast. Let me explain - there are several places in Boost where we needed to solve typical tasks connected with bits in integers - like "get log2 of an integer rounded down" or "get the number of trailing zeros" or "count number of 1-bits", and Boost contributors have been inventing there a wheel everywhere, with varying degrees of optimality: [2] - [6]. Moreover, if a programmer writes a cross-platform app and has to do smth with this stuff, it's likely that for bit operations he will write a "naive" implementations - e.g. getting the log2(x) for O(log N), when it could be done for O(log log N), but with a more complicated code. Also, as well as "smart" algos, there are other methods to use - precalced tables, taking a small additional memory when needed [6], and intrinsics (that are CPU-specific). Combining of these methods (intrinsics when conveniently, or tables/algos) gives a notable shift in performance - here's my benchmark [7] from my tiny library [8]. Performance here varies from *9.2%* to *36.9%* of speed of related naive functions. I can tell you a usercase - as a hobby I'm writing a chess variants engine (where bitsets used to represent chess board, and its size is *not* fixed to 64), and bit operations' speed there is a matter of life and death. So, what do you think of an adapter header in Boost, covering all these operation of all integer types (and maybe some other one-liners like `is_bit_set(x, pos)` ), which keeps programmers out of platform specifics? It may look as smth like this [8] (I wrote only 3 functions, but it's enough to show the potential). I guess it can be placed somewhere to *Boost.Algorithm*, and supported with CI build tests of different platforms. P.S. The (incomplete) list of bit functions, that will give a *notable* better performance compared with naive algos and even some "smart" (because of precalc/intrinsics): - count of bits - parity of bit count - first 1-bit - last 1-bit (aka integer_log2(x)) - leading zeros - trailing zeros - swap(x) - returns x with the order of the bytes reversed; for example, 0xaabb becomes 0xbbaa. (bytes here are 8 bits exactly) - rotate_left(x, shift) - rotate_right(x, shift) Other functions may look like `is_set(x, pos) -> return x & (1 << pos)` and aren't so interesting. [1]: https://lists.boost.org/Archives/boost/2018/08/242825.php [2]: https://github.com/boostorg/integer/blob/develop/include/boost/integer/inte… [3]: https://github.com/boostorg/move/blob/develop/include/boost/move/algo/detai… [4]: https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/pendi… [5]: https://github.com/boostorg/integer/blob/develop/include/boost/integer/comm… (really almost the whole file) [6]: https://github.com/boostorg/dynamic_bitset/blob/develop/include/boost/detai… [7]: https://gist.githubusercontent.com/Izaron/8c94b76818393ffd93613d255033bb48/… [8]: https://github.com/Izaron/bit_algo/blob/master/include/bits.hpp

5 6

A possible date for dropping c++03 support
by Mike Dev 28 Aug '18

28 Aug '18

> -----Original Message----- > From: Glen Fernandes <glen.fernandes(a)gmail.com> > Sent: Tuesday, August 28, 2018 1:25 AM > To: mike.dev(a)gmx.de > Subject: Re: [boost] A possible date for dropping c++03 support > > On Mon, Aug 27, 2018 at 1:10 PM Mike Dev <mike.dev(a)gmx.de> wrote: > > Conditionally using a c++11/14/17 feature is (usually) not the problem > > although there are sometimes pitfalls as Peter mentioned. However, it also > > has limited utility. E.g. it doesn't make sense to simplify a function > > implementation using c++11 features like auto, range based for, decltype, > > constexpr instead of TMP, if you have to maintain the c++03 code path as well. > > In principle, you could conditionally get rid of some boost dependencies > > in c++11 mode, but again at the cost of maintaining two different code > > paths (as boost types often have slightly different semantics from c++11). > > So why do it? And you still can't deprecate the dependency itself because > > it is still needed in c++03 mode. > > Why do it? I do it when it provides some benefit to the users: > > e.g. If alternative implementation using C++14 constexpr results in > faster compilation for users. > If supporting C++11 move semantics results in better performance > for the users. > If supporting C++11 variadic templates results in a more > flexible interface for the users. > > i.e. If I'm the maintainer, and I'm happy to have that burden of > maintenance, why does anyone else care that I support > C++03/C++11/C++14 users, in addition to C++17 users? > > Yes, these are the high value proposition cases, that you mention. > > There's also no dependency to the user is there?. e.g. If a library > obtain std::addressof from <memory> in C++11 mode and doesn't source > it from Boost.Core, to the user, the library doesn't depend on > Boost.Core. > > > So except for cases with a very high value proposition (move semantics, > > simplified api, c++11 only functionality) or simple annotations (noexcept, > > override) using c++11 features *conditionally* is usually not all that > > beneficial. My hope here is that at some point, those boost libraries > > will finally start to use c++11 features *unconditionally* in order to > > simplify things - not add even more complexity in the form of conditional > > compilation. > > Simplify things for which party? Are you worried about users or Boost > library authors/maintainers? I don't see how users are inconvenienced > unless the user wants some feature only available in later C++ modes > that the library maintainer refuses to implement. > > Glen There are (at least) three problems: 1) Not all dependencies are private. If a library e.g. uses boost::function in its interface (in particular if it returns one) the user is also directly affected by changes to that dependency. 2) As you know, the c++ compilation model is incredibly leaky, meaning transitive dependencies are not hidden from the user. E.g. if you are using boost core in your header and I include it, I do get all the symbols (including macros) in my TU too. Boost has (usually) very good hygiene, so the main problems here are usually compilation times, sometimes code size and tools (code highlighting, static analysis, refactoring etc.) that either get slower or totally break e.g. because they don't have a perfect emulation of the compilation environment and don't know which code paths are the currently active ones or are just not able to understand all the TMP. 3) Not every library in boost is as well maintained as yours and I as a user prefer "cleaner / simpler" libraries because they a) tend to have fewer bugs, b) I can more easily modify things myself if necessary, c) the easier the life of the maintainer, the more likely he has time to add new functionalities. Finally, if boost can deprecate and at some point even remove some libraries, then their maintainers (in particular the CMT) can focus their time on different projects. Btw.: In case this was not clear: I'm not a boost contributor myself and for some time now, we (as in our company) are actively trying to avoid boost dependencies for various reasons that have more to do with boost-internal stuff and the boost eco system than with e.g. inconvenient interfaces. So yes, at least some end-users do really care about the internals of boost. But admittedly, I mostly work on (semi-) embedded projects where we have to compile (and on rare occasion even modify) boost ourselves - not sure how common that is. Best Mike

3 3

[gil] Template instantiation with GCC 8 is 50x slower than with clang++
by Mateusz Loskot 26 Aug '18

26 Aug '18

Hi, One of Boost.GIL users reported very long compilation times with GCC 7 and 8 https://github.com/boostorg/gil/issues/131 then, reproduced the problem with a minimal example without Boost GIL and MPL dependencies. The issue has been reported to GCC developers - I think users/developers of other Boost libraries may be interested too https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87107 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

1 0

[dynamic_bitset] Using of GCC built-in functions may increase performance of some methods
by Evgeny Shulgin 26 Aug '18

26 Aug '18

Hi all, when I was playing around the Boost.DynamicBitset library, I noticed the last lines of the count() function (which returns the number of bits in the bitset that are set): return do_count(m_bits.begin(), num_blocks(), Block(0), static_cast<value_to_type<(bool)mode> *>(0)); Well, this line was modified 10 years ago last time. Let's go deeper. GNU C provides several language features not found in ISO standard C. These include a bunch of bit operations - you can look at them here: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html. For example, *__builtin_popcountll *counts the number of bits in an 'unsigned long long', so we can use this kind of code to calculate bits (don't judge, I wrote this fast and didn't think of coding standards): size_type res = 0; for (size_type i = 0; i < m_bits.size(); i++) { res += __builtin_popcountll(m_bits[i]); } I checked that m_bits[] and popcount() both work with 64-bit values on my machine. It halved the running time of a program that has a bitset and calls count() over and over again - here's the code <https://gist.github.com/Izaron/5005fed4184ee6483699191dc5ef3677> I used. These __builtin_XXX functions can be used everywhere where it's possible, with preprocessor directives. Or is it actually used and longer time means something else? I used the latest version of Boost.

6 8

[test][pull#151] Fix warning: BOOST_CLANG is not defined, evaluates to 0
by Mateusz Loskot 26 Aug '18

26 Aug '18

Hi, I've submitted a tiny fix for this annoyance: https://github.com/boostorg/test/pull/151 May I ask the library maintainers to merge it? Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

2 1

GNOME outreachy
by Pranam Lashkari 26 Aug '18

26 Aug '18

GSoC just finished and it helped grow the community by adding few new students and maybe mentors to our Boost community. I was hoping why don't we also apply for GNOME outreachy also it is also similar to GSoC and can also help our community to grow. and by appearing in end of year internship in GNOME outreachy we can keep a flow of new contributors and motivate people to contribute to opensource throughout the year. Thank you, Pranam Lashkari

14 26

[regex] Drawing attention to link issue
by Antony Polukhin 24 Aug '18

24 Aug '18

Hello, The build flags for shared libraries are changing right now in b2. See https://github.com/boostorg/boost/pull/190 for more info. The thing is that Boost.Regex fails to link with those new flags, probably because of the https://github.com/boostorg/regex/issues/49 issue. If there's no simple solution for the above case, then please merge the https://github.com/boostorg/regex/pull/66/ . It should help. Thanks in advance!

2 2

[MSM] Still maintained?
by Christophe Henry 24 Aug '18

24 Aug '18

>Hi Boost-list, > >because I realized that my simple PR for Boost.MSM [1] (which makes it >compilable with C++17) and an even older one did not receive any >attention, I wonder if Boost.MSM is still actively maintained. > >The latest changes seem to be from around December 2017. > >Does anyone know, if Christophe is still active? > > >Best regards, >Deniz Hi Deniz, Sorry, I didn't have time to do it before vacations, I only merged your change to develop now. Thanks, Christophe

2 1

[type_traits][core] modularisation and moving stuff about (again)
by John Maddock 23 Aug '18

23 Aug '18

So... I have a couple of PR's to move some of type_traits into config so it can be used by core. It's a modest proposal so I can go with that I guess... but this moving stuff about all over the place just to satisfy dependencies does wind me up a bit - I know that I sometime struggle to figure out where stuff is on Github - half of Integer is in Config for example. How on earth would an end user figure that out in order to file a PR or a bug report? I know... "calm down dear" and all that ;) So radical suggestion - does type_traits just belong in core and lets be done with it? What would happen to the file history if we moved it (can I still "git blame")? DARFC, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

5 16

Re: [boost] [type_traits][core] modularisation and moving stuff about (again)
by Glen Fernandes 23 Aug '18

23 Aug '18

Andrey Semashev wrote: > I would rather encourage people use type traits, the official > interface. Boost.Config or Boost.TypeTraits could provide macros that > allow users to detect whether is_final is emulated or is the real > deal. One thing about this suggestion: If Boost.Config was to provide macros that tell users whether Boost.TypeTraits' boost::is_final<T>::value is emulated or the real deal, then the compiler detection logic currently in Boost.TypeTraits for detecting __is_final would already have to be duplicated in Boost.Config. That does not sound like a great idea. Right now TypeTraits provides both, which is better. i.e. It provides boost::is_final<T>::value and BOOST_IS_FINAL(T). The former uses the latter if it is defined, or is always false if not defined. If BOOST_IS_FINAL(T) and all its compiler detection logic lives in TypeTraits, then that all that compiler detection logic should not be duplicated in Config to provide a BOOST_HAS_IS_FINAL_INTRINSIC or similar feature detection macro. Glen

5 13

[test] I want my core dumped
by Alain Miniussi 22 Aug '18

22 Aug '18

Hi, I have assert in my library code, but when the assert fire in a test, the main function in minimal.hpp intercept the signal and explains that, yes, you asked for an abort, but no: [...] ../../../boost/test/minimal.hpp(136): exception "signal: SIGABRT (application abort requested)" caught in function: 'int main(int, char **)' Is there a way to avoid that behavior ? I need that core file. Thanks Alain

3 2

[multiprecision] Design question on variable precision types.
by John Maddock 22 Aug '18

22 Aug '18

Folks, I have a tricky design question that Boost.Multiprecision has been dodging relating to variable precision types - these have just expanded somewhat now that we support complex numbers via mpc as well as mpfr's reals etc. The basic use case is this: We have a set of numbers at very high precision, some calculations are performed on those directly, others we want to temporarily drop precision, get an approximate answer and perhaps later refine it. Generally speaking, performance trumps everything, on a really long running calculation 10-20% speedup can actually make a big difference (in $$'s in some cases if the CPU time is from the cloud). Up till now Boost.Multiprecision has been dodging this issue - it's actually pretty hard to program in a sane and consistent way, so the message has been "don't mix precisions" when using a type like boost::multiprecision::mpfr_float - just set what default you want and get on with it. But we really should do better than that. So... with the help of Danielle Brake I've been trying to nail this down in develop, what we have at present is: * Copy construction or move assignment copies the precision of the source. * Regular assignment retains the precision of the target variable. This is efficient in that assignment doesn't reallocate to a new precision, and provides an easy way to up/down sample precision when required. But it breaks equality after assignment. It does match what MPC/MPFR do in mpfr_set etc though. The fact that move assignment behaves differently from regular assignment bother me too - it's too easy to write code that triggers move semantics without noticing. The trouble is, being able to assign while retaining precision of source is sometimes useful too, so having move-assign behave differently provides a useful back door, but maybe one that's just too cute for it's own good? And then.... we get on to arithmetic. * Currently temporaries are created at current default precision. So it's easy to shoot yourself in the foot by not noticing that temporaries are being created in an expression and not having the default precision set correctly. I actually think this one might be solvable, but it's a huge job involving banning default constructors in all the backends to our number types, and then catching all the cases where they might have been used. * What should happen in "a = expression", where the variable used in "expression" are at different precision to a? The uncontroversial answer might be to adjust the result to the precision of a. But hold on... we have expression templates, and these can use variable a as working space while evaluating the expression... so the change in precision might occur *during* the computation and not after it. * Should we try to ban mixed precision arithmetic altogether? It's a tempting idea, but I can't see how to enforce it in code without also banning mixed precision assignment. Thanks for your consideration, John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

2 1

[MSM] Still maintained?
by Deniz Bahadir 22 Aug '18

22 Aug '18

Hi Boost-list, because I realized that my simple PR for Boost.MSM [1] (which makes it compilable with C++17) and an even older one did not receive any attention, I wonder if Boost.MSM is still actively maintained. The latest changes seem to be from around December 2017. Does anyone know, if Christophe is still active? Best regards, Deniz [1] https://github.com/boostorg/msm/pull/15 -- BENOCS GmbH Dipl.-Inform. Deniz Bahadir Reuchlinstr. 10 D 10553 Berlin Germany Phone: +49 - 30 / 577 0004-22 Email: deniz.bahadir(a)benocs.com www.benocs.com Advisory Board (Chairman): Oliver Fietz Board of Management: Stephan Schröder, Dr.-Ing. Oliver Holschke, Dr.-Ing. Ingmar Poese Commercial Register: Amtsgericht Bonn HRB 19378

1 0

Increasing BOOST_PP_VARIADICS_SIZE
by Damien Buhl 20 Aug '18

20 Aug '18

Dear Edward, In comparison to BOOST_PP_SEQ, BOOST_PP_VARIADICS is limited to 64 elements while BOOST_PP_SEQ is limited 255. Is there a reason for the choice of 64 or could I patch BOOST_PP_VARIADICS to go as BOOST_PP_SEQ to a limit of 255 ? Or asked differently do you think there are in newer compilers/standards a way to have an unbounded BOOST_PP_VARIADICS implementation nowadays ? Warm Regards, -- Damien Buhl Software Developer +33 6 77 43 10 05

2 2

ABI issues with -std
by Peter Dimov 20 Aug '18

20 Aug '18

At some point, we'll need to acknowledge the problem which results from building Boost with one -std and user code with another, and deal with it somehow, if just by documenting. Most of our libraries don't suffer from it at the moment but Boost.System does, because of my changes; its ABI changes between 03/11/14. So I'm going to take the initial hit. :-) POSIX platforms have long been able to ignore ABI issues so we don't mangle the library names there at all, but now whether one builds Boost for C++03, C++11 or C++14 matters, and there's nothing to prevent linking C++xx to C++yy. Even with --layout=versioned, the cxxstd level is not encoded. The fact that the default C++ standard differs between g++ and clang++ doesn't help; when following the instructions of doing "b2 install", with g++6 and above you get C++14, but with g++5 or clang++ you get C++03. The latter is very rarely what one wants today.

7 26

Formal review request: Synapse
by Emil Dotchevski 16 Aug '18

16 Aug '18

Hello, I'm requesting a formal review for Synapse, a non-intrusive signal programming library. Synapse is a non-intrusive C++ signal programming library. It is able to register connections and emit signals from any C or C++ object of any type whatsoever. If two contexts share access to a C or C++ object, they can use that object as a randezvouz point of sorts, and communicate with each other through Synapse signals. A system of meta signals provides interoperability with other signal programming libraries and callback APIs. In particular Synapse can be used to safely register C++ function objects, including lambda functions, with any C-style callback API that is designed to work only with C function pointers. In a multi-thread environment signals can be emitted asynchronously and scheduled for synchronous execution when requested in other threads. There have been numerous improvements since the first review, including the the ability to create persistent connections which don't require the user to explicitly keep them alive. See https://zajo.github.io/boost-synapse/. Thanks, Emil

2 1

Strange libstdc++ versions in travis-ci testers
by Andrzej Krzemienski 15 Aug '18

15 Aug '18

Hi Everyone, Maybe someone could help me understand the configuration on the travis-ci testers. Whenever I push a new commit I get a number of failures from travis-ci about missing std::is_trivially_default_constructible from the standard library; like here: https://travis-ci.org/boostorg/optional/builds/397519342?utm_source=email&u… Some tests with Boost.Predef indicate that they are clang compiler 3.X, and clang 5 with libstdc++ of strange version nubers: macro BOOST_LIB_STD_GNU gives values 450400026 and 460700026, which would correspond to releases 2015-04-26 and 2016-07-26, but when I look at the release notes for GCC there are no releases mentioned of these dates: https://gcc.gnu.org/news.html Maybe someone knows what versions of libstdc++ these are? Or maybe I am missing something obvious? Regards, &rzej;

5 12

numeric directory/namespace
by Robert Ramey 14 Aug '18

14 Aug '18

I'm preparing to make adjustments to safe_numerics directory and namespace in preparation to incorporating safe_numerics into the official boost distributions. I have a couple of decisions to make that someone/everyone will want to weigh in on. There is already a directory boost_root/libs/numeric which seems to be an "umbrella" for libraries dealing with numerics. It includes conversion, interval, odeint and ublas. There is an index.html in there also. But instead of referring to the above libraries, it points to the ublas documentation. So it's sort of tempting the place safe numerics in libs as a sub directory. But I really have strong reservations about the whole concept of have this "umbrella" directory in the first place. Personally I'd just prefer to use boost_root/libs/safe_numerics. I don't think the extra structure adds anything and makes it harder to implement tools which scan the directories. It would also mean that I should ? use #include <boost/numeric/safe_numeric/ ....> and I'm not sure want to do that. Also I expect I'll want to sync the namespace boost::numeric::safe_numeric:: ... with the file system. It just seems more complex and flexible than it has to be. I see the future of boost as diminishing coupling between libraries and I see the current setup as not helping with this. Please don't wait to answer until I've made the changes. Robert Ramey

3 2

[container] [flat_map] Error with heterogeneous comparator and std::string_view
by Viktor Sehr 13 Aug '18

13 Aug '18

On MSVC (latest) the following code yields a compile error with flat_map, but not with std::map. I do not have the knowledge of std::less<> to resolve what causes the error. auto fm = boost::container::flat_map<std::string, int, std::less<> >{}; auto m = std::map<std::string, int, std::less<> >{}; auto k = std::string_view{ "my_key" }; auto x = m.find(k); // Compiles auto y = fm.find(k); // Does NOT compile Error message: 1>boost\container\flat_map.hpp(1314): error C2664: 'boost::container::vec_iterator<boost::container::dtl::pair<Key,T> *,true> boost::container::dtl::flat_tree<boost::container::dtl::pair<Key,T>,boost::container::dtl::select1st<Key>,Compare,boost::container::new_allocator<T2>>::find(const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &) const': cannot convert argument 1 from 'const std::string_view' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>> &' 1> with 1> [ 1> Key=std::string, 1> T=int, 1> Compare=std::less<void>, 1> T2=boost::container::dtl::pair<std::string,int> 1> ] 1> boost\container\flat_map.hpp(1314): note: Reason: cannot convert from 'const std::string_view' to 'const std::basic_string<char,std::char_traits<char>,std::allocator<char>>' 1> boost\container\flat_map.hpp(1314): note: No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called Best regards /Viktor

4 7

Library Federation
by Robert Ramey 12 Aug '18

12 Aug '18

I'm now taking steps to get safe numerics integrated into the boost distribution. It's reminded me of a running complaint I have about using boost. a) When I use anything boost, I'm required to do two things: i) run b2 headers to create a forwarding header in the boost directory ii) include via command line or INCLUDE variable to boost root. b) If I want to use safe_numerics before it is included in the boost distribution, I have to place safe_numerics into it's expected destination in the boost hierarchy and run b2 headers AGAIN to make things match up. This is even more problematic in that b2 headers is not invoked "automagically" in such a way that people don't know it's there. To me, this just makes it harder to use / test any new library with boost without dragging in access to a bunch of stuff I may not want. It inhibits those without beam foo from running the tests etc. This is why I did things the way I did. Now I'm getting ready to add it to the boost distribution, I'll change this to do it the "boost way". Not so much because I think it's better but in this case, consistency is better than variety. But I'm still unsatisfied with the situation. It's part of the reason that boost is avoided when possible by many people. Isn't there a better way? I think there might be. Rather than sprinkling a bunch of forwarding headers around my file system - which are "sticky" and need to be updated from time to time, how about depending on the "INCLUDE" environmental variables available in gcc and msvc and clang. Using "some method", I would be able generate this variable via some sort of batch script - not too tough. And work as I do now. But a) the script would be re-run when ever I changed projects so that it "stuck" in my file system. b) It could be smarter - include only the boost include directories I'm actually using - thus avoiding accidently including surprising stuff. c) We have tools which figure out boost dependencies automatically so I don't think it would be a big stretch to do this automagically. d) If my project is "larger" and includes a bunch of stuff from other libraries, I could add these in as well. This would give my the concept of "library federation" where my app is linked to some list defined as part of the project. I'm sure this concept also sort of exists. e) my pet request would be that I could say: tool application.cpp ... >include environment output to generate the env output for all the target apps. Of course one could you * wild cards as well. This would let me create one set on includes for building/running my test suite and a different one for examples and a different one for my "real" application. I'll stop there so as to leave opportunity for discussion. Robert Ramey

3 7

Please merge into boostorg superproject
by James E. King III 11 Aug '18

11 Aug '18

Please merge into boost superproject - these have passed CI and have been reviewed: https://github.com/boostorg/boost/pull/186 https://github.com/boostorg/boost/pull/181 Please decide what to do with: https://github.com/boostorg/boost/pull/39 (I can't tell if this is defunct?) https://github.com/boostorg/boost/pull/184 (do we want this in the superproject, or a submodule called boostorg/docker, or not at all?) Thanks, Jim

1 0

iostreams in 1.68.0
by James E. King III 11 Aug '18

11 Aug '18

Hi folks, just a note that none of the changes since 1.67.0 got into 1.68.0 master. They were on develop and never merged. I just merged them for 1.69.0. - Jim

1 0

[release] 1.69.0 open for merging
by Marshall Clow 10 Aug '18

10 Aug '18

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

2 1