May 2017 - Boost - lists.preview.boost.org

base64 ?
by Greger 22 May '17

22 May '17

Hi all, First: As an introduction: I am new on this list. Joined a few weeks ago. Second:is there any interest in base64? I have a library for encoding and decoding, which I could contribute. Thank you, tc Greger

6 7

Boost.Outcome and the C++ standard proposals
by Vicente J. Botet Escriba 20 May '17

20 May '17

Hi, for those that will follow the Boost.Outcome review I wanted to share some links related to the standard: The draft of the next revision : * D0323R2 -*A proposal to add a utility class to represent expected monad *(Revision 4) - https://github.com/viboes/std-make/blob/master/doc/proposal/expected/d0323r… The monadic interface draft proposal * DXXXX - *C++ Monadic inteface* - https://github.com/viboes/std-make/blob/master/doc/proposal/monads/Monads.md This is based on Hana customization in its pre-Boost version. And last a very draft paper I don't pretend to send to the standard meetings, at least not yet, about how FileSystem TS could be adapted to take in account the proposes status_value and expected classes. * DXXXX -*Refactoring FileSystem TS using **|expected|**or **|status_value|*||- https://github.com/viboes/std-make/blob/master/doc/proposal/expected/DXXXXR… This paper show that there is not silver bullet solution to reporting errors, but that making abstractions as status_value or expected makes the interface more clear, composable and readable (for me at least) than using out parameters error codes. The paper show also that wanting to have exception interfaces and non-exception interface forces to double the interface. Using expected could reduce it at the price of using .value(). I have an POC implementation in https://github.com/viboes/std-make/tree/master/include/experimental/fundame… Look for expected, functor, applicative, monad, monad_error folders for the implementation and std for the customization. My intention is to show that there is something on-going on the standard aside the expected proposal as requested by the committee. Note these drafts are of course not reviewed yet by the committee and I don't know if they will like the direction. We will see in Toronto next July Best, Vicente P.S. The dead line for next meeting is the 19 Jun. Any feedback is welcome, but as this is not C++ standard ML, I will prefer to have this feedback either privately or vi a the std-proposals ML.

2 1

[outcome] Changelog of all changes made since review announcement one week ago
by Niall Douglas 20 May '17

20 May '17

Dear list, The Outcome review begins later today, but so much feedback has landed this past week already that I had better announce what has changed in develop branch to prevent people reraising already fixed things: ## 20170519 boost_peer_review4: - Issue #13 The opcode counting CI tests in test/constexprs was severely broken on POSIX. Thanks to Tom Westerhout for finding the problem and supplying its fix. - unittests.cpp had become clang-tidy unclean, fixed. - Issue #15 Move `outcome::expected<T, E>` into `outcome::experimental::expected<T, E>`. Thanks to Vicente J. Botet Escriba for persuading me to do this. - Issue #14 Removed all the static asserts in the Expected implementation apart from the nothrow move constructor check, which is now correct unlike the incorrect assert from before. Thanks to Vicente J. Botet Escriba for explaining Expected's semantics. - Issue #21 Correct misspelling of `extended_error_code` with `error_code_extended` in the docs. Thanks to Deniz Bahadir for reporting this. - Issue #17 Give credit to Paul Bristow for the name "Outcome". Thanks to Peter Dimov for finding the correct person. - Issue #18 `result<T>` had a `.set_exception()` which it should not have had. Thanks to Peter Dimov for reporting this. - Issue #19 Remove observers `.is_ready()`, `.get_error_or()`, `.get_exception_or()`. Thanks to Peter Dimov and Andrzej Krzemienski for suggesting this. - Issue #20 Rename: - `monad_error` to `bad_outcome` - `monad_errc` to `bad_outcome_errc` - `monad_category` to `bad_outcome_category` - `BOOST_OUTCOME_THROW_MONAD_ERROR` to `BOOST_OUTCOME_THROW_BAD_OUTCOME` Thanks to Peter Dimov, Andrzej Krzemienski and Paul Bristow for suggesting this. If anyone prefers to see these changes in a tarball, you can get a tarball at https://github.com/ned14/boost.outcome/releases/tag/boost_peer_review4 or the boost_peer_review4 tag in git. Note that this tarball was generated straight off develop branch from my laptop and MAY NOT WORK well. I didn't get a chance to implement these outstanding issues before the review began: - https://github.com/ned14/boost.outcome/issues/11 Expected should never have a valueless state - https://github.com/ned14/boost.outcome/issues/12 Copy assignment gets instantiated even when type T cannot be copied - https://github.com/ned14/boost.outcome/issues/16 Default constructor of T is sometimes compiled when T has no default constructor Thanks in advance for your feedback and reviews. As I hope the above shows, it makes a big difference. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

