- Boost - lists.boost.org

Safe numerics at Meeting C++
by Robert Ramey 12 Jan '19

12 Jan '19

News Flash for both of you interested in the Boost Safe Numerics Library. Checkout https://www.youtube.com/watch?time_continue=942&v=tcyb1lpEHm0 at 1 hour in. The whole rest of the talk is about a safe integer implementation written D. He uses it to illustrate his concept of "Introspective Programming". ALL the features and techniques he mentions (and more) are implemented in the safe numerics library. The Safe Numerics library is the Next Big thing! Robert Ramey

1 0

question/guidence regarding merge to master
by Robert Ramey 12 Jan '19

12 Jan '19

I'm looking to merge my develop branch into the master so that they will be in sync. I'm thinking that this the changed in develop should be squashed so that the master branch doesn't included all the the intermediate changes made during the develop phase. Is there any boost rule/practice/guidence regarding this?. Ideally, I'd like to see the master have only one set of consolidated changes for each release. But I'm not the person who decides these things or does the work. Any insight by other parties would be appreciated. Robert Ramey

10 29

Re: [boost] A class for embedded friendly callbacks.
by Bjorn Reese 12 Jan '19

12 Jan '19

On 1/4/19 1:30 PM, Mikael Rosbacke via Boost wrote: > I'm Mikael Rosbacke and new to this list. The last couple of months I've > been writing on a class for storing callbacks to different forms of > callables (member functions, functors, free functions). The main focus A while back, a somewhat similar library underwent a formal review. You may want to read the review report to see if any of the comments applies to your library: https://lists.boost.org/boost-announce/2016/12/0484.php

1 0

Re: [boost] Feedback desired for reflective enum library
by Nir Friedman 12 Jan '19

12 Jan '19

I had to fill in the subject for this manually, because of settings for the mailing list. I really hope it ends up on the right thread. Apologies if it doesn't. Hi Geert, There is an ADAPT macro, which is similar to your concept of CONVERT_TO_WISE_ENUM. However, it does require listing the enumerators; after all there's no way to find them out after the fact or else this library wouldn't exist in the first place. That said, I'm not quite sure what you mean by "changing your whole codebase". To take advantage of wise enums, all you'd need to do is change the original enum declaration to the wise enum macro. Everything else in your codebase will continue to work exactly as before. No typedef shenangians are necessary. Changing the original enum declaration is exactly the same amount of work as writing an adapt macro, but you don't have to maintain the list of enumerators twice. So I can't imagine a reason to write things the way you have (unless you want a conditional build dependency on WISE_ENUM but that seems unnecessary). The ADAPT macro is designed to be use wise_enum functionality generically with enumerators whose source you don't control, and therefore cannot change the declaration. Hope that clarifies things. Cheers, Nir

1 0

boost log to display source code name and lines
by hh h 11 Jan '19

11 Jan '19

Hi, I am looking for good log library to replace google log, my plan is to use boost log, but I am not sure if it is mature or it has been used seriously. It lacks some simple basic features such as display source code name and lines in log file, I've searched on line discussion, there are many suggestion to fix it in piece of code, but I could not get that work, difficult to use it may be overstated. Are there any good examples to display source program name and lines similar to asio socket examples on line? What is your opinion about boost log? Should I still pursue it? Thank you. - jhh

3 10

GSoC19
by Pranam Lashkari 10 Jan '19

10 Jan '19

Hello, Organization application date is going to start soon. I was trying to find our idea page for this year but couldn't find it. can anyone help!? Thank you, Pranam Lashkari

1 0

Requesting formal review for (Boost) LEAF
by Emil Dotchevski 10 Jan '19

10 Jan '19

