- Boost - lists.preview.boost.org

Re: [boost] [Block Pointer] Benchmarks
by Glen Fernandes 15 Mar '16

15 Mar '16

On Sun, Mar 13, 2016 at 1:02 PM, Phil Bouchard wrote: > Thanks for your help. > > So block_ptr<> wouldn't be a drop-in replacement for shared_ptr<> but an > add-on for: > - complex containers, > - neural networks, > - C# / Java / Javascript engines, > - etc. > No problem. Also renaming the thread to reflect the current benchmarks (since it doesn't appear that block_ptr is faster than shared_ptr where creation is involved). 1. Gathering these benchmarks is always useful, even if block_ptr was not designed to be a drop-in replacement for share_ptr. So you had the right idea, even if the execution needed some work. It's important to get the execution correct, though, otherwise the results are not meaningful - which is where I (and I believe Rob, also) was trying to steer you. 2. Looking at the numbers you obtained after modifying my benchmark example, they are close enough that at least you could say "Using block_ptr over shared_ptr won't be a significant performance loss": > unique_ptr (new): 47.7686 > unique_ptr (make_unique): 46.8545 > shared_ptr (new): 77.8261 > shared_ptr (make_shared): 50.8072 > shared_ptr (allocate_shared_noinit): 33.021 > block_ptr (new): 69.6554 3. There are more benchmarks beyond just creation (though creation is likely the most meaningfully expensive one). Copying overhead might be one: I haven't looked at what is involved in copying a block_ptr, but some work happens when you copy a shared_ptr. 4. shared_ptr by way of allocate_shared allows creation to not involve 'new' expressions, or even a call to '::operator new(std::size_t)' at all. i.e. For those C++ projects that have a requirement for all dynamic allocation in their project to involve some stateful custom allocator instances of some stateful custom allocator type, they can still use shared_ptr (with allocate_shared). Is this possible with block_ptr? I hope to take a look at the block_ptr motivation, design, and implementation when I have some time next week. The title of the thread caught my attention; "X is 600% faster than Y" always has a high excitement potential. Glen

8 16

[Block Pointer] Update
by Phil Bouchard 14 Mar '16

14 Mar '16

Hi, - So I've restructured all the code in the correct namespaces boost::smart_ptr & boost::smart_ptr::detail: https://github.com/philippeb8/block_ptr/tree/master/include/boost/smart_ptr - I am now using another smart pointer to refer to proxies because it is safer but the code is 15% slower than without it (now ~= shared_ptr<>): make: auto_ptr: 26211292 ns shared_ptr: 27291607 ns block_ptr: 61097868 ns new: auto_ptr: 23240569 ns shared_ptr: 48016207 ns block_ptr: 55554121 ns - Because of the removal of the proxy optimization there is a new caveat; if you assign an rvalue (temporary pointer on the stack) to a pointer on the heap (opposite of normal heap object assigned to stack pointer) then there the behavior will be undefined. I am looking to fix it or throw an exception but for now it's better not to use rvalues when assigning to pointer living on the heap as such: https://github.com/philippeb8/block_ptr/blob/master/example/t100_test1.cpp#… Regards, -Phil

2 13

[Fit] formal review ends today, 13th March.
by Vicente J. Botet Escriba 14 Mar '16

14 Mar '16

Hi, The formal review of Paul Fultz II's Fit library ends today, 13th March. If you had not time to do the review and you plan to do it, please let us know so that we see if the review can be extended. Up to now we had 3 formal review (2 for conditional acceptance and 1 against, not now). I have not done a review myself, but I have created a lot of issues on Github. Best regards, Vicente Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both `constexpr` initialization and `constexpr` evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: * Function Adaptors and Decorators: These enhance functions with additional capability. * Functions: These return functions that achieve a specific purpose. * Utilities: These are general utilities that are useful when defining or using functions Fit has been tested on gcc 4.6-4.9, clang 3.4-3.7, and Visual Studio 2015. For more information see: Github:https://github.com/pfultz2/Fit/tree/boost Documentation:http://pfultz2.github.io/Fit/doc/html/ We encourage your participation in this review. At a minimum, kindly state: - Whether you believe the library should be accepted into Boost * Conditions for acceptance - Your name - Your knowledge of the problem domain. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design * Implementation * Documentation * Tests * Usefulness - Did you attempt to use the library? If so: * Which compiler(s) * What was the experience? Any problems? - How much effort did you put into your evaluation of the review? More information about the review process can be found here:http://www.boost.org/community/reviews.html We await your feedback!

4 6

[Fit] Review
by Zach Laine 13 Mar '16

13 Mar '16