[context] Windows x64 fiber local storage GS offset
by Elbert Mai 20 May '17

20 May '17

The Windows x64 implementation of Boost.Context saves fiber local storage from GS:[0x18]. For example, in jump_x86_64_ms_pe_masm.asm: ; load NT_TIB mov r10, gs:[030h] ; save fiber local storage mov rax, [r10+018h] mov [rsp+0b0h], rax However, this is the NT_TIB struct as defined in winnt.h typedef struct _NT_TIB { struct _EXCEPTION_REGISTRATION_RECORD *ExceptionList; PVOID StackBase; PVOID StackLimit; PVOID SubSystemTib; union { PVOID FiberData; DWORD Version; }; PVOID ArbitraryUserPointer; struct _NT_TIB *Self; } NT_TIB; This implies that fiber local storage is found in GS:[0x20], not GS:[0x18]. The Windows x86 implementation uses FS:[0x10], which is consistent with the NT_TIB struct. Am I missing something, or does Boost.Context save/restore fiber local storage at the wrong address in Windows x64?

3 3

[Beast] Discussion
by Vinnie Falco 20 May '17

20 May '17

A desire was stated in the 2015 formal review for Boost.Http, that the author would engage the community during the development of the library. I've been doing that throughout the development of Beast and I will continue to do so. So I am inviting you and anyone else who would like to participate in the design and evolution of this library to weigh in with comments on anything that you would like, ahead of the Beast formal review (scheduled July 1st). Your feedback can help make the library better! On Sat, May 20, 2017 at 8:19 AM, Bjorn Reese via Boost <boost(a)lists.boost.org> wrote: > On 05/20/2017 04:17 PM, Vinnie Falco via Boost wrote: > >> I hope readers are convinced that HTTP requests and responses should >> be modeled as self-contained objects with all necessary fields >> prescribed by rfc7230, and that the HTTP status should be neither >> separate nor stored in an error_code. > > > Not really, but that is the subject for a review of a different library. Here's a nice new thread for the discussion.

1 0

[math] Chebyshev polynomial
by Bjorn Reese 20 May '17

20 May '17

Does Boost.Math contain functions for Chebyshev polynomials? Preferably a recurrent chebyshev_next(). I can find functions for Legendre, Laguerre, and Hermite polynomials, but not Chebyshev.

3 3

