January 2016 - Boost - lists.preview.boost.org

[regression] Winapi submodule tests missing
by Andrey Semashev 13 Feb '16

13 Feb '16

Hi, The winapi submodule tests are missing from the test matrix, although the status/Jamfile.v2 lists it. This is both on develop and master. Is there something I should do to make the tests appear?

2 5

[smart_ptr] Interest in the missing smart pointer (that can target the stack)
by Noah 09 Feb '16

09 Feb '16

Hi all, I'm new here. Here goes: I propose a new smart pointer called, say "registered_ptr", that behaves just like a native C++ pointer, except that its value is (automatically) set to null_ptr when the target object is destroyed. This kind of smart pointer already exists and is being used in the form of, for example, QPointer and Chromium's WeakPtr (http://doc.qt.io/qt-5/qpointer.html and https://code.google.com/p/chromium/codesearch/#chromium/src/base/memory/wea…) although those implementations only apply to a specific set of object types. There's also std::experimental::observer_ptr (http://en.cppreference.com/w/cpp/experimental/observer_ptr) which seems to be trying to serve a similar purpose, but with none of the functionality. This might be as far as you need to read to decide if you think it's a good idea or not. The rest of this (kind of long) post addresses some of the details and motivation. It's instructive to compare this "registered_ptr" with (std::)shared_ptr. Both have a (modest) performance cost, although registered_ptr's performance cost is significantly lower, as will be discussed later. Both can have a significant "code safety" benefit when used for that purpose - i.e. reduce or eliminate the possibility of invalid access of an object that has already been destroyed. And both have a functional purpose other than safety or convenience (or just being a regular pointer). That functional purpose is to deal with situations when it is not easy to predict in advance (i.e. at compile time) when an object will be referenced (and stop being referenced). shared_ptr deals with these type of situations by ensuring that the object remains "alive" for as long as there are any (owning) references to the object. This assumes that the object has no "curfew". But one can imagine situations where an object needs to be destroyed at or by a certain time or event. If the object is exclusively holding an in demand resource, or security lock for example. In these cases one might prefer that late attempted references to the object fail (safely) rather than have the object's destruction delayed. registered_ptrs might be more suitable for these situations. So from this comparison it's hard to argue for the inclusion of shared_ptr and the omission of registered_ptr in the library. registered_ptr can be thought of as a kind of "non-intrusive" counterpart to shared_ptr. "But wait", you say, "shared_ptr already has a non-intrusive counterpart. Namely weak_ptr." Yes, but the difference between weak_ptr and registered_ptr is that registered_ptr is independent, not just an appendage of shared_ptr. And registered_ptr can point to stack allocated objects (just like native C++ pointers can), but at the cost of "thread safety". Referencing an object on another (asynchronous) thread's stack is inherently not safe, right? Some may be concerned with this lack of thread safety - I am not, I don't think we should be encouraging casual asynchronous object sharing - but the performance dividend of getting to put the target object on the stack rather than the heap more than makes up for it in my opinion. So I've actually already had cause to implement, and use, a version of this "registered_ptr" (I actually called it "TRegisteredPointer"), and in practice it works great. But there are, arguably, a couple of issues. Besides the thread safety (non-)issue, my implementation can only target types that can act as base classes. By default most classes can act as a base class, but native types like int, bool, etc. cannot. In my case, this is not a big issue because TRegisteredPointer is actually part of a small library that includes (safer) substitutes for int, bool and size_t that can act as base classes. The good thing is that it does seem to serve its purpose of not only being safe, but also faster than shared_ptr. Much faster when targeting stack objects as one would expect, but also faster when targeting heap objects according to my simple benchmarks (msvc2013 - Windows 7 - Haswell). My implementation can be found here: https://github.com/duneroadrunner/SaferCPlusPlus. It's in the file called "mseregistered.h". Examples of it in action can be found in the file called "msetl_example.cpp", near the end. No decent documentation yet, but the examples are commented and it should be clear what's going on. So far I've posited that the argument for registered_ptr is at least as good as the argument for shared_ptr. But let me make a further argument for why I think it's particularly important to include registered_ptr. First, let me make an argument for "safe" pointers in general. By safe pointers, I mean pointers that have zero chance of participating in a dereference to invalid memory. This will usually imply that the safe pointer will do a runtime check and throw an exception if an invalid dereference is attempted. Now, I subscribe to the C++ "trust the programmer" philosophy, so I agree that programers should have the option of avoiding these runtime checks. But security (and by extension, language safety) is so important these days that programmers should also have the option of having these runtime checks when desired. So I'm suggesting that all the smart pointers (shared_ptr, unique_ptr, etc.) come in "safe" versions as well. There is already some precedent for safe and unsafe options. For example, std::vector<> provides both the "unsafe" [] operator and the "safe" at() function. And ultimately it needs to be properly measured, but I would think that the performance cost of this kind of runtime check should be quite modest. There is plenty of opportunity for optimizing compilers to strip them out when not needed and of course these sorts of runtime checks are a favorite food of branch predictors in modern cpus right? I haven't put a lot of effort into this, but my simple benchmarks show checked dereferences being only modestly slower than unchecked dereferences. (The "msetl_example.cpp" file includes some simple benchmarks.) So why does this make registered_ptr so important? Because the "safe" version of registered_ptr would be the safe pointer with the lowest performance cost. Perhaps low enough for the safety benefits to be widely considered worth the cost. Of course the ideal would be smart pointers that could distinguish between stack allocated objects and heap allocated objects. Unfortunately, as far as I know, (standard) C++ doesn't seem to give us that facility. If we can't have those, I think we need a smart pointer that can at least accommodate stack allocated objects. Right? Noah

10 45

expected/result/etc
by Michael Marcin 07 Feb '16

07 Feb '16

Some months ago there was a lot of discussion regarding Rust style return values for non-exceptional error handling. Did anything ever come of this? Is there a useable library? Apologies if I missed an announcement (I've been away for a bit).

7 31

Is there interest in Computable Calculus?
by Alexander Lauser 05 Feb '16

05 Feb '16

Hi, An arithmetic operation produces a new function using the functions in the operands and some simple expression manipulations. if I gather it right, then what you propose is basically a Computer Algebra System (i.e., a system for manipulating reals by symbolic expressions). What specifically would the goal of the library be? Best, Alex

2 5

updated version of safe integer library
by Robert Ramey 05 Feb '16

05 Feb '16

I've updated my safe integer library. Pointers to the most recent documentation and code can be found at www.blincubator.com . Or one can use documentation http://htmlpreview.github.io/?https://github.com/robertramey/safe_numerics/… repository: https://github.com/robertramey/safe_numerics I've resolved added more tests. added more examples and explanation of them added facilities to enforce a guarantee of zero runtime penalty added new section to the documentation of the above added more documentation regarding the library implementation. and other stuff. There is still a little more to do. But there is nothing that I know about that would prevent users from using this library right now to implement guaranteed correct integer arithmetic in their applications. Of course I'm interested any feedback and/or observations anyone want's to offer. Robert Ramey

5 13

Transferring the boost-qvm github repository to Boost
by Emil Dotchevski 03 Feb '16

03 Feb '16

Hello, Ron Garcia, one of the Boost Review Wizards, has directed me to ask the mailing list about the exact procedure for transferring the boost-qvm github repo to Boost. I believe I need to have some kind of permissions to be able to use the built-in github repo transferring mechanism. Thanks, Emil

2 1

Adding Metaparse to the master branch
by Abel Sinkovics 31 Jan '16

31 Jan '16

Hi, I've created a pull request to add the Metaparse tests to the Boost regression tests (#113) on the develop branch (Metaparse itself is already part of the develop branch, only the regression test integration is missing). I would like Metaparse to be added to the master branch as well. I have created pull request #112 for that. Please let me know what else is needed. Thanks, Abel

4 7

[tools/GSoC] static code analysis?
by Oliver Kowalke 30 Jan '16

30 Jan '16

Hi, would it be possible to provide a boost-tool or maybe a boost-GSoc project that enables static code analysis for boost developers? clang-tidy ( http://clang.llvm.org/extra/clang-tidy/) could be used for this purpose. Oliver

4 6

Re: [boost] [coroutine] x86 msvc11 stack corruption
by AVZ 29 Jan '16

29 Jan '16

Just want to share workaround which work for our company. (Fiber fix was not acceptable for that application) Debugging differences in make_fcontext between 1.53 vs 1.57, I found that in 1.53 context area is cleanned with 0, but not in 1.57. So we added explicit clear after line 100 in make_x86_64_ms_pe_masm.asm: sub rax, 0128h * ; memset context area pxor xmm0, xmm0 movaps [rax+008h], xmm0 movaps [rax+018h], xmm0 movaps [rax+028h], xmm0 movaps [rax+038h], xmm0 movaps [rax+048h], xmm0 movaps [rax+058h], xmm0 movaps [rax+068h], xmm0 movaps [rax+078h], xmm0 movaps [rax+088h], xmm0 movaps [rax+098h], xmm0 movaps [rax+0a8h], xmm0 movaps [rax+0b8h], xmm0 movaps [rax+0c8h], xmm0 movaps [rax+0d8h], xmm0 movaps [rax+0e8h], xmm0 movaps [rax+0f8h], xmm0 movaps [rax+108h], xmm0 movaps [rax+118h], xmm0 * ; third arg of make_fcontext() == address of context-function mov [rax+0118h], r8 With that we are getting same behavior as 1.53 - no crash on DLL load. Thanks, AZ -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Iterator] [PR] Fix for documentation #8010
by Nathan Wilson 29 Jan '16

29 Jan '16

Hi, As a followup to my inquiry about maintaining the Iterator Library about a month back, I wanted to create PR for a simple documentation fix. So, here it is: https://github.com/boostorg/iterator/pull/21 Please let me know if there are any thoughts and/or if I'm doing something incorrectly. Thanks! Nate

2 2