- Whether you believe the library should be accepted into Boost Yes, conditionally. * Conditions for acceptance I think the documentation and naming issues I raise below, and those filed on GitHub by me and others should be addressed before acceptance. Also, the ADL issues that Steven Watanabe alluded to previously need to be fixed. After that, I think it should be re-submitted. - Your name Zach Laine - Your knowledge of the problem domain. I do generic programming regularly, and have done for years. You are strongly encouraged to also provide additional information: - What is your evaluation of the library's: * Design I think it's good. I particularly like the fact that it attempts to keep everything constexpr- and SFINAE-friendly wherever possible. I *really* like reveal() and failure(). Too few TMP-heavy libraries pay attention to providing good error messages. I have no problem with the constness requirements on Callables used throughout Fit, as was discussed previously. I even consider this a feature, allowing me to detect non-const Callables, which are almost always an error on my part. This is especially true since std::ref() and mutable_() let me explicitly choose how to handle mutable Callables, in a way that is also explicit at the call site. There are a number of adaptors that I find have obscure names: by() is a projection; why not call it project()? compress() is defined in terms of "fold", with a link to the Wikipedia page for same; why not call it foldl()? Similarly, reverse_compress() should be foldr(). flow() is a super obscure name! Why is this not reverse_compose() or similar? indirect() could more easily be understood if it were called deref() or dereference(). I don't feel as strongly about partial(), but I think it might be clearer if it were called partial_apply() or curry(). conditional() should be called invoke_first(), call_first_of(), or similar. I find it too easy to confuse with if_(). * Implementation I only briefly looked at the implementation, and only a few adaptors at that. What I saw did not leave me any concerns in particular. However, I *am* concerned by Steven Watanabe's claim that the library is ADL-unsafe. He did not state exactly why that I could tell, but this needs to be addressed if so. * Documentation The Quick Start section is good at showing a compelling motivating case for using the library. The result at the end of the section looks like a very good start on a "Scrap Your Boilerplate" solution for simple, dump-style printing. It's relatively easy to read and write. The documentation is what needs the most work, from what I've seen. The Quick Start is quite nice, but then there are some things that are underexplained in the subsequent Overview and Basic Concepts sections. For instance, why are these macros used everywhere and what do they do? They should be used for the first time after showing what the expanded code looks like. This will justify their use for those users that want them, and show those that don't what they can write instead. Others have written during the review that they don't understand why this library is useful. I think this is simply a documentation failure. I find the printing example from the Quick Start compelling, but perhaps Paul could show how it would have to be done if hand-written (even if only partially). Also, Paul has told me offline that there are a small number of primitive operations on which everything else is built (pack, unpack, and apply, IIRC). Perhaps show how those can be used to implement the other adapters, and how hard they are to write yourself. Showing how at least some of the library can be used as fundamental building blocks would go a long way. Some specifics. I have read the online docs before, and I put several bugs into the GitHub page for what I consider insufficient examples or explanations. Some new points, though: I think alias() is in bad need of a motivating example. I don't understand the distinction between lazy() and protect() just from the descriptions. In particular, this is what protect()'s docs say: '' The protect function adaptor can be used to make a bind expression be treated as a normal function instead. Both bind and lazy eargerly evaluates nested bind expressions. The protect adaptor masks the type so bind or lazy no longer recognizes the function as bind expression and evaluates it. '' I don't know what "masks the type" means here. This really needs an example. * Tests I did not run the tests, and just sort of spot-checked them. They seem a bit thin. In particular, one of the ones I looked at was conditional(). This one seems like it is needs more coverage, including thorny ones that must be kept working when maintenance occurs. There are probably others adapters that need similar treatment. Also, consider this -- Steven pointed out this as a failure case: boost::fit::conditional(identity(), identity())(0); and Paul says that it is supposed to fail, and that this failure is a feature, not a bug. If so, a minimal use like this that fails to compile needs to be added as a fail-compile test (and of course this intention should be documented). * Usefulness I think the library is very useful. There seem to be some things in there that use of which might be deemed a bit clever (not the good kind), like infix(), but then there are things like conditional() that I can see being *extremely* useful. - Did you attempt to use the library? If so: Yes. * Which compiler(s) Clang 3.6 * What was the experience? Any problems? I found I could gin up quick uses of things like conditional() (the most interesting adaptor for my purposes) in a short period of time. It was quite straightforward. - How much effort did you put into your evaluation of the review? About 5 or 6 hours. Zach

9 23

Alternative names to Boost.Fit
by paul Fultz 13 Mar '16

13 Mar '16

Hello All, Boost.Fit is a function utility library, however, the name currently doesn't have anything with this. I originally chose the name because it started with F(for function) and it was short and sounded nice. However, there could be some names(or abbreviations) that more adequately describe the library. Here are some alternatives that are short: - Boost.FP - Boost.FPL - Boost.Fun - Boost.FN Of course, I prefer the Boost.FN name. Names like Boost.FP or Boost.FPL could imply that it provides full functional constructs whereas Boost.Fit does not and is mainly focused on functions. Either way, this is something reviewers could consider as they review the library as I am not strongly tied to the name Boost.Fit. Thanks, Paul

13 27

[Block Pointer] Up to 600% faster than Shared Pointer
by Phil Bouchard 13 Mar '16

13 Mar '16

- I made the proxy explicit. Now it can be used 3 different ways: 1) Clothesline style: block_proxy x; block_ptr<int> v = block_ptr<int>(x, new block<int>(11)); block_ptr<int> w = block_ptr<int>(x, new block<int>(12)); 2) Root style: proxy_ptr<char[9]> u = proxy_ptr<char[9]>(new block<char[9]>()); 3) Container style (very easy to write containers now): struct list : block_proxy { public: list() : root(*this) {} [...] private: block_ptr<node> root; }; - I removed the capacity to unify sets. Why? Because it's faster & cleaner without it. - If we use fastblock<>() then the speedup can go up to 600% compared to shared_ptr<>: new: auto_ptr: 23174753 ns shared_ptr: 49726615 ns block_ptr: 7812659 ns - Once again all the examples can be found here: https://github.com/philippeb8/block_ptr/tree/master/example - And the pointer itself here: https://github.com/philippeb8/block_ptr/blob/master/include/boost/smart_ptr… Regards, -Phil

3 18

32/64 library name conflict under Windows?
by Peter Dimov 12 Mar '16

12 Mar '16

I remember that we discussed this problem before: C:\Projects\boost-git\boost>b2 --with-system toolset=msvc-10.0 address-model=32,64 [...] error: Name clash for '<pstage\lib>libboost_system-vc100-mt-gd-1_61.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <address-model>32 error: - <address-model>64 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. but don't remember what we concluded. Will we support building both 32 and 64 bit libraries under Windows? At present if I want to have an IDE project that has both Win32 and x64 configurations I need to build the 32 bit libraries, move them out of stage/lib somewhere, then build the 64 bit libraries, then move them out of stage/lib to somewhere else, and set my library directories in the IDE accordingly. It would be much more convenient if 32/64 were encoded into the name, so that I can leave my library path to point at stage/lib and rely on autolink to choose the right .lib file automatically, like it works today for the other options (debug/release, static/dynamic runtime).

14 25

[Fit] Louis Dionne's formal review
by Louis Dionne 12 Mar '16

12 Mar '16

