- Boost - lists.preview.boost.org

Contributing in the algorithm library
by Surayans Tiwari 24 Jan '18

24 Jan '18

Hello Boost Community! My name is Surayans Tiwari currently pursuing Bachelors of Engineering at BITS Pilani, India . I am an algorithms enthusiast and c++ programmer with 3 years of experience coding in the language. I want to get a head start on how to add new modules in algorithm library of boost. Please can someone help me with this. Thank you. ‌

4 10

[outcome] Whether to default EC = error_code for result?
by Niall Douglas 23 Jan '18

23 Jan '18

Just wondering what the reviewers' opinion is on the choice by Outcome to default `result<T, EC = std::error_code>`? That made sense back when Boost.System's error_code aliased `std::error_code` when being compiled under C++ 11 or better (i.e. always in the case of Outcome). But now that Boost.System's error code looks to be becoming a superset of `std::error_code`, I am now wondering whether to no longer default it at all to anything. Arguments in favour of this: 1. Expected no longer defaults E to anything, thus avoiding including <system_error> which drags in <string> and imposing compile time costs on those who don't use <system_error>. I did some more benchmarking, on a recent GCC on a 4Ghz CPU it's about 0.6 secs per compiland being added on Linux, and more like a second on Windows with MSVC. 2. As is pretty clear from the tutorial, we expect all non-trivial uses of Outcome to typedef `result` into the local namespace anyway. So defaulting `EC` only really benefits trivial use cases. 3. I think it now inevitable I need to go implement a much lighter weight <system_error2> without the problems with <system_error> (e.g. header only use problems, heavy includes, underspecified semantics, hardcoded use of `int`, memory allocation and so on). I'll send it to SG14 for them to get it into the standard if they like it (they will, it'll tick all their boxes, WG21 may be more challenging). Arguments against this: 1. Use of `std::error_code` ought to be encouraged rather than UDTs such that Outcome using code is not anti-social to other code. Defaulting the type sends a clear message on this. 2. Removing the defaulted `EC` on `result` is asymmetrical to defaulting `EC` and `EP` on `outcome`. I personally don't mind it, different typical use cases means different defaults, but others may find the asymmetry upsetting. 3. The relevant policies need to include `<system_error>`, otherwise they don't compile. So the include of `result.hpp` would need to be split into a `result.hpp` and a `error_code_support.hpp` with the latter containing the `<system_error>` stuff. Thoughts? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

23 Jan '18

While refactoring the test Jamfile for Boost.System, I wrote this rule: rule system-run- ( sources + ) { local result ; result += [ run $(sources) : : : <link>static : $(sources[1]:B)_static ] ; result += [ run $(sources) : : : <link>shared : $(sources[1]:B)_shared ] ; result += [ run $(sources) : : : -<library>/boost/system//boost_system <define>BOOST_ERROR_CODE_HEADER_ONLY : $(sources[1]:B)_header ] ; return $(result) ; } to avoid repeating each test three times. The inconsistency is somewhat annoying. We could normalize the third line by introducing a third link type, <link>header, in response to which the library can switch to header-only mode. This is more or less the same suggestion as Niall's _hl targets from the CMake discussion, but it fits Boost.Build better, because the <link> property is automatically propagated to dependencies. Furthermore, after thinking about it a bit, I think that we might even have room for a fourth link type, <link>source, in response to which the library target would pass an appropriate <source> usage-requirement upwards. (<source>error_code.cpp in Boost.System's case.) <link>source is kind of best of both worlds, as it doesn't reparse the source code each time the library is used, and at the same time is not prone to the ODR violations introduced by inadvertently compiling the library and the executable with different, ABI-incompatible options. Comments?

2 4

[git][releases] removing beta tags
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi all, I would like to know if it is allowed to delete the git tags that are associated to beta releases (such as "boost-1.45.0-beta1"). Thanks, Raffi

2 2

[trac] email notifications?
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi, Is trac sending email notification on comments and changes regarding tickets? It used to do so, but I am not receiving anything. I am asking because I am waiting for ppl to comment on the tickets for some time. If people do not receive email notifications, I think I will wait for ever. Thanks, Raffi

2 2

[trac] new versions of boost
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi there, Would it be possible to add the next versions of boost to trac/milestones ? Thanks! Raffi

7 12

[system] Would it be possible to trial a breaking change to Boost.System and see what happens?
by Niall Douglas 22 Jan '18

22 Jan '18

SG14 the low latency study has been looking into how to improve some design decisions in <system_error>. The relevant WG21 paper is https://wg21.link/P0824 and recent discussion can be found at https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/j7tQybEjP5s. What we'd like to do is to test whether some very mildly breaking changes to <system_error> are so mild as to affect no users, and on that basis propose WG21 to make those mildly breaking changes to <system_error> in the next C++ standard. And to test this, we'd like to modify Boost.System with those mildly breaking changes, ship a release and see how many users complain. If it is zero, we have evidence for WG21 that this is not a consequential change. What we'd like to change is this: 1. Stop treating code zero as always meaning success irrespective of category. This remedies a defect where some custom error code domains cannot be represented by error_code due to using value 0 for an error. In actual code, I've never seen anyone ever use comparison to anything but a default constructed error code, so I think this will be safe. 2. Success becomes solely the default constructed error code, which is code zero and a new category of "null_category". This is internally represented by { 0, nullptr }, and thus makes the default constructor trivial which is highly desirable as it eliminates any compiler magic static fencing for the default constructor. Right now the default constructor uses system_category with value 0, and I suspect no code will notice this change either. 3, Make the default constructor constexpr, now possible. No code should notice a difference, except less runtime code will be generated. 4. error_code::message() returns a std::string_view instead of std::string if running C++ 17 or better. This lets us remove the <string> dependency, and thus stop dragging in half the STL with <system_error> which in turn makes <system_error> actually useful to the embedded systems crowd. The guess here is that std::string_view has such excellent interoperation with std::string that I think 99% of code will compile and work perfectly without anybody noticing a thing. I appreciate that this would undo Peter Dimov's excellent work at having Boost.System alias <system_error> under C++ 11 and later. I also appreciate that we are deliberately going to potentially break end user code. But my personal guess is that in practice, the breakage will not be noticed by 99% of code out there right now. It'll just compile against the improved Boost.System and everything will work as before. Boost was originally intended as an incubator for C++ standard changes. This ticks that box perfectly. Thoughts on feasibility? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

15 76

Travis CI Resources
by James E. King, III 22 Jan '18

22 Jan '18

Last summer we had a discussion about Travis CI Resource Usage for boostorg. Originally the discussion was about purchasing more resources; however the discussion quickly focused on finding the root cause of the backlog. The desire is to ensure that pull requests submitted to repositories are processed in a timely manner. This is not happening, and there is at least a 12 hour backlog on pull request builds for boostorg right now. Summarizing the discussion back then, it was proposed that the backlog was caused by folks working on feature branches directly in their boostorg repository, with the Travis CI setting enabled to "build branch updates". The proposed solution was to encourage everybody to fork their repository and set up their own Travis CI and Appveyor under their account, and work feature branches on your fork. If working alone, this is efficient for everyone as we all end up with faster builds because your account will not contend with boostorg for resources. So please, use your personal account to build up features if you can. Additionally, tuning your Travis CI build script to do a little bit less work will help. If you have a script that builds with gcc, gcc-5, gcc-6, gcc-7, clang, and cxxstd of 03,11,14,1z - for most libraries that are at the c++03 language level this is going to be significant overkill for use as a pull request gate. In the example above, there are 20 builds to do; double that if you build debug and release variants. If each build takes just 2 minutes that's still an 80 minute CI cycle. Please spend some time reviewing your practices around the use of the free CI resources we all share. Thanks, Jim

5 11

[config] Supporting newer compilers: what does it take?
by Olaf van der Spek 22 Jan '18

22 Jan '18

Hi, What does it take to support new compilers, especially MSVC? 15.6 Preview 1 has been released now. Is some documentation or policy regarding test runners etc available? https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-… Gr, -- Olaf

1 1

[gsoc18] RSS
by Greger 22 Jan '18

22 Jan '18

Got some code/idea for RSS. possibly an GSoC18 topic?anyone? br g

2 3