[review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
by charleyb123 . 19 May '17

19 May '17

Hi Everyone, ** HEADS UP, NEXT WEEK ** The formal review of Niall Douglas' Outcome library starts next week (Fri-19-May to Sun-28-May). Your participation is encouraged, as the proposed library is uncoupled and focused, and reviewers don't need to be domain experts to appreciate the potential usefulness of the library and to propose improvements. Everyone needs (and has suffered) error handling, and can compose an opinion on that topic. Outcome is a header-only C++14 library providing expressive and type-safe ultra-lightweight error handling, suitable for low-latency code bases. Key features: *- Makes using std::error_code from C++11's <system_error> more convenient and safe *- Provides high-quality implementation of proposed std::expected<T,E> (on C++20 standards track) *- Good focus on low-latency (with tests and benchmarks) *- Error-handling algorithmic composition with-or-without C++ exceptions enabled *- No dependencies (not even on Boost) This review is timely, as C++17 brings us std::optional<T>. The upcoming std::expected<T,E> (an implementation provided in Outcome) is a generalization of std::optional<T> that provides a <success|fail> value, where the unhappy result is a 'std::error_code' or an instance of "your-chosen-error-type". The library further provides 'outcome<T,error-code,exception-ptr>' for handling <success|error|exception> to safely wrap throwing APIs. Documentation: https://ned14.github.io/boost.outcome/index.html ACCU 2017 talk including design rationale: https://www.youtube.com/watch?v=XVofgKH-uu4 GitHub: https://github.com/ned14/boost.outcome Latest tarball: https://github.com/ned14/boost.outcome/releases/ download/boost_peer_review3/boost.outcome-v1.0-source-201705111650.tar.xz Note: Tarball might be easiest; but if you want to clone from GitHub directly, after the clone you should run the following command to get the source zip exactly: git submodule update --init --recursive NEXT WEEK (when the public review is started): Please post your comments and review to the boost mailing list (preferably), or privately to the Review Manager (to me ;-). Here are some questions you might want to answer in your review: - 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 what compiler? 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? And most importantly: - Do you think the library should be accepted as a Boost library? For more information about Boost Formal Review Process, see: http://www.boost.org/community/reviews.html Thank you very much for your time and efforts. --charley

14 92

[outcome] Fix with support for VS2017 Update 1
by Niall Douglas 19 May '17

19 May '17

Earlier today Vinnie Falco found that the peer review edition of Outcome does not compile on Visual Studio 2017 Update 1. I do apologise for this. Update 1 came out a few days before the peer review edition was set in stone. I didn't know it had until now, and I tested against VS2017 RTM, not Update 1. I have applied a fix to develop branch and cherry picked just this fix to the frozen master branch. You can find that fixed peer review edition at this branch: https://github.com/ned14/boost.outcome/tree/master_vs2017_fixed I hope that this does not inconvenience people too much, and once again, sorry. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 3

[offtopic] Who has the power to create Trac accounts nowadays?
by Niall Douglas 19 May '17

19 May '17

Sorry for asking boost-dev, but had no reply on boost-steering. I've got some new GSoC mentors wanting to contribute to https://svn.boost.org/trac/boost/wiki/SoC2017 but they need a Trac login to do so. Who has that power, and can they grant me the power to create Trac accounts as this comes up every year? I'm ned14 on Boost Trac. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 5

Any Projects that need significant contribution?
by GuillermoReyes 19 May '17

19 May '17

Hi all, My name is Guillermo - I am currently looking to significantly contribute to the boost library. In fact, I recently applied for gsoc17. I am willing to work on the nearly antipodal points issue (astroid problem), but am open to contributing to others as well. I have accepted an internship offer, so my time may be limited to part time work. I really want to contribute to the library :) Thanks Again, Sincerely, Guillermo Reyes -- View this message in context: http://boost.2283326.n4.nabble.com/Any-Projects-that-need-significant-contr… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[review] Review of PolyCollection is finished, thanks!
by Ion Gaztañaga 18 May '17

18 May '17

Hi, The review period for PolyCollection has come to an end. Thanks to all participants for submitting their reviews, and sharing their insights. All votes have been positive, so congratulations to Joaquín, PolyCollection will be accepted. I will collect all the suggestions, fixes and change proposals during this weekend and post an official result announcement in a few days. I encourage everyone to continue discussing further issues that can improve the library in the mailing list. Best, Ion, review manager

2 1

[dynamic_bitset] Comparison operators without assertions
by Pavel Kretov 18 May '17

18 May '17

