- Boost - lists.boost.org

C++Now 2019 Registration is Open
by Jon Kalb 24 Jan '19

24 Jan '19

Boosters, Registration for C++Nows 2019 (aka BoostCon) is now open: http://cppnow.org/announcements/2019/01/2019-registration-is-open/ Please help us to spread the word about this announcement. Thanks. Note that the Aspen Meadows Resort online registration link is also up on the lodging page. Because there will be another group in the hotel, we’ve been allocated fewer rooms this year. Please either reserve a room very soon or plan to stay at the Lamplighter or another hotel in town. See you in Aspen in May. Jon

1 0

[gsoc19][GIL] Project proposal
by Miral Shah 23 Jan '19

23 Jan '19

Hello everyone, I am Miral Shah a computer engineering student from India. I have been talking with Boost.GIL community on GIL's Gitter channel since last few weeks to come up with the new idea for GSoC19. After many suggestions and a long discussion on various ideas with the contributors, we have come up with the idea to expand the GIL by introducing new image processing algorithms into it. I would also like to thank Stefan Seefeld and Mateusz Loskot for their guidance and support. Proposal idea can be found here: https://github.com/boostorg/gil/wiki/GSoC-2019 Thank you, Miral Shah

1 0

Boost log issues and workarounds
by hh h 21 Jan '19

21 Jan '19

Hi, I like the boost log, but there are many small issues, appreciate your kind help: I followed the following link to use a good macro LOG: https://stackoverflow.com/questions/35895199/boost-log-and-severity-local-a… But calling LOG(error) caused much trouble for the name space collision, alternative is to use full namespace boost::log::trivial::error, but that is too cumbersome,I tried to use an uppercase ERROR to replace it in an enum ERROR = boost::log::trivial::error, obviously that could not be complied, although it is defined as enum severity_level in trivial.hpp, it does not look like the boost::log::trivial::error is an enum value. Any workarounds? Another issue from that link is it has to call LOGGABLE prior to call LOG(error) in each function, that makes more clumsy, software developers in my team are not happy about it. Any workaround to have a fixed argument in BOOST_LOG_STREAM_WITH_PARAMS, without need to claim boost::log::sources::severity_logger<boost::log::trivial::severity_level> slg; in each function? You guys are genius that must be a way to do it, appreciate your advice. Thank you

4 22

[lockfree] wait-free multi-queue?
by Shawn Yarbrough 18 Jan '19

18 Jan '19

Is it practical to have a wait-free, multi-producer/multi-consumer queue? I ask because Boost's Lockfree multi-queue is only advertised as being "lock-free". (Boost does offer a wait-free single-queue.) https://www.boost.org/doc/libs/1_69_0/doc/html/lockfree.html Shawn Y.

2 1

Re: [boost] [parameter] Helping user libraries adjust to recent changes in GitHub develop branch
by Cromwell Enage 17 Jan '19

17 Jan '19

Happy New Year, everyone! > I've been contributing upgrades to Boost.Parameter functionality > and documentation in the GitHub develop branch for the past > couple of months. These upgrades include the addition of code > generation macros for Boost.Parameter-enabled function call > operators and support for perfect forwarding, and more upgrades > are yet to come. It's been an enjoyable experience so far, > but understandably there are some growing pains. I've taken > pains to ensure that as long as user libraries access only the > public interface of Boost.Parameter, they won't be affected by > the changes. However, there are several notable libraries that > currently use non-public portions of Boost.Parameter, so > whenever possible I've submitted PRs to those libraries that > either change the usage to access only public portions > (preferred) or make quick fixes (temporary). Update: As of this writing, I have active PRs for the following libraries: Boost.Accumulators Boost.Convert Boost.Graph Boost.Log AFAIK, these are the libraries most directly affected by the changes. To reiterate: I'm willing to help the library maintainers resolve these issues as quickly as possible. I should be able to answer any questions you have about the changes to Boost.Parameter. Cromwell D. Enage

3 2

[histogram] discussion of accessor interface design
by Hans Dembinski 15 Jan '19

15 Jan '19