LEAF is a small C++11 error handling library (the acronym stands for Low-latency Error Augmentation Framework). Features: - Header-only, NO dependencies. - No dynamic memory allocations. - Associate objects of arbitrary types with any failure — when it is initially reported or at a later time. - Compatible with std::error_code, errno and any other error handling API. - Use with or without exception handling. - Support for multi-thread programming. Official documentation: https://zajo.github.io/leaf. LEAF is designed for use in low-latency environments without exception handling, but it also works with exception handling; in that case it is a better, more optimal replacement for Boost Exception. This link can be helpful for refactoring existing Boost Exception code: https://zajo.github.io/leaf/#boost_exception.

5 9

async_read SEGFAULT
by hh h 09 Jan '19

09 Jan '19

I use one io_service in one process to run two servers A and B each has its own port, own context and SSL configuration to accept inbound connections. Although both A and B have boost::asio::deadline_timer, but I think there is only one thread is running: (gdb) info threads Id Target Id Frame * 1 Thread 0x7ffff7fe0bc0 (LWP 31204) "ssl_connection" 0x00007ffff4a690a3 in __epoll_wait_nocancel () at ../sysdeps/unix/syscall-template.S:84 The problem I got: - If I started only one server A, it worked just fine for both async_read and async_write. - If I started both servers A and B, even B was in idle, server A could sometime be crashed after receiving and responding just one message, then crashed at next async_read in the first second, it was more stable if it did not call async_write. SEGFAULT: Fault address=0x55b3700d00cf, #4 0x000055555557f98a in boost::asio::detail::task_io_service_operation::complete (this=0x55555584adc0, owner=..., ec=..., bytes_transferred=0) at /usr/include/boost/asio/detail/task_io_service_operation.hpp:38 #5 0x0000555555581f82 in boost::asio::detail::task_io_service::do_run_one ( this=0x555555814710, lock=..., this_thread=..., ec=...) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:372 #6 0x0000555555581ab4 in boost::asio::detail::task_io_service::run ( this=0x555555814710, ec=...) at /usr/include/boost/asio/detail/impl/task_io_service.ipp:149 #7 0x000055555558221f in boost::asio::io_service::run (this=0x7fffffffe150) at /usr/include/boost/asio/impl/io_service.ipp:59 It seems that async_write and async_read messed up, but that problem was intermittent, especially when the server A passed first second, it could be running for hours for doing consequent many async_read and async_write simultaneously. It was only one thread, what could cause that problem? Thank you.

2 11

b2 --exec-prefix=...
by Peter Dimov 09 Jan '19

09 Jan '19

Our "b2 --help" documentation says --exec-prefix=<EPREFIX> Install architecture dependent files here. Default: <PREFIX> --libdir=<LIBDIR> Install library files here. Default: <EPREFIX>/lib and bootstrap.sh also supports --exec-prefix and when given, records it in project-config.jam. But it doesn't work and has never worked. Only --prefix is honored, --exec-prefix is simply ignored. I think that we should bring the documentation and the actual behavior in sync, either by making --exec-prefix work as documented, or removing it from the documentation. Which one should we do? Comments?

5 4

Boost wiki - revised Boost guidance for authors on Warnings - RFC
by Paul A. Bristow 08 Jan '19

08 Jan '19

As promised at the end of a long (hijacked!) thread on 'Warnings' http://boost.2283326.n4.nabble.com/Current-Guidance-on-Compiler-Warnings-td… starting from a query by Brian Kuhl of Wind River on Boost's policy on compiler warnings, I have spent some time revising the previous guidance document on Trac that I edited many years ago. This was a long and tedious task as Markdown, as most conveniently used on Github, is rather different from the mark-up language on Trac, leaving me slightly in fumble mode :-( I have made some updates en passant, but there is still much to do updating for the much improved granularity of warning suppression and perhaps more about other code improvement tools like Lint, UBSan. The overall structure leaves a lot to be desired, but I don't want to put any more work into this without some encouragement that it will prove useful. I have posted the result of my efforts on https://github.com/boostorg/boost/wiki/Guidelines:-Warnings and I am as promised I am starting this new thread on warning for your comments, corrections, condemnations etc. HTH Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

3 2