First of all, sorry for submitting my review so late. > - Whether you believe the library should be accepted into Boost Yes, conditionally. > - Your name Louis Dionne > - Your knowledge of the problem domain. Extensive. In fact, I have implemented something very similar to Fit in parallel to Paul, but in the Hana library. Hence, I understand what Fit can be useful for, and I know many of the challenges Paul must have faced in designing the library. > You are strongly encouraged to also provide additional information: > - What is your evaluation of the library's: > * Design Good. It is simple and quite lean, which is nice. However, - The issue about `capture`'s semantics (and `pack`'s semantics too) ought to be addressed. I created an issue for this: https://github.com/pfultz2/Fit/issues/141. - It would be nice to provide a master header: https://github.com/pfultz2/Fit/issues/143 - I am not sure that `alias` has its place as part of the public interface of the library. I have only looked at it quickly, but it seems to diverge pretty heavily from the purpose of the rest of the library. I know it's used to implement `fit::pack`, but is it necessary to make it part of the public interface? Zach Laine already opened a similar issue here: https://github.com/pfultz2/Fit/issues/95 - I'm not sure about `compress` and `reverse_compress`. I think `fold` and `reverse_fold` (or my favorite `fold_left` and `fold_right`) would be better suited. An issue was already filed by Vicente here: https://github.com/pfultz2/Fit/issues/62 > * Implementation I have not looked at the implementation intensively, but I have to say that the profusion of macros is a bit off-putting. That being said, it's probably difficult to do better while supporting archaic compilers such as GCC 4.6. Hats off to Paul on this one. Also, I think the `fit/detail/ref_tuple.hpp` is unused and should be removed. Finally, why do you use your own `move` function? Is it because it is not marked constexpr in pre-C++14? > * Documentation I submitted pull requests to fix typos, but these are not worth mentioning here. Comments that might be of interest for the purpose of this review were made in the form of GitHub issues: - https://github.com/pfultz2/Fit/issues/131 - https://github.com/pfultz2/Fit/issues/132 - https://github.com/pfultz2/Fit/issues/133 - https://github.com/pfultz2/Fit/issues/135 - https://github.com/pfultz2/Fit/issues/136 - https://github.com/pfultz2/Fit/issues/138 - https://github.com/pfultz2/Fit/issues/139 - https://github.com/pfultz2/Fit/issues/140 - https://github.com/pfultz2/Fit/issues/142 - https://github.com/pfultz2/Fit/issues/144 > * Tests I have looked quickly, and basically all the individual components seem to be tested. It's hard to evaluate the depth in which each component is tested, but it seems OK. Also, the fact that the library is tested on Travis CI on each commit is a blessing, and it makes me much more confident about its quality. > * Usefulness This, I think, is the biggest problem of the library. I personally know very well why the library is useful, but I can also understand that someone with a different background would not feel the same. In my view, the library is mostly useful as a replacement to shortcomings of lambdas in C++11/14. Not only this, but in large part yes. Indeed, let's say I have a function object `f`, and I'd like to get a function object that swaps the arguments and calls `f`. The obvious solution (simplified) is auto g = [f](auto x, auto y) { return f(y, x); }; In other words, the simplest way to express my intent is to use a lambda and to do exactly what I mean. Unfortunately, this has several limitations - The lambda above can't be constexpr - The lambda can't appear in an unevaluated context So I end up using `fit::flip`. In a different situation, I might want to capture many variables in a lambda, but moving them into the capture (not copying). So I write auto f = [x = std::move(x)...](auto const& param) { ... }; but unfortunately there's no way to capture a parameter pack by moving each of its elements in a lambda. So I resort to using `fit::capture`. Examples like this abound, and IMO these limitations are the main (but not the only) reason for using Fit. Actually, this is how I implemented a library similar to Fit inside Hana; I started by using lambdas everywhere and then I wanted to make everything constexpr, capturing by move and things like that. All of this is very useful, but I feel like the documentation completely misses the goal of explaining the problem solved by Fit (the problem I would use it for, at least). This failure of motivating its own existence is the main reason why I think Fit should be accepted conditionally. > - Did you attempt to use the library? If so: > * Which compiler(s) AppleClang 6.1.0.6020053 (shipped with Xcode 6.4) Clang 3.5, 3.6, 3.7 I used both the Makefile and the Ninja generators for CMake, and both worked. > * What was the experience? Any problems? Classic CMake setup, everything works well and the tests compile and run fast. No problem whatsoever, as expected. > - How much effort did you put into your evaluation of the review? A couple of hours for the formal review itself, but I have been looking at Fit's development for a while. Summary ------- Fit should be accepted conditionally and re-submitted for a mini-review before it can be accepted. My conditions are 1. Correctly justify the purpose of the library 2. Resolve the issues on `capture` and `pack`'s semantics I think all the other points I raised are important too, but they shouldn't refrain Fit from being accepted. I also trust that Paul would be willing to continue working on the issues that were raised during this review if Fit were to be accepted. Regards, Louis

4 5

Boost.ASIO SSL examples
by Umit Sami 11 Mar '16

11 Mar '16

Hi All, SSL examples in boost.asio is very limited and not that clear. How can I improve my knowledge of this great network/security library ? what are some of well known online websites and books I can read/buy to better write secure/encrypted client-server applications ? Thank you, U

2 1

[release] Need help to test new release archives.
by Rene Rivera 09 Mar '16

09 Mar '16

As part of my attempt to make the Boost release management less painful, for everyone, I've implemented building of the release archives in Travis-CI. As of yesterday archives of the "boost" super-project master branch are getting uploaded to the bintray.com service at < https://bintray.com/boostorg/snapshots/master/view>. There are still some kinks in how this works but it's automated enough at this point that it might serve the upcoming release needs. I would appreciate it if people download the archives available at the above link and test them out. In particular I'm looking to see if there's anything missing or generally incorrect. For reference the archives are named with the commit SHA that they correspond to. Thank you. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

6 16

Re: [boost] [Boost-users] [Fit] formal review starts today
by paul Fultz 09 Mar '16

09 Mar '16

>> >> >> >> Quick Start:Function Objects >> >> >> >> "We can make it behave like a regular function if we > construct >> the class >> >> as a global variable." >> >> >> >> What about a non-global >> >> >> >> sum_f sum = sum_f(); >> >> >> >> makes 'sum' not behave like a regular function other > than the >> fact that >> >> the variable 'sum' may eventually go out of scope ? >> >> >> > >> > In C++, a regular function is always global, there is no such >> thing as local >> > function(sans gcc extensions). >> >> My point is that the non-global 'sum' in my example above > behaves just >> as much like a regular function as your global 'sum'. You may > want to >> promote the idea of global function objects but I think that this is >> personally a bad idea. IMO global variables of any kind are to be >> avoided. >> >> It is quite common in several modern C++ libraries to declare functions as >> global objects. There are many advantages to this. Why do you believe it >> should be avoided? Especially since it has the same effect as a free >> function. >> DO you believe free function should be avoided as well? > > Global objects, whether functions or data, increases the chances for > name clashes. Also accessing global data increases the chances for > errors in a multi-threaded environment. > > Free functions can be in a namespace, as the standard library functions > are in the 'std' namespace. This helps greatly in avoiding name > conflicts. By global variables, I mean defined at the namespace level, not solely at the global namespace level. So functions using BOOST_FIT_STATIC_FUNCTION can be defined within a namespace. Also, the function objects are `const` so there isn't an issue from multithreaded environments. > >> >> >> >> > >> > >> >> >> >> Quick Start:Lambdas >> >> >> >> Why do we need both BOOST_FIT_STATIC_LAMBDA and >> >> BOOST_FIT_STATIC_LAMBDA_FUNCTION ? I would seem that >> >> BOOST_FIT_STATIC_LAMBDA_FUNCTION would be adequate and >> >> BOOST_FIT_STATIC_LAMBDA is just redundant, mimicking lambda >> syntax to no >> >> purpose. >> >> >> > >> > BOOST_FIT_STATIC_LAMBDA_FUNCTION and BOOST_FIT_STATIC_FUNCTION >> both define a >> > function at global scope, and can only be used at global scope, >> whereas >> > BOOST_FIT_STATIC_LAMBDA can be used to constexpr initialize local >> variables >> > as >> > well. >> >> It might be good to add that when the end-user first encounters >> BOOST_FIT_STATIC_LAMBDA, because the name does not suggest >> initialization of local objects. Furthermore I cannot imagine why one >> would want to use it to initialize a local object, >> >> >> Really? You just said that you would prefer avoiding global functions. > > I mean that for local objects I do not see the reason why I would ever > use BOOST_FIT_STATIC_LAMBDA instead of initializing local objects in the > normal C++ way(s). If this is not the case you need to explain what > problem(s) BOOST_FIT_STATIC_LAMBDA solve in initializing local data > which ordinary C++ initialization of local data could encounter. If > there aren't any problems BOOST_FIT_STATIC_LAMBDA solves in initializing > local data I see no purpose for its existence. > Well, they can still be passed to constexpr functions, even if they are local, I probably shouldn't discuss BOOST_FIT_STATIC_LAMBDA in the Quick Start guide because its usage is not quite as a common. >> >> so you might want to >> explain the benefit of doing so as opposed to the normal syntax for >> creating a lambda function. >> >> >> Maybe the quick start guide isn't the place for this in the first > place. > > I would hope to convince you that a good Overview of your library should > come first and then all the Quick Start guides, tutorials, examples etc. > would make much more sense once your end-user understands what your > library really does in terms of at least the main general functionality. I usually start with the Quick Start guide with a library in order to get an understanding of what components are in the library and what they can do, then I start delving into the other components from there. Thats what I am showing in the Quick Start guide. I guess people have different ways of learning a library. I wonder what is needed to be explained better in a initial overview of the library. > >> >> >> > In fact, BOOST_FIT_LIFT uses this since it is not always clear > what >> > context the user might call BOOST_FIT_LIFT. >> > >> > >> >> >> >> Quick Start:Overloading >> >> >> >> The overloading adaptors show two or more lambda functions. > Can >> they >> >> also work with function objects ? Or a mix of lambda > functions and >> >> function objects ? In fact all the reamining Quick Start > topics >> show >> >> examples with lambda functions. Do they also work with > function >> objects ? >> >> >> > >> > Yes it can be used with function objects. I probably should show >> an example >> > of >> > that as well. I used the lambdas because of the terseness of > them. >> >> Evidently the adaptors can be used with any Callable. I think you >> should >> make that point very strongly and show that in examples also. >> >> >> Agreed. >> >> >> > >> > >> >> >> >> Quick Start:Variadic >> >> >> >> I do not understand what 'We can also make this print > function >> varidiac, >> >> so it prints every argument passed into it.' means ? >> >> >> > >> > I'll try to explain that better, but basically it will print > each >> argument, >> > so: >> > >> > print("hello", 5); // Will print "hello" and > 5 >> >> I wouldn't associate that with the word 'Variadic' but I do > think you >> need to explain that more clearly. >> >> >> I always understood variadic to mean taking a variable number of >> arguments. What do you understand variadic to mean? > > Your terminology is fine, but I always think of variadic in terms of > variadic templates or variadic macros. After all your not making the > print function variadic in the sense of taking a variable number of > arguments. Yes, I am, so I probably need to make that more clear in the documentation. > The simple_print functionality is any of 3 different lambda > functions, with 'conditional' picking the first one that is callable and > > 'fix' passing in the callable as the first parameter. So I really > don't > understand what 'by' does here in printing each argument irregardless of > > your 'Variadic' terminology. You need invoking examples and then show > what the output would be for each invocation, and then it would be > easier for me and others to understand what 'by' does in this situation. > Yep, that part needs to go into more in-depth. >> >> >> > >> > >> >> >> >> I do not think the Quick Start explains very much since it is >> dealing >> >> with adaptors of which we know almost nothing and the >> explanation for >> >> these adaptors and what they actually do is very terse. >> > >> > >> > Probably can expand the explanation of adaptors a little more. >> >> Good idea. What do adaptors create ? >> >> >> They create a function. >> >> Different function objects I would >> imagine ? In that case how about the explanation that adaptors take >> Callables as input and generate function object types that adapt the >> original functionality of one or more Callables to some other purpose. >> >> >> The examples are already show taking Callables. Are you suggesting I >> show an example taking a member function or something? > > Global/static function, member function, std::function, boost::function, > Boost Phoenix and/or Boost lambda function objects, instantiated > template functions. My point is that you should show your library > functionality working with as many types of Callables as possible. > Instead your doc suggests that function objects and lambda functions are > the only type which can be passed to your library's functionality and > you enforce this view by your examples. I'll try to do that. > >> >> > >> > >> >> >> >> In the 'Signatures' section of the Overview I read: >> >> >> >> "All the functions are global function objects except > where an >> explicit >> >> template parameter is required." I honestly don't > know what this is >> >> supposed to mean. Does this refer to when function objects > are >> referred >> >> to as parameters to the adaptors, functions, and utilities of >> the library >> >> ? >> >> >> > >> > I don't understand what you are asking. It means that the >> function is >> > written >> > like this in the documentation: >> > >> > template<class IntegralConstant> >> > constexpr auto if_(IntegralConstant); >> > >> > But its actually a function object like this in the code: >> > >> > struct if_f >> > { >> > template<class IntegralConstant> >> > constexpr auto operator()(IntegralConstant) const; >> > }; >> > const constexpr if_f if_ = {}; >> > >> > However, `if_c` is written like this in the documentation: >> > >> > template<bool B, class F> >> > constexpr auto if_c(F); >> > >> > It requires the bool `B` template parameter explicity. So in the >> code it is >> > written as a function and not as a function object. >> >> I don't understand to what you are referring when you say > 'function'. >> Are you talking about adaptors in your library, functions in your >> library, or what ? >> >> >> I am talking about all functions that are defined in the library, that >> includes adaptors as well. I am not sure how to make that clearer. >> >> Please try to understand that your use of the word >> 'function' is very broad but that the word 'function' > in C++ has a much >> narrower meaning. >> >> >> By function, I mean something like in the example: >> >> template<class IntegralConstant> >> constexpr auto if_(IntegralConstant); >> >> I think everyone agrees that is a function in C++. > > I call that a function template. Which is a family of functions. > My definition for 'function' is not the > > same as yours. I know you feel differently but please realize that the > term 'function', to mean any and every type of callable in C++, is not a > > universally agreed on terminology. I would bet that for the vast > majority of C++ programmers a function is: > > ReturnType FunctionName(ZeroOrMoreFunctionParameters); Yes, which can happen at class scope or namespace scope, and it can also be templated.

5 7

Re: [boost] 2 regression test failing at under 1.60 (John Maddock)
by Steven Kelso 09 Mar '16

09 Mar '16

On Tue, Mar 8, 2016 at 3:42 AM, <boost-request(a)lists.boost.org> wrote: > Date: Mon, 7 Mar 2016 19:21:26 +0000 > From: John Maddock <jz.maddock(a)googlemail.com> > To: boost(a)lists.boost.org > Subject: Re: [boost] 2 regression test failing at under 1.60 > Message-ID: <56DDD4B6.6030603(a)gmail.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > > > On 07/03/2016 17:04, Steven Kelso wrote: > > I've just started trying to install version 1.60 of boost using the gcc > > 5.3.0 compiler. With a vanilla download and no chnages it all seems to > > compile correctly, but I have a problem with 2 library regressions tests > > not terminating. They have both run for over 18 hours before I had to > kill > > them. I was using the options and configuration "out of the box" so > > optimization was -O3. > > I'm unable to reproduce on Ubuntu x64, all the Math lib tests pass fine > for me with gcc-5.3.0 in both C++03 and C++11 modes. > > So you'll need to debug and supply a patch if you're able, > > Thanks, John. > I'm trying to find out what exactly is causing the issue here. Would it be possible for you to show me the 'gcc -###' output so that I can compare to my version of gcc. Since the failure occurs only with optimization turned on i'm now leaning towards a compiler issue since I compiled gcc from source for this test. I'm hoping it's something obvious when I look closer. So far this has failed on a RHEL6.5 system running a locally compiler gcc 5.3.0 as well as a RHEL 7.2 based system compiled with the same gcc 5.3.0. Many thanks for your help, S

1 0

Re: [boost] [C++-sig] Trouble building boost with Visual Studio 2010
by Stefan Seefeld 09 Mar '16

09 Mar '16

Hi David, On 09.03.2016 05:04, David Aldrich wrote: > > Hi > > > > I am trying to build Boost 1.60 with Visual Studio 2010 Professional > on Windows 10. > > > > I use the command: > > > > b2 toolset=msvc-10.0 --with-python link=shared > > > > and get the following error: > > > > python34.lib(python34.dll) : fatal error LNK1112: module machine type > 'x64' conflicts with target machine type 'X86' > Just a quick guess: is it possible that your "libpython34.dll" file is a 64-bit binary, when the command really requires it to be a 32-bit binary ? > > > I guess this means I have a conflict of 32-bit and 64-bit libraries. > I want to target 32-bit (X86). > > > > Do I need to install a 32-bit version of Python? I wonder if that can > co-exist with the current version of Python? > I'm unfortunately unable to answer your question, as the question seems more about the build system than Boost.Python itself. Therefore I'm including the Boost mailing list in my reply, hoping that some Boost.Build expert may be able to help. Regards, Stefan > > > Best regards > > > > David > > > > > > _______________________________________________ > Cplusplus-sig mailing list > Cplusplus-sig(a)python.org > https://mail.python.org/mailman/listinfo/cplusplus-sig -- ...ich hab' noch einen Koffer in Berlin...

1 0

Re: [boost] [Boost-users] [Fit] formal review starts today
by paul Fultz 09 Mar '16

09 Mar '16

> On Tuesday, March 8, 2016 11:39 PM, Gavin Lambert <gavinl(a)compacsort.com> wrote: > > On 9/03/2016 10:43, paul Fultz wrote: >>> I would hope to convince you that a good Overview of your library > should >>> come first and then all the Quick Start guides, tutorials, examples > etc. >>> would make much more sense once your end-user understands what your >>> library really does in terms of at least the main general > functionality. >> >> I usually start with the Quick Start guide with a library in order to get > an >> understanding of what components are in the library and what they can do, > then >> I start delving into the other components from there. Thats what I am > showing >> in the Quick Start guide. >> >> I guess people have different ways of learning a library. I wonder what is >> needed to be explained better in a initial overview of the library. > > I suspect part of the problem is that the Introduction appears under the > ToC at the top level instead of on its own page above the Quick Start. > Thus someone not scrolling down is likely to miss the Introduction and > > start with the Quick Start. > > Still, even the Introduction is a little light on the things an Overview > generally needs to cover: "why should I consider using this library and > what types of problems does it solve?" (Sometimes some of this is split > to a separate Motivation section.) Yea, I think adding Motivation section will be helpful. > > Quick Starts / Tutorials are more for answering "now that I've already > decided to (probably) use this library, how do I do XXX?" > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

2 1

Re: [boost] [Boost-users] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
by paul Fultz 09 Mar '16

09 Mar '16

> On Tuesday, March 8, 2016 6:52 PM, Steven Watanabe <watanabesj(a)gmail.com> wrote: > > AMDG > > On 03/06/2016 09:39 PM, Paul Fultz II wrote: >> >> On Sunday, March 6, 2016 at 3:44:31 AM UTC-6, Vicente J. Botet Escriba >> wrote: >>> >>> Le 06/03/2016 06:16, paul Fultz a écrit : >>>> >>>>> On Saturday, March 5, 2016 10:50 PM, Steven Watanabe < >>> watan...(a)gmail.com <javascript:>> wrote: >>>>> >>>>> #ifndef BOOST_FIT_NO_EXPRESSION_SFINAE >>>>> #ifdef _MSC_VER >>>>> #define BOOST_FIT_NO_EXPRESSION_SFINAE 1 >>>>> #else >>>>> #define BOOST_FIT_NO_EXPRESSION_SFINAE 0 >>>>> #endif >>>>> #endif >>>> This is can be configurable, whereas Boost.Config it is not. >>> I'm not sure this is true. >>> >>> > http://www.boost.org/doc/libs/1_60_0/libs/config/doc/html/index.html#boost_… >> >> >> That doesn't seem easily configurable by the user. I think I would > prefer >> to make it configurable by the library and use Boost.Config for the default > >> value. >> > > Why does it need to be easily configurable? > No one is ever going to care about it except > when Boost.Config is wrong. Well, I guess its mainly only useful for development then. I like to use the "no expression sfinae" path on clang as I can get better diagnostics. It seems kind of complicated to change this with Boost.Config, so I would prefer to have it easily configurable, and then use Boost.Config for the default value.

1 0

[property_tree] Two pull requests removing rtti and exception dependencies
by Chris Glover 09 Mar '16

09 Mar '16

Hi, I have two pull requests against property tree that I haven't heard anything about.. The first replaces usage of typeid(Type).name() in exception messages with boost::typeindex::type_id<Type>().pretty_name(). The second uses macros from no_exception_support.hpp to replace try catch blocks. I was hoping these might get into 1.61 so I don't need to carry local changes for too long -- is there any chance of that? Links: https://github.com/boostorg/property_tree/pull/20 https://github.com/boostorg/property_tree/pull/21 Thanks, -- chris

1 0

[Fit] review - ends next 13th Mars
by Vicente J. Botet Escriba 08 Mar '16

08 Mar '16

Hi, we are on the middle of the Fit review stated on 2 Mars and that ends 13th Mars. We have not received a lot of comments, only 4 or 5 people have commented and only a formal review (reject now). I understand that the documentation needs a lot of improvements, nevertheless, this review is the occasion to give as much feedback as possible. If you want to improve this library, please take the time to do a review and share your point of view. Best, Vicente

1 0

[coroutine] Broken on all compilers.
by Rene Rivera 08 Mar '16

08 Mar '16

Coroutine on master branch seems broken across all the master tested compilers in the same way. Would be nice if it gets fixed. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

2 1

[release] Reminders..
by Rene Rivera 07 Mar '16

07 Mar '16

Boost was closed for "major changes" last Wednesday. Boost will be closed for all change this Wednesday (9th). If all goes well.. Boost will reopen for bug fixes only on the 17th. Please consult the calendar, and subscribe, to the calendar for such dates < http://www.boost.org/development/index.html>. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 6

[BGL] Multiple Start Vertices in Dijkstra Shortest Path
by Matthias Fuchs 07 Mar '16

07 Mar '16

Hi folks, I am interested in adding support for multiple start vertices for the Dijkstra Shortest Path Algorithm. Having such functionality would improve both performance and clarity of code I wrote. In a prove of concept I implemented such functionality using iterators for dijkstra_shortest_paths_no_color_map. Is there interest for such a feature? Or would it be a waste of my time working on that? If there is interest what should be the preferred way? * Using iterators (first_start_vertex, last_start_vertex) * Using ranges What about unit tests? AFAICT there are only few tests, which do not seem to be run automatically. What about documentation? Thanks for reading, Matthias

1 0

2 regression test failing at under 1.60
by Steven Kelso 07 Mar '16

07 Mar '16

I've just started trying to install version 1.60 of boost using the gcc 5.3.0 compiler. With a vanilla download and no chnages it all seems to compile correctly, but I have a problem with 2 library regressions tests not terminating. They have both run for over 18 hours before I had to kill them. I was using the options and configuration "out of the box" so optimization was -O3. I downloaded the regressions tests from https://github.com/boostorg/regression and installed in the boost source tree under 'tools' I then compiled and run them : B=$PWD cd tools/regressions-develop/build $B/b2 --boost-root=$B export PATH=$B:$B/tools/regression-develop/stage/bin:$PATH cd $B/lib/maths/test b2 threading=multi variant=release toolset=gcc-5.3.0 test_binomial_real_concept2 The last few lines of the output file are: test_binomial.cpp(671): error: in "test_main": check x == (RealType)floor(binomial_quantile_data[i][3]) has failed [60 != 61] test_binomial.cpp(673): error: in "test_main": check x == (RealType)floor(binomial_quantile_data[i][4]) has failed [61 != 64] test_binomial.cpp(673): error: in "test_main": check x == (RealType)floor(binomial_quantile_data[i][4]) has failed [60 != 59] test_binomial.cpp(673): error: in "test_main": check x == (RealType)floor(binomial_quantile_data[i][4]) has failed [60 != 59] the same looping forever occurs with test_binomial_real_concept4 as well. However, editing the Jamfile.v2 file to add an entry '<optimization>off' for the test, allows the test to complete successfully and the test_binomial_real_concept2.output having no errors. I've done the same test using gcc 5.2.0 and gcc 5.1.0 as well with the same results. However, boost 1.56 using gcc 5.3.0 completes all of it's tests successfully. Is this a known issue or, if not, is there any more information that I can supply to help diagnose why this isn't working? Many thanks, S

2 2

Recommended Boost file structure?
by Paul A. Bristow 07 Mar '16

07 Mar '16

I've been looking at the structure of Phil Bouchard's prototype block_ptr library and am wondering if the structure of the header files is optimal/Boost_Standard/wrong. http://www.boost.org/doc/libs/1_60_0/more/getting_started/windows.html describes the Boost structure, but looks well out of date to me. (Can/should anyone still update this to reflect Modular Boost?) And looking through libraries, there seems some variation. I'm asking for views on what the best structure should be, (or if it doesn't matter much?) Some libraries have a structure modular_boost/libs/algorithm/include/boost/algorithm which contains algorithm.hpp and string.hpp that one might use directly. Others like asio contain /asio and just a asio.hpp that includes (all?) other headers. Others like multiprecision contain just a single folder modular_boost/libs/algorithm/include/boost/multiprecision but no other header files, not even forwarding header(s). So should the structure be that all headers (except forwarding headers - or a single header) are within modular_boost/libs/some_library/include/boost/some_library/ so the user should include with #include <boost/some_library/some_header.hpp #include <boost/some_library/other_header.hpp ... or to get everything useful #include <boost/some_library/some_library_fwd.hpp> possibly with a /detail folder containing headers that should not be called by users. Just checking... Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

2 4

Re: [boost] [Boost-users] [Fit] formal review - should we propose some parts to Boost.Config/Boost.Core
by paul Fultz 07 Mar '16

07 Mar '16

> On Saturday, March 5, 2016 10:50 PM, Steven Watanabe <watanabesj(a)gmail.com> wrote: > > AMDG > > On 03/05/2016 07:21 PM, Vicente J. Botet Escriba wrote: >> >> I want to start a new sub-thread about some of the concerns of Steven >> Watanabe about whether some of the contents of this library fits better >> in Boost.Config. In particular the file boost/fit/returns.hpp. >> > > When I mentioned Boost.Config, I was talking about > things like > > #ifndef BOOST_FIT_NO_EXPRESSION_SFINAE > #ifdef _MSC_VER > #define BOOST_FIT_NO_EXPRESSION_SFINAE 1 > #else > #define BOOST_FIT_NO_EXPRESSION_SFINAE 0 > #endif > #endif This is can be configurable, whereas Boost.Config it is not. > > or > > #ifndef BOOST_FIT_HAS_TEMPLATE_ALIAS > #if (defined(__GNUC__) && !defined (__clang__) && __GNUC__ == 4 > && > __GNUC_MINOR__ < 7) > #define BOOST_FIT_HAS_TEMPLATE_ALIAS 0 > #else > #define BOOST_FIT_HAS_TEMPLATE_ALIAS 1 > #endif > #endif > This could be replaced with Boost.Config, however, I have ran into problems before with template aliases on gcc 4.7, so I wanted to make this configurable as well, although it could fallback onto Boost.Config right now. > In Christ, > > Steven Watanabe > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

3 2

[MMap/VM] RFC
by Domagoj Saric 06 Mar '16

06 Mar '16

Hello everyone, for quite some time I've been working on a portable mmap/virtual memory library and I've finally found enough time to bring it out of the 'my internal litle tool' state into something presentable: https://github.com/psiha/mmap (C++14 currently). I would now kindly ask fellow devs for opinions (on the good, the bad, the ugly and the future;) First let me answer the basic questions (i.e. on motivation and scope)... Q&A: (1) Why? Considering Boost already offers two related solutions * Interprocess: http://www.boost.org/doc/libs/release/doc/html/interprocess/sharedmemorybet… * Iostreams: http://www.boost.org/doc/libs/release/libs/iostreams/doc/classes/mapped_fil… why do we want a new one? Even if the two mentioned solutions were adequate, the problem domain would still merit a separate, dedicated library merely considering its complexity (which will become apparent in later points). (I suspect Ion would agree here considering he actually authored a related standardization proposal:) (2) Why a completely new library instead of a repackaging of existing functionality? I'm not satisfied with (a) the API semantics/design, (b) the API 'power'/library capabilities (c) and the implementation efficiency/overhead. a) Insistence on POSIX semantics: that shared memory objects have to be persistent (kernel lifetime) and resizable while not everyone wants or needs this (https://svn.boost.org/trac/boost/ticket/4827) This has implications both: - in the interface (requiring manual cleanup guards, additional platform specific shm types like windows_shared_memory) - and the overhead of the library (emulating shm with mapped files on major platforms that do not offer full POSIX compliance: Windows, OSX, iOS and Android) MMAP solves this with one class template 'named_memory' and policies: https://github.com/psiha/mmap/blob/master/include/boost/mmap/mappable_objec… so the user can choose: named_memory<scoped, resizable>, named_memory<persistent, fixed> or any other combination and the library chooses the best implementation. On POSIX, scoped semantics are achieved with a SEM_UNDO-enabled SysV semaphore acting as a kernel/system-global reference counter (which is then also used for automatic cleanup of shm zombies left by killed/crashed processes). On Windows the user can choose the Win32 backend (file emulation) or the NativeNT (not yet finished/commited) backend (with native persistence and resizability). b) - lack of a meta layer (e.g. so one can ask is_mappable<FILE *> or is_mappable<boost::filesystem::path>, is_mappable<HANDLE> etc...) - lack of related utility functions, for example: -- map_read_only_file( path ) which will open the file for reading, query its size, create a read only file mapping and map/return a read only view of the file -- guarded_operation( view, operation, error_handler ) - execute operation wrapped in SEH(Windows)/scoped signal handler(POSIX) guards that will catch access violations (e.g. when mmaping network files) and gracefully execute error_handler (with the faulting address as the parameter) https://github.com/psiha/mmap/blob/master/include/boost/mmap/mapped_view/gu… - in MMAP the mapped_view object (which should probably be renamed to just 'view' considering the enclosing mmap namespace) is just a RAII wrapper around an iterator_range therby providing the standard begin/end(), front/back(), operator[], etc. interface (as opposed to a get_data(), get_size() like interface) - general (not specific to mapping) virtual memory functionality (to be discussed in a separate point, MMAP also completely lacks this currently) - MMAP offers a comprehensive 'flags' system (e.g. https://github.com/psiha/mmap/blob/master/include/boost/mmap/flags/flags.hpp) for everything from object-level and system-level access privileges, over object parent-child inheritance to system life-time and access-pattern optimisation hints. Quite some time was invested in this area to produce a normalized interface that works for all objects (files, mappings...) while producing (near)zero adjustment codegen. Flags are 'packed'/grouped in structs (e.g. struct access_privileges with object_access, child_access and systen_access members) with public members so that, after flags are created with a factory function (a portable API) the flags can be further tweaked for a specific platform (e.g. adding some FreeBSD specific mmap hint which isn't covered by the portable/documented MMAP API) c) It is my view (if not a "self evident truth";D) that libraries that merely wrap existing low level functionality (such as OS or CRT APIs) should allow you to write code that is safe, portable and looks reasonably nice while at the same time incurs (near)zero overhead (i.e. with a reasonably intelligent compiler, produces codegen that looks nearly the same as it would had one used the underlying API directly) - and the existing solutions fail that. In the two related tickets I went into more detail on this so I'll avoid spaming this post by repeating those objections and analysis. Rather I'll present a trivial example that demonstrates what wannabeboost::mmap currently produces with a decent compiler, https://gist.github.com/psiha/c0823fefc01fa3b39662: #define BOOST_MMAP_HEADER_ONLY #include <boost/mmap/mapped_view/mapped_view.hpp> #include <boost/mmap/mappable_objects/file/utility.hpp> int main( int /*argc*/, char * /*argv*/[] ) noexcept { auto maybe_foo_view( boost::mmap::map_read_only_file( "foo" )() ); if ( !maybe_foo_view ) return static_cast<int>( maybe_foo_view.error() ); if ( maybe_foo_view->empty() ) return -1; return (*maybe_foo_view)[ 0 ]; } with Xcode 7.2.1 Clang -O3 build for x64 produces https://gist.github.com/psiha/f92a7b8a93c5ce1736ae (notice how the error handling is also correctly detected as such and placed at the end of the function, after the main return...) Besides not using shared_ptr pimpls or saving paths in std::strings as a 'nice to have' (YAGNI!:), part of the way this codegen is achieved is through the use of (also wannabe) Boost.Err (https://github.com/psiha/err) which makes it possible to avoid EH (in such simple/'localised' examples). It is also the reason for the somewhat awkward (optional<>-like) syntax: - map_read_only_file() returns a mmap::fallible_result<mmap::mapped_view> (an alias for err::fallible_result<mmap::mapped_view, mmap::error>, an "rvalue-only" type) - which is converted/'saved'/'pinned' into a result_or_error (the maybe_foo_view variable) with the additional operator() call - the !maybe_foo_view checks whether the call succeeded or the returned object contains an error - if error return the error (errno) code - else check if the view/file is empty (optional<>-like syntax for accessing the contained object through the -> and * operators) - else return the value of the first character in the file. Boost.Err was recently discussed on this list so I'll skip most of that now, let me just say that it also supports classic EH coding style (it auto adapts, no need for reconfiguration, macros or anything like that), i.e. the above code can be rewritten as: int main( int /*argc*/, char * /*argv*/[] ) noexcept { using namespace boost::mmap; try { read_only_mapped_view const foo_view( map_read_only_file( "foo" ) ); if ( foo_view.empty() ) return -1; return foo_view[ 0 ]; } catch ( std::runtime_error const & ) { return error::get(); } } ...now let me reverse the Q&A direction ;) 3. Library scope: currently the library covers the topic of memory mapping (of filesystem objects and virtual memory), however I think that 'the final' library should cover all resonably portable aspects of virtual memory (and be called something like vm with mmap as a nested namespace), tackling thingies such as: - process working set - portable low memory event handling, madvise, memfd... - prefetching, locking/unlocking virtual memory to/from physical memory (e.g. for realtime sensitive data) - allocators capable of contiguous resizing (for implementing realloc or vector.resize() that does no copying or moving, simply maps new pages at the end of the current allocation) - https://fgiesen.wordpress.com/2012/07/21/the-magic-ring-buffer ... does anyone have an objection/different approach to this? 4. Windows offers/has/uses the concept of an intermediate "mapping" object (i.e. you don't create a mapped view of a file, rather you create a 'mapping' of a file and then a view of the mapping). This of course complicates things but also gives more power, e.g. you can have a r/w file open and create a mapping (or several mappings) of it that only covers a part of its size and has stricter (e.g read only at object/process level) or wider access privileges (e.g. on the system level, only the parent process/user can access the file but the mapping is accesible by everyone). Boost.MMAP retains this distinction in its API (mapping vs mapped_view classes)...comments/thoughts on this please? 5. The above (Windows specific) 'mapping' concept makes it possible to create "named file mappings" (so that the object gets a system global name, like a shared memory object) which then another process can open by its name, erasing the difference between file mappings and vm mappings for client processes (kind of like the interface vs hidden implementation distinction). MMAP uses this on Windows for file-backed/'emulated' shared memory (e.g. that which needs persistence and/or resizabilty) - it is created named so that client processes can open and access it as 'normal'/native Windows shared memory. It might actually be possible to make this at least partially portable to POSIX systems that use virtual filesystems for implementing shared memory (e.g. Linux which uses /dev/shm) where we could symlink the file to the shm filesystem directory...(unfortunately I have no way of testing this as I have no Linux machine setup, I develop only for Windows, OSX, iOS and Android)...does this make any sense/would it be worth the hassle (i.e. ease any real world problems)? 6. The security part of the 'flags system' models the POSIX API: for named (system level) created objects you specify the permissions for the 'user', 'group' and 'world'. 'Behind the scenes', on Windows, 'user' maps to the user that created the process, 'group' maps to all groups that the 'user' belongs to and 'world' maps to the Everyone group..? When not using the predefined privilege/permission levels [e.g. process_default, unrestricted, nix_default (644)] things are currently pretty verbose here: namespace flags = boost::mmap::flags; using ap = flags::access_privileges; auto const default_privileges ( ap::system::user ( ap::all ) | ap::system::group( ap::read ) | ap::system::world( ap::read ) ); I have a prototype implementation that shortens this with user defined literals, so that one can write something like "rwxr-xr--"_perm...All in all, this thing looks like it merits a separate library in its own right... 7. Windows has another quirk up its sleeve: global vs local session objects - if you want to create a shared memory object visible across terminal sessions (this includes a server process running as a service, thereby in session 0, and client process created by a logged on user, or/also using the NativeNT backend/API to create a native persistent shared memory object which requires that it be created in the global session '0') you have to prefix its name with "Global\" (and have admin privileges)... I'm still pondering how to model this in the API or whether it should be automatically handled at all, e.g. whether to deduce if the Global\ prefix should be automatically added (based on the process privileges, type and access privileges of shm object being created etc) or leave it up to the user to know "if I'm running on Windows and want to do this and this I have to use the Global\ prefix"... There's more but the openning post is already too long so I'l stop...for now ;) -- "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 --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus

4 5

code naming conventions
by Michael Marcin 06 Mar '16

06 Mar '16

I've written a lot of code in the boost/standard library style. I've become increasingly annoyed at naming my variables when coding in this style. Looking to the standard library implementations for guidance isn't much help as they often use conventions like local variables are named with a leading double underscore and member variables are named with a leading underscore and capital letter. I.E. things I'm not allowed to do as I'm not a standard library implementer. Good names are generally taken by types leading to distress when trying to name objects and functions. Here's a concrete example: // type takes the most natural name enum class format { rgba, rgb, float // enum value wants reserved name }; class image { public: // getter wants the same name format format() const noexcept { return this->format; } // setter wants the same name void format( format format ) noexcept // parameter wants the same name { this->format = format; } private: // member variable wants the same name format format; }; format bits_to_format( int bits ) { // local variable wants the same name format format = format::rgba; if ( bits == 24 ) { format = format::rgb; } return format; } // unrestricted template parameter does *not* want the same name template< typename Format > std::ostream& print_format( std::ostream&, Format format ); // Concept template parameter *does* want the same name template< Format Format > std::ostream& print_format( std::ostream&, Format format ); What I end up doing right now is something like: // type takes the most natural name enum class format { rgba, rgb, float_ // add trailing underscore to reserved name }; class image { public: // prefix getter with get_ format get_format() const noexcept { return _format; } // prefix setter with get_ void set_format( format format_ ) noexcept // trailing underscore on parameter { _format = format_; } private: // leading underscore on member format _format; }; format bits_to_format( int bits ) { // cutesy abbreviation for local variable format fmt = format::rgba; if ( bits == 24 ) { fmt = format::rgb; } return fmt; } template< typename Format > std::ostream& print_format( std::ostream&, Format format_ ); // cutesy abbreviation for constrained template type template< Format Fmt > std::ostream& print_format( std::ostream&, Fmt format_ ); Having to come up with cutesy abbreviations for every local variable that are still meaningful is especially distracting. Surely enough code has been written that this has been solved. I looked through several boost library implementations but didn't see anything that stuck out as a clear convention. Adobe's ASL library seems to append _t postfix to type names and _m postfix to member variables. They also use very terse names for template parameter type names as well as parameter names and local variables. Like in: template <typename I, // I models ForwardIterator typename N, // N models IntegralType typename T, // T == result_type(P) typename C, // C models StrictWeakOrdering(T, T) typename P> // P models UnaryFunction(value_type(I)) -> T I lower_bound_n_(I f, N n, const T& x, C c, P p) { while (n != 0) { N h = n >> 1; I m = boost::next(f, h); if (c(p(*m), x)) { f = boost::next(m); n -= h + N(1); } else { n = h; } } return f; } What's your preferred convention? If possible please answer by modifying the initial concrete example and providing annotations.

3 2