Hi all. Looking through boost::dynamic_bitset code, I found a interesting inconsistency between its operator== and operator<. Namely, the first works well with bitsets of different size, while the second triggers an assertion: boost::dynamic_bitset<> a(std::string("111")), b(std::string("1110")); a == b; // false a < b; // Assertion `a.size() == b.size()' failed. This means that we cannot reliably use dynamic bitset within ordered containers like std::set or std::map. Since the standard library has distinct concepts of equality and equivalence (see [1]), it's fine to have different comparison behaviors in dynamic_bitset. However, as far as I can judge, equivalence is a metaphysically broader concept than equality, we shouldn't restrict it to bitsets of the same size only. So, the questions: 1. May I remove that assertion? (It won't be a breaking change, after all). 2. How about doing the same thing to bitwise operators, too? Instead of throwing an assertion if sizes don't match, it may be worth to generalize the operators definitions. I can see several possible schemes, but not all of them are consistent enough. 3. Shouldn't BOOST_ASSERT be used instead of the one from assert.h? ――― Pavel K. [1]: http://en.cppreference.com/w/cpp/concept/EqualityComparable

8 25

[poly_collection] Memory allocation and allocator propagation
by Ion Gaztañaga 17 May '17

17 May '17

Hi Joaquín, Some additional comments about the design: ///////////////////////// // Memory indirections ///////////////////////// If I understand code correctly, the internal structure of a poly collection is approximately: 1) poly_collection stores an unordered_map<type_index, segment_type> 2) segment_type stores a unique_ptr<segment_backend> and segment_backend_is an abstract class, so roughly equivalent to unique_ptr<packed_segment/split_segment> (both packed_segment/split_segment derive from segment_backend. 3) packed_segment/split_segment stores a vector of concrete types. So we need 3 memory hops to navigate between the "this" pointer of a PolyCollection to a pointer to a concrete type: poly_collection -> unordered node -> segment in unique_ptr -> vector value. I think the data structure could be optimized to save one indirection. segment_type could directly hold the class derived from segment_backend as packed_segment/split_segment will need the same size and alignment requirements regardless of the ConcreteType they hold (as long as they use std::vector). This could improve insertion times and other operations. This optimization could also make easier to fix the following section (allocator propagation). *Main question 1*: Do you find think PolyCollection should implement this optimization? ///////////////////////// // Allocator propagation ///////////////////////// As mentioned in Adam Wulkiewicz's review PolyCollection currently does not propagate the allocator from the constructor argument of poly_collection to the concrete type. From a practical point of view, the key requirement is that all intermediate memory until the concrete type must be allocated using the same root allocator passed when a poly_collection was constructed, and that allocator must be propagated also to the concrete type. I think this should also be the case of all memory used for auxiliary data like the index vector of split_sequence. Clause 23.2.1.3 was mentioned although I don't think this clause was designed with compound containers in mind, as IMHO all auxiliary data, including metadata that needs dynamic memory should receive the allocator and should be constructed using allocator_traits or a container that uses allocator_traits (yes, even the non-value parts of a node). Otherwise, the original intention of the new standard allocator model (use a single source of memory and propagate it transparently) wouldn't be feasible. I think that a unique memory source for all internal structures and the correct propagation of the allocator using allocator_traits is a very interesting feature for PolyCollection. Even Bjarne Stroustrup commented on this when Joaquín's article was published in isocpp ( https://isocpp.org/blog/2014/05/fast-polymorphic-collections-joaquin-m-lope…) "One thing caught my eye: The elements could be allocated using stack allocators, rather than a general new. That would make the technique applicable to hard real-time systems where general dynamic memory is banned" *Main question 2*: Do you think PolyCollection should support stateful allocator using the scoped allocator model? Some specific notes that might show places where the scoped allocator model has problems.: - PolyCollection uses operator new to allocate the packed/split_segment implementation stored in unique_ptr and also when the segment must be copied. If unique_ptr is avoided and the concrete segment is in-place constructed inside "segment" then all memory will be allocated from the original allocator. - I think "segment" is missing an extended copy and move constructor taking an additional allocator. It also would need an internal allocator_type typedef so that uses_allocator_v is true and unordered_map calls these new constructors when needed. These new constructors should be propagated to split_segment/packed_segment so that these call the extended constructors of internal vectors. - The concrete type wrappers (e.g. value_holder) also would need to support allocators with extended copy/move constructors. - The "emplace" operation uses a placement new to wrapped in a lambda which is type-erased with a captureless lambda. It looks to me that instead of delegating the work into the value_holder, the type erasure arguments should be treated by the segment so that internal vectors propagate the allocator when needed. A test to make sure everything is correctly propagated: -> Create an instance of monotonic_buffer_resource passing a big enough static buffer. -> Create a base_collection< Base, std::polymorphic_allocator<Base> > passing the address of the monotonic_buffer_resource -> Insert types Derived1 and Derived2 in the container, both of which hold a vector<int, polymorphic_allocator<int> > (for Derived1 and Derived2 are uses_allocator_v is true and they propagate the memory resource to the vector). -> After filling base_collection, no heap allocation is made and all objects are constructed in the static buffer. Best, Ion

