- Boost-users - lists.boost.org

[variant2] Review - Review period extended until April 15
by Michael Caisse 09 Apr '19

09 Apr '19

Hi all - The review period for Boost.Variant2 has bee extended to April 15. Thank you to those who have participated so far. There has been a fair amount of discussion about the merits of never valueless. A core design _feature_ of Variant2 is never valueless. You may have made different trade-offs. Understanding motives makes sense but in this review we are not trying to change this basic design choice. This paper by Peter discusses valueless variants some and may be useful reading: <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0308r0.html> If you haven't started your review yet, you have time! Reviews ranging from detailed discussions of inner workings to a user-perspective of the library and documentation are all helpful. I personally believe we need more user-based reviews in Boost. So, feeling sheepish about reviewing? Don't! Your review is important in the process. Here is one more motivation if you are on the fence ... Peter's code is a joy to read. The library is extremely clean and the code is accessible. There might be all kinds of things you learn from reading the source. Thank you again community for staying involved. We get great libraries when people ask questions, review, and provide input to everything from the docs to the design. Happy coding! michael -- Michael Caisse Ciere Consulting ciere.com

1 0

Re: [Boost-users] [boost] [release] Boost 1.70.0 Release Candidate 1 available
by Vinnie Falco 08 Apr '19

08 Apr '19

On Mon, Apr 8, 2019 at 3:51 PM Stefan Seefeld <stefan(a)seefeld.name> wrote: > At this point in time, I'd argue...fixes, to make sure... > But soft, what commit through yonder git log states? It is a bug, and 5e88637752ea0ecb49824904be3098656740298c is the fix! ... To merge, or not to merge? That is the question. Regards

1 0

[release] Boost 1.70.0 Release Candidate 1 available
by Marshall Clow 08 Apr '19

08 Apr '19

The release candidates for the 1.70.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.70.0/source/> The SHA256 checksums are as follows: 6e5cba1269225395bb5e78dda48441ccadaf745e42638180015e9e6257068336 ./boost_1_70_0_rc1.7z 35d8e1361e2063f70aa3a6ca0dd8af0877ceb75477ebbd2c726bb1d039658c7a ./boost_1_70_0_rc1.tar.bz2 ec8ddbbee2fd61e2f78a1dfe9a07ad83ca8f6a2f4c704d6f297d89c6afdc4f2c ./boost_1_70_0_rc1.tar.gz ee2c3b97ce10f85a31b6a105ad8edf1c20fb4b936c9a6e6008206059cb98ab1b ./boost_1_70_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. -- The Boost Release Managers

8 15

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 28 Mar '19

28 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