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

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

[container] moving a pre-built vector into a flat_set
by Sam Kellett 12 Mar '17

12 Mar '17

a common problem i encounter is that i have two stage's w/r/t to a large collection of data: building and querying. vector is obviously the king of building. flat_set is the king of querying. so what i often tend to do is build up a very large vector, sort it then create a flat_set using the flat_set(ordered_unique_t) constructor. however this still copies the entire vector into the flat_set, right? what i would like to be able to do is move the vector straight into the flat_set, something like: std::vector<T> data; flat_set data_set1(std::move(data)) // move vector in and sort it // or: std::sort(data.begin(), data.end()); // sort vector flat_set data_set2(ordered_unique_t, std::move(data)) // and move it in is this doable (am i just being blind?) or is there plans/interest for this?

8 19

[nowide] Library Updates
by Artyom Beilis 04 Mar '17

04 Mar '17

Hello, Disclaimer: --------------- I recently discovered that virtually all e-mails sent from Yahoo account to any mailing lists go to user's spam due to recent Yahoo's DMARC policy. So I'm sending some important stuff from GMail account that almost certainly was missed: What is Boost.Nowide: -------------------------------- Boost.Nowide is a library that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. It was inspiration and inspired by http://utf8everywhere.org/ development ideas and policy. Some updates regarding Boost.Nowide ------------------------------- 1. Library moved to github and its format is converted to modular boost layout: https://github.com/artyom-beilis/nowide 2. Fixed unsupported std::ios::ate flag by boost::nowide::fstream 3. Added some C++11 interfaces to boost::nowide::fstream 4. Added integration functionality with boost::filesystem: https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/in… Note: that the links to the source code on review schedule aren't relevant, it should be: - Code: https://github.com/artyom-beilis/nowide - Documentation: http://cppcms.com/files/nowide/html/ Also the library is still looking for review manager. Artyom Beilis P.S.: I'm sorry if you are getting this as "duplicate"

2 1

[config] RFC PR 82
by Domagoj Saric 01 Aug '16

01 Aug '16