3 8

Re: [boost] Hello Again From Facebook Engineering
by Yurii Zubrytskyi 16 May '17

16 May '17

Hi Scott, I appreciate the email. Things are going great here, and I'm really happy with Google. Anyway, even if I wanted to change jobs I wouldn't consider Facebook until it opens an office on the Eastside - commuting into Seattle is just too uncomfortable, so I'm not considering any company there Thanks! ________________________________ From: Scott Shay <scottshay(a)fb.com> Sent: Tuesday, April 18, 2017 10:03:15 AM To: Yuriy Zubritsky; boost(a)lists.boost.org Subject: Hello Again From Facebook Engineering Hi Yuriy, Sending a note to say hello again from Facebook! My great teammate, Camila, mentioned that I should reach out and see how things at Google have been going for you? Have you had some time to consider what's next in your career? I understand if this is not the right timing, kindly let me know how we can best keep in touch for when it makes more sense. Thanks a lot and I look forward to hearing back from you. P.S. in case you're curious, here's a resource that highlights some of the technical problems we tackle. https://code.facebook.com/ Scott Shay Engineering Sourcer | Recruiting M: (650) 785-6142 [id:image001.png@01D298C9.4BBDBCE0] facebook.com/careers<https://www.facebook.com/careers>

1 0

crc // wrong poly for crc_xmodem_type
by Sergei Nikulov 16 May '17

16 May '17

Hello All, I've discovered that current typedef crc_xmodem_type uses wrong poly. Current release and master branch: > typedef crc_optimal<16, 0x8408, 0, 0, true, true> crc_xmodem_type; Should be (ref: http://reveng.sourceforge.net/crc-catalogue/16.htm#crc.cat-bits.16) > typedef crc_optimal<16, 0x1021, 0, 0, false, false> Develop branch already have some changes which address this error (for ex. https://github.com/boostorg/crc/commit/328bf50f666c463901e2179aa2d890916c3b…) but master and boost release does not. Who currently owns boost::crc and can fix this issue? Thank you. -- Best Regards, Sergei Nikulov

2 2

[Convert] convert<float> doesn't respect input size
by Olaf van der Spek 15 May '17

15 May '17

Hi, const char* a = "42"; boost::string_ref b(a, 1); float c = boost::convert<float>(b, boost::cnv::strtol(), -1); // returns 42 assert(c == 4); https://github.com/boostorg/convert/issues/29 -- Olaf

1 0

Re: [boost] [http] Boost.Http review report
by Vinnie Falco 15 May '17

15 May '17