Dear all, work on boost.histogram is progressing fast. I am still implementing feedback from the review, simplifying the interface, adding requested features, such as axes that can grow. STL compatibility was further improved, you can now also write to histograms via iterators. The normal iterators make sense when you iterate over a 1D histogram. When you iterate over a multi-dimensional histogram, you also want to know the current multi-dimensional index. After considering many options, and I really thought about this a lot, I went for the following design, which is a bit unusual. Therefore I would appreciate feedback. I think it is great, once you overcome an initial feeling of awkwardness. The accessor class is "polymorphic", it behaves like a pointer to the histogram value, and like an array for the multi-dimensional index. In code, this is how you use it: auto h = make_histogram(…) // make 2D histogram for (auto && x : indexed(h)) { // indexed produces a range of accessors // x is a special accessor type, combining two non-overlapping concepts // - it acts like a pointer to the histogram value // - it acts like an array to the current index std::cout << "current value " << *x << std::endl; // "dereference" to get value std::cout << "current index " << x[0] << " " << x[1] << std::endl; // use subscript operator to get index } This syntax is beautifully terse, e.g. see https://github.com/HDembinski/histogram/blob/develop/examples/guide_access_… for a full example, especially line 66. Pros: - really terse - you can access methods on the pointee with x->method() as well! (useful when histogram counters are not PODs) - you can iterate over x to get the indices, for (auto i : x) { … } works - since x acts like an array to the indices, you can pass it to functions which accept ranges or iterators (it has .begin() and .end()) - x can be (and is) enhanced with other useful methods * x.bin(N) returns the current bin interval for the N-th axis, allowing you to access the central value, width, edges * x.density() returns the current density (bin value divided by product of current bin widths) Cons: - *x and x[0] do completely different things: *x gives you the bin value, x[0] gives you the first index The last point is, of course, where people have a problem. But if you take C++ concepts seriously then the accessor is a perfect model of a pointer and a perfect model of an array. These two roles are non-overlapping and they have non-overlapping sets of interfaces, which I exploit here. If you have the expectation that *x and x[0] should do the same thing, it is so because of C. C has no extensive type system like C++ and does not distinguish between arrays and pointers, although these are very different concepts. A pointer points to a value, and an array is a collection of values. "dereferencing" a collection of values makes no sense, we are just used to it because of our C heritage. C++ has a better type system, and better classes for pointers and arrays than raw pointers. The stdlib authors recognize that *x has no meaning when x is a sequence of values. *x fails when x is a std::vector, std::deque, std::list, or any kind of collection in the stdlib. Even for std::unique_ptr, they made sure that the interfaces for the pointer-to-object and pointer-to-array specializations behave differently: ``` #include <memory> int main() { std::unique_ptr<int> p(new int); // pointer version // p[0]; // fails *p; // OK std::unique_ptr<int[]> a(new int[3]); // array version // *a; // fails a[0]; // OK } ``` Once you accept that the two concepts of pointers and arrays have non-overlapping interfaces in C++, it becomes possible to make a combined object which has both interfaces, and uses these two sets to return different information. If you have read this far, I hope your initial reaction of "woah, this looks really inconsistent and confusing!" turned to "hmm, maybe it is not inconsistent after all". I am looking forward to hear your thoughts. Best regards, Hans PS: The alternative would be to return a std::pair<index_type, value_reference_type>, but this has disadvantages. Unpacking the pair is going be nice in C++17 with structured bindings, but not so much in C++14. Also, it prevents me from adding convenience methods, like the above-mentioned bin(N) and density() methods.

1 0

boost log to concatenate just one log file
by hh h 15 Jan '19

15 Jan '19

Hi, I added boost::log::keywords::open_mode = std::ios_base::app to the log configuration, but it did not stop log file proliferation, every time I started the program, it created a new log file mylog.log0000x, how can I stop creating new logs? Thank you.

2 2

Is it possiable to use a simple LOG(info) in boost log?
by hh h 15 Jan '19

15 Jan '19

Hi, After trying many days on boost log, still have many issues. Google log has a nice LOG(INFO) << "debug";, looks like that kind thing cannot do in boost log, the close online code in https://stackoverflow.com/questions/35895199/boost-log-and-severity-local-a… has to call LOGGABLE first then to use LOG(info) << "my log", it is really cumbersome, is it possible to call LOG(info) like glog? Thank you.

1 1

Boost.Build requirements to exclude GCC 5
by Niall Douglas 14 Jan '19

14 Jan '19

Outcome is now into Boost, and is being tested nightly: Docs in BoostDoc theme: https://www.boost.org/doc/libs/develop/libs/outcome/doc/html/index.html Regression matrix: https://www.boost.org/development/tests/develop/developer/outcome.html One problem is how to exclude from testing GCC 5 which Outcome cannot support due to GCC 5's incorrect parsing of variable templates in nested template classes [1], so I need some sort of Boost.Build project requirement which explicitly excludes GCC 5. Unfortunately, GCC 5 appears to Boost.Config as fully implementing C++ 14, so this is not straightforward. What might work is to specify a requirement for one of the library items at https://github.com/boostorg/config/blob/develop/checks/Jamfile.v2 which we know for a fact libstdc++ 5 does not implement, but libstdc++ 6 does. However, clang with libstdc++ 5 would then be excluded incorrectly, as clang does not have this parsing bug. I guess ideally speaking Boost.Config gains a new test testing for this specific compiler parsing bug. But it seems a bit much to ask for this just for Outcome. Guidance is sought! Niall [1]: https://www.boost.org/development/tests/develop/developer/output/teeks99-02…

4 5

C++Now 2019 Submission Deadline
by Jon Kalb 14 Jan '19

14 Jan '19

The deadline for submitting to C++Now 2019 is just a few days away. If you’ve been thinking of submitting, please do not delay: http://cppnow.org/announcements/2018/12/2019-call-for-submissions/ <http://cppnow.org/announcements/2018/12/2019-call-for-submissions/> Thanks. Jon

1 0