Hi everyone, I am finally getting back to (trying to) contributing some of my personal projects to Boost. For two of those, Err (https://github.com/psiha/err) and especially Functonoid (a C++11 generalization and rewrite of my previous Boost.Function related work) I need some lower level codegen and/or optimiser control functionality (i.e. portable macros wrapping toolset specific attributes and pragmas) that I've added to my personal fork of Boost.Config and which I've now submitted in the subject PR (https://github.com/boostorg/config/pull/82). I don't expect this PR to be accepted as is/'just like that' so I'm opening this thread where we can discuss which of those changes/macros are welcome, which need more work and which, for some reason, should not be part of Boost.Config (and which, in turn then, I have to move to some 'internal implementation headers' in libraries that will need them). To avoid 'spamming' (and save time;) I'll skip the explanation of the individual macros as I expect them to mostly be self-explanatory (if not from their name then from the minimal Boost.Config documentation additions that are part of th PR). ps. I'll be on the (off) road for the next three weeks so I don't know when I'll be able to respond until I get back... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

8 31

[Fit] pipable order of the arguments
by Vicente J. Botet Escriba 05 Mar '16

05 Mar '16

Hi, I would like to know what other think about the order of the pipe (See this issue https://github.com/pfultz2/Fit/issues/5). What would be the expected meaning of auto r1 =1 | pipable(f)(2); f(1,2) or f(2,1)? What would be the expected meaning of auto f2 = partial(f)(2); auto r1 =1 | pipable(f2); f(1,2) or f(2,1)? As the operator| has left-to-right associativity, we can not do auto x = 1 | 2 | pipable(f); We would need a way to pack the parameters auto x = forward_as_tuple(1, 2) | pipable(f); but this wouldn't compile as f has two parameters. or use parenthesis auto x = 1 | (2 | pipable(f)); and the result will be f(2, 1). Any ideas? Best, Vicente Vicente

1 1

[MSM] Is there any interest in C++14 Boost.MSM-eUML like library which compiles up to 60x quicker whilst being a slightly faster too?
by Krzysztof Jusiak 18 Feb '16

18 Feb '16

Dear Boosters, I have recently released 1.0.0 version of experimental C++14 Boost.MSM-lite. Your scalable C++14 header only eUML-like meta state machine library with no dependencies, which outperform Boost.MSM - eUML in: - faster compilation times - up to 60x times faster! - smaller executable size - up to 15x smaller - slightly better performance - smaller memory usage - short error messages Check it out yourself online! http://boost-experimental.github.io/msm-lite/examples/index.html#hello-world Performance Results: http://boost-experimental.github.io/msm-lite/overview/index.html#performance Source code: https://github.com/boost-experimental/msm-lite Documentation: http://boost-experimental.github.io/msm-lite Any feedback is more than welcome! Cheers, Kris

7 58

Boost.Operators issue: polluting namespace of caller through argument-dependent lookup
by John M. Dlugosz 17 Feb '16

17 Feb '16

Here's the problem I ran into http://stackoverflow.com/questions/34449254/how-is-argument-dependent-looku… |usingstd::tr1::shared_ptr; ||usingstd::tr1::make_shared;| |shared_ptr<Dog>Gamma::knockout (constHotel&target){Eggsoftboiled (target.ID);softboiled.sequence ^=0x40000000;returnmake_shared<Dog>(softboiled,target.kin,Frank::myself());} | The arguments to the constructor passed through make_shared are of types |Able::Bravo::Charlie::Egg&,constuint32_t&,constFrank&| The use of make_shared is finding boost::make_shared as well as std::make_shared. The program doesn't use boost::shared_ptr and shouldn't need to know about it. It turns out that Frank is derived privately from boost::totally_ordered1 (and and Egg from boost::totally ordered). Some Boost header that's being used in this translation unit just happens to pull in Boost's shared_ptr stuff. It ends up effectively polluting the namespace of possible calls involving these types, thanks to argument-dependent lookup. Furthermore, which Boost headers include which will change from version to version. I have this problem show up much more in Boost 1.60 than I have in Boost 1.59. There is no easy way around it beyond qualifying the call make_shared, and I specifically want to avoid that so I don't litter the program with tr1's (this varies by compiler and version as to whether tr1 is required, prohibited, or optional, so I want it in one place.) I believe the proper thing to do, which is a very simple fix actually, is to define the mix-in classes like totally_ordered (and other things from Boost.Operators in particular) in a unique inner namespace, and then make aliases in the boost namespace where they are published as being found. namespace boost { *namespace inner_name_1 { * template<typename T, Typename U> partially_ordered { ⋯ }; // the entire guts of Boost.Operators can go here, I think. *} // end of inner isolating namespace** ** ** using inner_name_1::partially_ordered;* // etc. } This inner isolation technique should be SOP for any classes that are meant to be inherited from by user (non-Boost library) code. It would not hurt to also isolate classes that match the names of std library code, in general! This would, in general, prevent the libraries from interfering with each other and surprises popping up when using std components and pulling in Boost headers. —John ||

4 12

Re: [boost] expected/result/etc
by Emil Dotchevski 13 Feb '16

13 Feb '16

On Wed, Jan 27, 2016 at 10:49 PM, Michael Marcin <mike.marcin(a)gmail.com> wrote: > So looking a few of these libraries/proposals I have a few things I'm > interested in. > > - Is it at least as good as a simple hand-rolled solution? > - Can you transport error codes through layers without knowing specifics > of an error? > > For the second Niall's outcome/result handles very well I think. > std::error_code and std::exception_ptr transport is good enough for almost > any reasonable type agnostic error transport. > Have you considered using Boost Exception? It lets you add arbitrary data to exception objects, even after they have been thrown, regardless of their type -- see http://www.boost.org/doc/libs/release/libs/exception/doc/error_info.html. The general idea is to adopt a strategy where the exception objects are augmented with any, even platform-specific relevant data, which then the catch site can analyze to choose the correct handling. Cheers, Emil

9 69

[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