On Aug 27, 2015 at 12:21 PM, Bjorn Reese <breese_at_[hidden]> wrote: > The outcome of the formal review of Boost.Http is that the library is > NOT accepted for inclusion into Boost this time. > ... > Judging from the reviews, the following additions will > make a future submission more likely to succeed: > > 1. Involve the community more during the development. This will > both solicit earlier feedback on the design, and help to align > community expectation. I've been trying to involve the community for several months now, offering opportunities to weigh in on design decisions, provide feedback on pull requests, perform code reviews on pending merges. The response has been, to put it nicely, minimal. In particular I have not heard from anyone involved in the other proposed libraries such as Boost.Http or cpp-netlib except some initial contacts in early 2016.

2 3

Re: [boost] [review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)
by Bjorn Reese 14 May '17

14 May '17

On 05/11/2017 06:19 PM, charleyb123 . via Boost wrote: > GitHub: > https://github.com/ned14/boost.outcome The code has a "boost-lite" submodule. Is that part of the review?

5 13

Win10 now allows symlink creation without elevated privileges
by Niall Douglas 14 May '17

14 May '17

In case the list didn't know, from the Creator's Update onwards Windows 10 allows normal users to create symlinks if the machine is put into Developer mode: https://blogs.windows.com/buildingapps/2016/12/02/symlinks-windows-10/ I don't know about others, but this will be a major time saver for me at least, I had been using hard links on Windows which are prone to accidental data loss. Niall

5 4

[poly_collection] User-defined polymorphism model
by Ion Gaztañaga 14 May '17

14 May '17

Hi Joaquín and all reviewers, Before we reach the end of the review period, I wanted to comment an (IMHO) interesting feature used in the internal design of PolyCollection. The library offers three of polymorphism models: base-derived, boost::any and signature-sharing callable types. Under the hood, the library abstracts those polymorphic models into a generic class in the detail namespace: template<typename Model,typename Allocator> class poly_collection; and each concrete container is just implemented in terms of poly_collection: template<typename Base,typename Allocator> class base_collection : public detail::poly_collection<detail::base_model<Base>,Allocator> The first template parameter (Model) is the abstraction ("concept") that implements the non-generic part of each polymorphism model. A model implements the following types and operations (comments on each attribute are my interpretation, they can be completely wrong): template<class ModelArg> class Model { // //Value-related attributes // //The type we want to expose as value_type of the container using value_type= ...; //Is T a subtype of the general type (acceptable as value)? template<class T> using is_subtype= ... //Is T the "most refined type"? template<class T> using is_terminal=... //Id of a value template<class T> static const std::type_info& subtypeid(const T& x); //Obtain a type-erased pointer to the value template<class T> static void* subaddress(T& x); template<typename T> static const void* subaddress(const T& x); // //Segment-related // //Segment iterators that point to type_erased value_types using base_iterator=... using const_base_iterator=... //const<->non-const conversions static base_iterator nonconst_iterator(const_base_iterator it); template<typename T> static iterator<T> nonconst_iterator(const_iterator<T> it); //Concrete iterators for Derived template<typename Derived> using iterator=...; template<typename Derived> using const_iterator=... //Generic type, comparable with base_iterator. //base_iterator == the last returned base_sentinel //means that base_iterator points one-past the last //element of a segment. using base_sentinel=...; using const_base_sentinel=... //Construct a segment for type T using the given allocator and //return it type-erased. template<typename T,typename Allocator> static detail::segment_backend<Model>* make(const Allocator& al); }; I have several questions on this polymorphism model. 1) Wouldn't be a good idea to make this model-based polymorphism (or a refined one) public? Maybe the current model needs more work to support additional polymorphism models. Of course requirements for each operation in a model should be detailed. A correct abstraction to define user-provided polymorphism models is hard but this seems really a great feature that makes this library more valuable for users. 2) If understand this model abstraction correctly, each Model chooses the segment type to store values (it could be any sequence type, I guess). The segment_backend abstraction does not only abstract ConcreteTypes from value_types (using void pointers that will be casted to real types in the implementation of the virtual function), but also the segment type (the sequence holding the concrete values). Current implementation uses two segment types: split_segment (stores Concrete types and generic value_type's in two separate vectors) and packed_segment (stores ConcreteTypes which already contain value_type's as a subobject). function_collection and any_collection use the first segment, base_collection uses the second. Why are different segment types needed? Can't we store value_types and ConcreteTypes in a struct and use only one type of segment? If this is possible, I guess iteration performance would be improved for function_collection and any_collection. Model definition could be simplified. On the other hand, if the sequence type can be left out of the model definition, the underlying sequence type (change vector with deque, small vector or any other) could be made configurable. Would this be useful for users? 3) I understand that caching a base_sentinel in each segment is an optimization to avoid a virtual function call when iterating with base_iterators. Is this assumption correct? Why is a different base_sentinel type needed to mark the end of each segment? Wouldn't a "base_iterator" pointing to that on-past-the end position suffice? Is an optimization (maybe base_sentinel is cheaper) or a must have? Thanks, Ion PD: I have more design questions related to other topics but I will post a different thread for each one.

2 2

Re: [boost] [review] Review of PolyCollection starts today (May 3rd)
by Glen Fernandes 13 May '17

13 May '17

Gavin Lambert wrote: > On that note, do you know of a more-comprehensible-than-standardese guide > on how allocator_traits is supposed to be used for node-based custom > container types? I've tried to figure it out a couple times but I'm sure I'm > missing important points. What do you want to know? 1. The storage for the node should be allocated with the Allocator's 'allocate()', for an allocator instance 'a' whose value_type is the containers node type (i.e. 'a' can be achieved by rebinding an existing allocator instance in the normal way). 2. The node object itself would be constructed in the normal way - e.g. placement new to construct the node object. 3. The containers' value_type object within the node must be constructed by allocator_traits<U>::construct(u, p, args...) where u of type U is a rebound copy of the allocator such that the allocator's value_type is the container's value_type. 4. Similar to 3, for destruction of the container's value_type object should be destroyed by allocator_traits<U>::destroy(u, p) 5. Similar to 2, the node object is destroyed in the normal way - e.g. invoking the destructor of the node type. 6. Similar to 1, the storage for the node is deallocated with the Allocator's deallocate() (for an allocator instance whose value_type is the container's node type). Glen

