- Boost-users - lists.preview.boost.org

Newbie error trying to construct an offset_ptr in a managed shared memory segment.
by Bill Baker 03 Apr '19

03 Apr '19

1 0

cannot compile boost pmr small_vector snippet
by Pedro Pinto pedro.pinto＠bluetradesys.com 02 Apr '19

02 Apr '19

Hi there, I am trying to use the pmr version of the boost small_vector container. I expected the following to work: #include <boost/container/pmr/polymorphic_allocator.hpp>#include <boost/container/pmr/small_vector.hpp> boost::container::pmr::polymorphic_allocator<int> alloc; boost::container::pmr::small_vector<int,4> vec(alloc); But this does not compile with boost 65, gcc 7.3/clang 6.0. The compile error seems to suggest I should be using small_vector_allocator which is an internal class. The exact clang error is below. Am I missing something here? Thanks /usr/include/boost/container/small_vector.hpp:514:41: note: candidate constructor not viable: no known conversion from 'boost::container::pmr::polymorphic_allocator<int>' to 'const boost::container::small_vector<int, 4, boost::container::pmr::polymorphic_allocator<int> >::allocator_type' (aka 'const small_vector_allocator<boost::container::pmr::polymorphic_allocator<int> >') for 1st argument BOOST_CONTAINER_FORCEINLINE explicit small_vector(const allocator_type &a)

1 0

[variant2] Review of Variant2 started today : April 1 - April 10
by Michael Caisse 02 Apr '19

02 Apr '19

The Boost formal review of Peter Dimov's Variant2 library will take place April 1 - 10, 2019. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Variant2 is a never-valueless C++11/14/17 implementation of std::variant. >From the README: The class boost::variant2::variant<T...> is an almost conforming implementation of std::variant with the following differences: * A converting constructor from, e.g. variant<int, float> to variant<float, double, int> is provided as an extension; * The reverse operation, going from variant<float, double, int> to variant<int, float> is provided as the member function subset<U...>. (This operation can throw if the current state of the variant cannot be represented.) * variant<T...> is not trivial when all contained types are trivial. To avoid going into a valueless-by-exception state, this implementation falls back to using double storage unless * one of the alternatives is the type monostate, * one of the alternatives has a nonthrowing default constructor, or * all the contained types are nothrow move constructible. If the first two bullets don't hold, but the third does, the variant uses single storage, but emplace constructs a temporary and moves it into place if the construction of the object can throw. In case this is undesirable, one can force emplace into always constructing in- place by adding monostate as one of the alternatives. You can find the source code here: <https://github.com/pdimov/variant2> The master branch will be stable for the review: <https://github.com/pdimov/variant2/tree/master> Find the documentation here (also stable during the review): <https://pdimov.github.io/variant2/doc/html/variant2.html> Note: The repository contains an expected implementation also; however, that is not being considered in this review. Please provide in your review information you think is valuable to understand your choice to ACCEPT or REJECT including Variant2 as a Boost library. Please be explicit about your decision (ACCEPT or REJECT). Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: <http://www.boost.org/community/reviews.html> Thank you for your effort in the Boost community. Happy coding - michael -- Michael Caisse Ciere Consulting ciere.com

1 0

[boost][stacktrace] stacktrace keep eating memory
by Hao Jiang 29 Mar '19

29 Mar '19

I am using stacktrace on Windows. I found stacktrace keep eating my memory. A simple test program: void foo() { auto st = boost::stacktrace::stacktrace{}; auto line = st.begin()->source_line(); std::cout << line << std::endl; } void main() { for (int i = 0; i < 0xFFFF; i++) { foo(); } } Based on MSVC memory profiling tool, memory usage keep growth: [cid:image001.png@01D4DF46.BA4E1090] And frame allocator is taking heap: [cid:image004.png@01D4DF47.6F38C310] Anyone knows why it happens? Br, Hao. Platform: Windows 7. Compiler: MSVC 2017 Boost version: 1.67 Compile and link: release, static-link, static runtime.

2 1

[dll] Notifying a plugins host that a plugin should be unloaded
by Sean Farrow 29 Mar '19

29 Mar '19

Hi all, I have an application that uses boost.dll to provide plugin functionality. I have a base class defined that all plugins derive from. I'm looking for a way to notify the host application that a particular plugin should be unloaded. This is determined by the plugin itself. Is signals/slots appropriate here or is there a better option? Has anyone else done anything like this? Any help appreciated. Kind regards Sean.

2 1

[range] Conflict with string algorithms
by Bill Buklis 29 Mar '19

29 Mar '19

I noticed there is a conflict between boost range and the string algorithm header files. There may be others, but the specific one I was dealing with was boost::find. For example, the following code results in an ambiguous warning. This is because boost::find is defined both in algorithm/string/find.hpp and range/algorithm/find.hpp. #include <vector> #include <boost/range/algorithm.hpp> #include <boost/algorithm/string.hpp> int main() { std::vector<int> vec; boost::find(vec, 3); } Is this intentional or is it is an oversight or am I just doing something wrong? -- Bill

2 1

[review][variant2] Variant2 Review Starts April 1
by Michael Caisse 24 Mar '19

24 Mar '19

