- Boost - lists.boost.org

Interprocess mutex & condition variable at process termination
by Phil Endecott 18 Feb '17

18 Feb '17

Dear Experts, I've just been surprised by the behaviour of the interprocess mutex and condition variable on abnormal process termination, i.e. they are not automatically released. Google tells me that I'm not the first to be surprised by this; there have been previous posts here, stack overflow questions etc. One often-valid observation is that if a process crashes - or otherwise terminates without executing its destructors - while it holds a lock on a shared data structure then the data is probably now corrupt, so unlocking the mutex that protects it is not very useful. I think there is an important case where that does not apply - when the process that crashes is only reading the shared data. In my case, I had written a "monitor" utility that loops forever, waiting on a shared condition, taking the corresponding mutex, and then dumping the shared data to stdout. I had been running this and stopping it by pressing ctrl-C and it had not occurred to me that this might not work as I expected. My attempt at debugging using this utility was making my problems worse, not better! Modifying this code to run destructors on ctrl-C is non-trivial. I am aware that the SysV shared semaphore is able to undo on process termination (see SEM_UNDO in man semop), and I had assumed that Boost.Interprocess was using this or something like it. I now see that it is using pthreads, which I didn't even realise could work between processes, and I don't think this API has any way to specify process termination behaviour. Anyway, I'd like to suggest that the interprocess docs should make some mention of the behaviour of the synchronisation primitives on process termination, e.g. somewhere near the beginning of http://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/synchronization_… I may now try to implement some primitives that use semop() and unlock automatically. I haven't yet looked at what's involved to implement a condition variable on top of a semaphore, so I may not get very far! Has anyone else ever tried this? Also, I note that Interprocess is using "old style" times, not std::chrono like the std::mutex/condition do. Are there any plans to update this? Thanks, Phil.

5 6

Missing link for Boost.Algorithm documentation
by Alexander Zaitsev 17 Feb '17

17 Feb '17

3 2

Scheduled Outage : Web sites / Trac
by Michael Caisse 17 Feb '17

17 Feb '17

We are planning the final move of services from IU this week. Expect service outages for all web sites including Trac on 17-February-2017 between 16:00 UTC - 00:00 UTC. The mail lists will continue to operate during this time; however, all other sub-domains for boost.org will be affected. Sync'ing bandwidth with IU has been low recently and has caused us to increase the outage window. We will notify these lists when services are available again. Thank you for your patience during the move. -- Michael Caisse Ciere Consulting ciere.com

1 1

Boost.Python sandox or multiple interpreters
by David Bellot 17 Feb '17

17 Feb '17

Hi, I'm using Boost.Python to load and use plugins in Python. Each plugin can define a few functions which are are pre-determined, so that my C++ software knows what to call. However, the mistake I've made was to think that the Python interpreter could be initialized many times, so that each plugins was existing and running into a separate interpreter. It's of course not the case and therefore, each time I load a new plugin, its functions overwrite the functions of the same name from the previous plugin (the one which was loaded just before), and so on. Is there a possibility to either : - have as many independent Python interpreters at the same time ? - or encapsulate each plugin in an independent "environment" ? - or any other solution which would elegantly solve this problem ? :-D Thanks for your help, David

3 6

[trac] how close trac for bug reports
by Oliver Kowalke 17 Feb '17

17 Feb '17

Hello, how can I close boost trac for a specific library? Users should report issues only at github. ty, Oliver

1 0

[teeks] Missing winerror.h for MSVC-9
by Andrey Semashev 17 Feb '17

17 Feb '17

Hi, I see lots of tests failing on teeks99-09b-win2012R2-64on64, MSVC-9.0 because winerror.h is missing. Here's an example: http://www.boost.org/development/tests/develop/developer/output/teeks99-09b… I can see that the file is present in Windows SDK 6.0A, which is supposed to be used with this compiler. The tests are passing on my machine. Could this be a tester configuration issue? Also, all MSVC-15 tests are failing on teeks99-09o-win2012R2-64on64 with the error of 'cl' not being found.

3 14

Functional programming in boost
by Abhishek Kumar 16 Feb '17

16 Feb '17

Hello I am a Computer Science senior from India. I have been doing functional programming for quite some time and have also used C++ for different projects. I recently came across BOOST libraries for supporting functional programming in C++. I want to contribute to one of the BOOST libraries maybe PHOENIX. Are there any open issues or plans in this direction, in which I might help? Thanks Abhishek Kumar

1 0

[release] 1.64.0 deadline for new libraries approaching
by Rene Rivera 16 Feb '17

16 Feb '17