1 0

[poly_collection] Andrzej's review
by Andrzej Krzemienski 12 May '17

12 May '17

Hi Everyone, Some comments from me about PolyCollection library, First, Joaquín, thank you for writing and sharing this library. I am not an an expert in the domain. In my programs I never needed this optimization. But I have seen it described in a number of publications, and I am convinced it deserves a place in Boost libraries, so that people are not forced to reinvent it. [1] Now, because I have no practical experience with the problem, what I say in this paragraph might be incorrect. But I have a problem here. You will use this library for improved performance, maybe for a game implementation, yet because a game needs super-performance, can a programmer afford to use dynamic dispatch, or RTTI or exceptions? I always imagined taht such library, rather than resembling `ptr_vector<I>` would resemble `vector<variant<A, B, C>>`, that is: I decide and fix the container on a set of types I will be storing inside. This set of tyes is embedded in the type, so I can detect many mis-usages at compile time. The implementation can be faster, because the number of segments is fixed (no segment management), and no registration checks need to be performed. Then, iterate over such collection with a static_visitor (from Boost.Variant). Of course, this would be constraining: I need to know all the types I will be using ahead of time. But maybe in practice this is often the case? If you disagree, maybe it is wort discussing it in the rationale. [2] I am not comfortable with per-segment functions having the same name as container-wide functions, and being only overloaded based on function or template parameters, like `cc.size()` and `cc.size(index)`. These two functions do different things, so they deserve different names. Maybe `cc.segment_size(index)`, or `cc.serment(index).size()`? [3] I downloaded it and tried toy examples with GCC 6.3 on Windows with -std=c++11, and clang 3.8.1 on Fedora with -std=c++11. It compiIes fine. I observed that the following small program crashes (assertion fails): ``` #include <boost/poly_collection/base_collection.hpp> struct Iface { Iface() = default; virtual ~Iface() = 0; }; inline Iface::~Iface() {} struct Type1 : Iface { Type1() = default; Type1(Type1&&) = delete; }; struct Type2 : Iface { Type2() = default; Type2(Type2&&) {} // throwing move // no move assignment }; int main () try { boost::base_collection<Iface> c; c.insert(Type1{}); // fires an assert c.insert(Type2{}); // fires an assert } catch (std::exception const& e) { } ``` Admittedly, `Type1` and `Type2` are not "acceptable", but according to the documentation this should throw an exception upon insertion rather than firing assertions. [4] The documentation is good. As to implementation, I did not look at it in detail. Regards, &rzej;