The Boost formal review of Peter Dimov's Variant2 library will take place April 1 - 10, 2019. Please consider participating in this review. The success of Boost is partially a result of the quality review process which is conducted by the community. You are part of the Boost community. I will be grateful to receive a review based on whatever level of effort or time you can devote. Variant2 is a never-valueless C++11/14/17 implementation of std::variant. >From the README: The class boost::variant2::variant<T...> is an almost conforming implementation of std::variant with the following differences: * A converting constructor from, e.g. variant<int, float> to variant<float, double, int> is provided as an extension; * The reverse operation, going from variant<float, double, int> to variant<int, float> is provided as the member function subset<U...>. (This operation can throw if the current state of the variant cannot be represented.) * variant<T...> is not trivial when all contained types are trivial. To avoid going into a valueless-by-exception state, this implementation falls back to using double storage unless * one of the alternatives is the type monostate, * one of the alternatives has a nonthrowing default constructor, or * all the contained types are nothrow move constructible. If the first two bullets don't hold, but the third does, the variant uses single storage, but emplace constructs a temporary and moves it into place if the construction of the object can throw. In case this is undesirable, one can force emplace into always constructing in- place by adding monostate as one of the alternatives. You can find the source code here: <https://github.com/pdimov/variant2> and the documentation here: <https://pdimov.github.io/variant2/doc/html/variant2.html> Please take an early look at the library and ask questions now. Peter Dimov is very active on the Cpplang Slack #boost channel; however, please consider using the Boost Dev or User Mail Lists so that the entire community might benefit from your conversation. Note: The repository contains an expected implementation also; however, that is not being considered in this review. Thank you for your participation! michael -- Michael Caisse Ciere Consulting ciere.com -- Michael Caisse Ciere Consulting ciere.com

1 0

How to keep a pointer on a shared data in a boost shared memory segment
by jucin loic 24 Mar '19

24 Mar '19

Hi everyone ! How to keep a pointer on a shared data in a boost shared memory segment ? I have a function which returns shm.construct<SharedData>(_nameSeg.c_str())(innerDataAllocator); But outside of the function, the object pointed by SharedData is inaccessible My general problem is that I want to have way to get, and set data in shared memory, but without, each time, having to : -get shm -find object in shm based on its name -construct allocators. So I would like to store 1) allocators and 2)a pointer to the shared object How could I do this ? I made a SO question about my problem, can you have a look ? It should be clearer :) https://stackoverflow.com/questions/55195149/how-to-keep-a-pointer-on-a-sha…

4 5

Future of boost.compute
by Heriberto Delgado 23 Mar '19

23 Mar '19

My apologies if this has been asked before. To be honest, I'm not good doing stuff with mailing lists. However, this is something about which I would really like to know your opinion. With Apple recently deprecating OpenCL / GL technologies in their software, and the newer APIs on the market - Vulkan, Metal - and current native APIs - DX Compute, also Metal Compute - , it sure looks like boost.compute, which is essentially a wrapper around OpenCL, is on its way to become a legacy API. That is, unless the API gets modified to allow multiple APIs and platforms. So, what do you think is going to happen? Is boost.compute eventually going to "disappear" (similar to how boost pointer classes were replaced by std:: pointer classes), or is there some kind of effort to move it beyond OpenCL and into newer APIs? - Heriberto Delgado.

1 0

Re: [Boost-users] Zero-malloc memory pool for Boost Intrusive smart pointers
by Gavin Lambert 23 Mar '19

23 Mar '19

At 09:25 23/03/2019, Francesco wrote: >Yes I know about std::make_shared<> and indeed I >was using that solution before implementing the >memory pool based on intrusive pointers. >The problem is that in my workload I have >several threads that need to get a smart pointer >to a fairly-big object every time they process >input data and they will release it later. Which brings up another point; your current implementation is not thread-safe. Which is fine, but you should probably mention that explicitly in your readme. A very common worker pattern is to have all allocations on one thread and all deallocations on another thread, and that wouldn't work as-is. >Now allocating with std::make_shared<>Â a new >object on every input data was causing my >threads to do lots of mallocs/sec and that >became the performace limiting factor. >The use of a memory pool instead allows me to do >a very large memory allocation from time to time >(in blocks of e.g. 1024 items) and still have >each single item of the memory pool independently refcounted. Yes, I realise that. It still could be possible to have individual node allocations strung up into a free list rather than requiring a larger contiguous allocation. But you're correct that arena allocation and intrusive_ptr is probably more efficient in the end. >My first implementation of the memory pool >indeed was using C++11 perfect forwarding to >call the ctor/dtor of type T when the item was >pulled out the pool or was returning to it. >I later removed such feature because I realized >that calling the ctor of the items to recycle >produced issues with classes having multiple inheritance IIRC. >I don't think it's safe and sane to call the >ctor of the same instance multiple times...Â Calls must be paired -- you allocate aligned uninitialised storage (aligned_storage), then placement-new to call the constructor on that storage, then eventually call the destructor, and then later you can placement-new again. You must never call the constructor twice in a row or the destructor twice in a row (unless it's trivial), but alternating is fine. Again, this is how things like optional and variant work internally -- and since they do that part for you, it can be useful to re-use it rather than re-implementing it.

2 1