One week from today master will close for commits of new libraries. Thanks, -- The Boost Release Team -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[safe_numerics] Review coming in March
by Andrzej Krzemienski 15 Feb '17

15 Feb '17

Hi Everyone, This is to inform you ahead of time that the formal review of Robert Ramey's Safe Numerics library will be held in about two weeks: March 2 - March 11. Boost Numerics is a set of drop-in replacements for the built-in integer types, which make the guarantee that the results of operations are either correct according to the rules of integer arithmetic or report a diagnosable error (rather than offering modulo arithmetic results, or resulting in undefined behavior, or returning incorrect results as in the case of signed vs. unsigned comparisons). The library can be found on GitHub: https://github.com/robertramey/safe_numerics/ Online docs: http://htmlpreview.github.io/?https://github.com/robertramey/safe_numerics/… Even before the formal review starts, you can provide your review on Boost Library Incubator: http://blincubator.com/reviews/?library_id=426 It will also be included in the final verdict. I will be making the official announcement on March 2. Andrzej Krzemienski, review manager.

1 0

Is there any interest in non-owning pointer-like types?
by Joseph Thomson 14 Feb '17

14 Feb '17

For some time, I have been developing a pair of non-owning pointer-like types that I am currently calling `observer_ptr` and `observer`. I had planned to propose their addition to the C++ standard library, but I have been informed by the author of the original `observer_ptr` proposal <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4282.pdf> that the ISO C++ committee has rejected his proposal and made clear that it feels there is no place in the standard library for such types, believing that this role is filled to a satisfactory degree by regular pointers. I wholeheartedly disagree with this assessment, so I am bringing my proposal here instead. The `observer_ptr<T>` class template is a pointer-like type that does not do any resource management, and is intended to be used in place of `T*` wherever `T*` is used as a non-owning reference to an object of type `T`. `observer_ptr<T>` has three main advantages over `T*`: 1. `T&` is implicitly convertible to `observer_ptr<T>` which, unlike `T*`, makes it *type-safe*. `T*` can represent things that are not conceptually objects of type `T`: arrays, strings, iterators. No implicit conversion from `T*` means that these things cannot implicitly convert to `observer_ptr<T>`. Pointers aren't even required to point to valid objects (e.g. a past-the-end iterator). Conversely, in a well-formed program, `T&` is *always* a valid object of type `T`. 2. `observer_ptr<T>` documents its purpose. This is really a side-effect of it being type-safe (a type should have a single, specific purpose), but it's worth mentioning. Conversely, when you see `T*`, it may not be immediately obvious what it represents. 3. `observer_ptr<T>` has a minimal interface, which makes it harder to misuse than `T*`; for example, `observer_ptr<T>` has no pointer arithmetic operators, no array subscript operator, no conversion to `void*`. The `observer<T>` class template is a counterpart to `observer_ptr<T>` that has *no null state*; it cannot be default constructed, constructed from `nullptr_t` or constructed from `T*`, and it does not contextually convert to `bool`. The only way to create an `observer<T>` is from `T&`. This allows a "not null" precondition to be enforced at compile-time, rather than having to worry about pointers being null at run-time. Just to give you an idea of the current syntax, here is a simple tree node type (where the nodes do not own their children) implemented using `observer_ptr` and `observer`: class node { public: node() = default; node(node const&) = delete; node& operator=(node const&) = delete; node(node&&) = delete; node& operator=(node&&) = delete; void set_parent(observer_ptr<node> new_parent) { if (parent) parent->remove_child(*this); parent = new_parent; if (parent) parent->add_child(*this); } observer_ptr<node> get_parent() const { return parent; } size_t get_child_count() const { return children.size(); } observer<node> get_child(size_t index) const { return children[index]; } private: observer_ptr<node> parent; vector<observer<node>> children; void add_child(observer<node> child) { children.push_back(child); } void remove_child(observer<node> child) { children.erase(find(begin(children), end(children), child)); } }; And a contrived usage example: node a, b, c; b.set_parent(a); // conversion from `T&` c.set_parent(b); observer_ptr<node> x = c.get_parent(); if (x) // conversion to `bool` { observer<node> y = x->get_child(0); assert(y == c); // comparison with `T&` y->set_parent(a); b.set_parent(y); // conversion from `observer<T>` to `observer_ptr<T>` } A project with a working implementation <https://github.com/hpesoj/cpp-observer/blob/master/api/observer.hpp> and full test suite <https://github.com/hpesoj/cpp-observer/blob/master/tests/observer_tests.cpp> can be found here <https://github.com/hpesoj/cpp-observer>. Regards, Joseph

16 35