2 2

[poly_collection] Small review
by Pete Bartlett 11 May '17

11 May '17

> > Dear Ion, Joaquin and boost mailing list, > > I hope this brief review is of some value to you. I don’t expect to be a recognised name on the mailing list but have contributed to it intermittently over the years. I have also used the author’s MultiIndex library in production for about a decade. > > I would recommend that PolyCollection be accepted into Boost. > > I think the design pattern is common enough to be Boost-ified. I have done something very similar to boost::base_collection myself in the past and have achieved useful speed ups over a solution like boost::ptr_vector in a production system. My speed-ups were not quite as good as Joaquin documents, but I can’t tell if this was due to the ineptitude of my own solution or due to lab conditions of the Boost.PolyCollection tests. > > I spent a couple of hours reading the docs and running basic examples on my default compiler (VS2015 x64) and did not experience any significant problems. > > It may be worth remarking in the docs (sorry if I missed it) what facilities are used for the type registries that are presumably behind the scenes. From the reference section I think RTTI is required. Is this a hard limit or could Boost.TypeIndex be used? > > NB the reference section has a note “REVIEW THIS DESIGN DECISION” in it. > > Personally I would attach value to the fact that the author has been a great servant to Boost over the years (as have many others) so it is likely that this would be a well-maintained library. E.g. if algorithms were added to <algorithm> in the future, they would likely end up in <boost/poly_collection/algorithm.hpp> too. > > Regards, > Pete >

3 4

[review][poly_collection] Review period EXTENDED until May 17th
by Ion Gaztañaga 11 May '17

11 May '17

Dear boosters, Some have requested a bit of time to extend the review period in order to have time to submit reviews or issue technical comments. With the approval of Review Wizards, the review of PolyCollection is extended until May 17th. Please feel free to submit review and comments. Best, Ion

1 0

[poly_collection] Two remarks
by Dominique Devienne 10 May '17

10 May '17

Just as Pete Bartlett mentioned, I'm also a fan of Joaquín's Multi-Index, which I'm used in production for many years as well. My only complaint about his proposed Poly-Collection is the fact I can't leverage and thus benefit from the performance of it, in a multi-index scenario, but as Joaquín already answered a few months ago, that's off-topic and by design, I know :) Many of my BMIs have a by-type index, and the type-partitioned storage of those in contiguous memory for by-type scans would be (greatly?) beneficial. I'd be willing to give up some iterator guarantees BMI provides, as a node-based container, for intelligent contiguous storage of elements, without myself having to maintain by-value homogeneous containers with a manually maintained BMI of polymorphic pointers to those containers' elements. My second remark is about parallelism. I suspect the new poly_collection could be used for more efficient parallel (and/or concurrent) processing of elements, and would be interested in examples and even a ::parallel_for_each() algorithm that leverages the collection's internal storage. And perhaps even on the write side, rather than having to make the whole container thread-safe, but external mutexing for example, provide ways for a more granular thread-safety by type or segment perhaps. Again, probably off topic, but hardly something you can "add from the outside" I think, and why I mention it here and now. As merely a user of Boost, I don't feel qualified as a reviewer, beyond the two above remarks. Thanks, --DD

5 4