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

Re: [boost] Request for endorsements for mp11
by Bjorn Reese 22 May '17

22 May '17

I endorse mp11.

1 0

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

[build] please review the long standing pull request
by Konstantin Ivlev 10 May '17

10 May '17

Hello, There's a 2 month old pull request https://github.com/boostorg/build/pull/169. Please review and let me know any feedback.

1 0

[Thread] What is the meaning of BOOST_THREAD_USE_LIB?
by Frédéric Bron 09 May '17

09 May '17

Hi, I always use boost as static libraries. For a long time, I have been used to define macro BOOST_THREAD_USE_LIB on windows when cross-compiling from linux to windows with mingw. I have now made a new cross-compiler conformant with pthread (the previous one had only win32 api) but then boost does not build (with threadapi=posix). It seems that not defining BOOST_THREAD_USE_LIB helps. I do not remember why I used to define BOOST_THREAD_USE_LIB a long time ago and cannot find any help in the doc (http://www.boost.org/doc/libs/1_64_0/doc/html/thread/build.html) What is the meaning of BOOST_THREAD_USE_LIB? Frédéric

2 1

gsoc17 and boost.ublas
by Rishabh Arora 09 May '17

09 May '17

Hi Everyone, My name is Rishabh Arora and I have been selected to work with the BoostC++ libraries on the the project, "dataframes in ublas" as a part of GSoC '17. It will be great if someone could provide me with suggestions on how to get started with it. Thank you in advance Best Regards, Rishabh Arora

2 1

[GSOC'17] Project: Optimising Multiplications in uBLAS
by mohammad sharique 09 May '17

09 May '17

Hello Boost Community, My name is Mohd Sharique. I have been selected to work with Boost C++ Libraries under Google Summer of Code '17. My project is "Optimising Multiplications in uBLAS". It would be great if I could get some starting point for the same. Thank you, Your's sincerely, Mohd Sharique

2 1

[integer] Please fix build/test errors..
by Rene Rivera 09 May '17

09 May '17

The Integer library is causing general CI failures: < https://travis-ci.org/boostorg/boost/jobs/230199520#L6396> Please rectify ASAP. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 8

[poly_collection] throws upon insertion
by Andrzej Krzemienski 09 May '17

09 May '17

Hi, I am looking at the documentation of poly_collection. I will not be able to thoroughly review and test the library. But judging from the documentation, the problem is worth solving, and the approach to solve it is sound. I have one question/observation though. I am trying to figure out how preventing an incorrect insert() works. In the docs ( http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collec…) it says that it will sometimes throw if it cannot determine the most derived type. In the class reference, I get: ( http://rawgit.com/joaquintides/poly_collection/website/doc/html/poly_collec… ) ``` (1) c.insert(x) (2) c.insert(it,x) Effects: If the type of the subobject of t is not registered, then if this type is T and T is acceptable, does the registration, otherwise throws. If t is not a non-const rvalue expression and the type of its subobject is not CopyConstructible, throws. Inserts an element with a subobject move constructed or copy constructed from the subobject of t: (1) at the end of the corresponding segment; (2) just before the position indicated by it, if it points to the corresponding segment, or at the end of the segment otherwise. Returns: An iterator to the newly inserted element. Complexity: Amortized constant time plus linear in the distance from the insertion position to the end of the segment. ``` And maybe it is just me, but I cannot make the sense of it. First, it refers to 't' but in the signatures we have an 'x'. Next, the first sentence has two "if"s and one "otherwise" and I do not know which "if" the "otherwise" binds to. I read it as saying: if T is derived from the interface (like class `warrior`) but is not movable (which implies that T is not "acceptable"), then the program will compile fine but will later throw an exception. Is my interpretation correct? But if so, why not refuse to compile instead? Maybe it would be better tom make the prose longer in "Effects" clause, but to make it harder for misinterpretation. Regards, &rzej;

2 3

[Boost.Test] access to boost::unit_test::framework::master_test_suite().{argc, argv} outside from BOOST_TEST
by Olaf Peter 08 May '17

08 May '17

Hello, my test program uses boost.test datasets. I've wrote a filesystem loader for the input and expected data. Now I run into the problem, that boost::unit_test::framework::master_test_suite().{argc, argv} is only setup inside the tests self. My loader isn't a test case ... I can check it by using a simple mock, like struct app_mock { app_mock(); int const argc; char** const argv; }; app_mock::app_mock() : argc(boost::unit_test::framework::master_test_suite().argc) , argv(boost::unit_test::framework::master_test_suite().argv) { } BOOST_AUTO_TEST_CASE( app_mocker ) { app_mock app; std::cout << "Count = " << app.argc << '\n'; for(int i = 0; i != app.argc; i++) std::cout << "Arg = " << app.argv[i] << '\n'; } $ my_test -- my_args Count = 2 path/to/exe my_args these works, but as mentioned: dataset_loader::dataset_loader(fs::path const& path) { app_mock app; std::cout << "ARGC = " << boost::unit_test::framework::master_test_suite().argc << '\n'; read_files(path); } is always zero. How can I read the argc/argv values? Thanks, Olaf

2 4

[gsoc17] welcome Ruoyun
by Vissarion Fisikopoulos 05 May '17

05 May '17

Hi Ruoyun, congrats and welcome! As mentioned by GSoC this is the community bonding period. So you can start reading the documentation: http://www.boost.org/doc/libs/1_64_0/libs/geometry/doc/html/index.html This wiki is also useful: https://github.com/boostorg/geometry/wiki check for example https://github.com/boostorg/geometry/wiki/Contribution-Tutorial We can also start now discussing and refining you project goals. Best, Vissarion. ---------- Forwarded message ---------- From: Google Summer of Code <summerofcode-noreply(a)google.com> Date: 4 May 2017 at 19:35 Subject: GSoC 2017: You are a mentor for Ruoyun Jing To: fisikop(a)gmail.com [image: Google Summer of Code] Congratulations, you will be spending the next few months working with Ruoyun Jing on GSoC2017 Boost.Geometry:Filtering of compare distance predicates Proposal <https://summerofcode.withgoogle.com/dashboard/organization/4839090517180416…> . Please welcome <http://write.flossmanuals.net/gsoc-mentoring/community-basics/> your student into your community and work with them to plan the milestones they will need to meet. Setting clear expectations early is one of the best ways to help your student succeed. You can read the Mentor Manual <http://write.flossmanuals.net/gsoc-mentoring/about-this-manual/> for some great tips on how to communicate with your student and make a project plan. If you have any questions please contact our Google Open Source Programs team at gsoc-support(a)google.com or email the mentors mailing list if appropriate. -Google Open Source Programs team This email was sent to fisikop(a)gmail.com. You are receiving this email because of your participation in Google Summer of Code 2017. https://summerofcode.withgoogle.com To leave the program and stop receiving all emails, you can go to your profile <https://summerofcode.withgoogle.com/dashboard/profile/> and request deletion of your program profile. For any questions, please contact gsoc-support(a)google.com. Replies to this message go to an unmonitored mailbox. © 2017 Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, USA

1 0

[1.64] [ublas] Broken/regession due to Boost.Serialization changes
by Peppard 05 May '17

05 May '17

Hi, since the 1.64 release including e.g. boost/numeric/ublas/matrix.hpp gives an error like "no member named 'make_array' in namespace 'boost::serialization'", according to the official(?) test overview (http://www.boost.org/development/tests/master/developer/numeric-ublas.html) on a lot of systems. There have been discussions on this mailing list in Nov/Dec 2016 probably at least related to this ([boost] [serialization][ublas][test] failures in serialization causing regressions) and in Feb 2017 ([boost] [serialization][uBlas] Serialization still breaking anything that uses uBlas?), also there are several pull requests on GitHub, e.g. https://github.com/boostorg/ublas/pull/46. (I assume you are aware of this already, but I wonder why there was a release with a regression like this, maybe due to a maintainer missing? How are cases like these handled?) Thanks! (Sorry if this is a double post but the list address seemed to change from @wowbagger.crest.iu.edu to @lists.boost.org so I tried again.)

3 2

[beast] 1.0.0-b35 has been merged to master
by Vinnie Falco 05 May '17

05 May '17

Beast 1.0.0-b35 has been merged to the master branch. Changes include: API Changes * New HTTP interfaces This version has a freshly written HTTP parser which improves on the performance of the previous parser. New interfaces are provided to allow incremental reading of HTTP messages and better handling for Expect: 100-continue. These are API breaking changes. Beast is a C++11 header-only HTTP and WebSocket library built on Boost.Asio, scheduled for Boost formal review starting July 1st. Official repository: https://github.com/vinniefalco/Beast Documentation: http://vinniefalco.github.io/beast/index.html Stakeholders and interested parties may review version the pull request for 1.0.0-b36 if desired, all feedback welcomed: https://github.com/vinniefalco/Beast/pull/330 Thanks!

1 0

Boost macros for Android
by Vicente J. Botet Escriba 04 May '17

04 May '17

Hi, I would like to inhibit some failing test on Android. Are there any specific BOOST macros for Android? Best, Vicente

3 3

Test - ignore
by Michael Caisse 03 May '17

03 May '17

-- Michael Caisse Ciere Consulting ciere.com

1 0

GMane reflection of Boost mailing list messages
by Edward Diener 03 May '17

03 May '17

I am a user of GMane in regard to Boost mailing lists and it appears that GMane is no longer picking up Boost mailing list changes or allowing users to respond to mailing list posts through the corresponding GMane ng. Does anyone know how to rectify this situation ? I recall that Boost might have changed who was hosting the mailing lists and I am wondering if this is the reason that GMane no longer works with Boost mailing lists. The GMane website appears to be in transition, and all links for contacting anyone at GMane have been removed. I did try to contact Lars Magne Ingebrigtsen, who has been running GMane, but I do not know if this will produce any results.

4 9

Fwd: [clang] clang-cl expansion of macros
by degski 01 May '17

01 May '17

On 16 April 2016 at 17:58, Edward Diener <eldiener(a)tropicsoft.com> wrote: > What I strongly suspect will finally happen is that clang will not fix > these emulation problems because they are too tricky and numerous to do. > Instead they will probably declare that their emulation is good enough for > the majority of preprocessor constructs and that Boost PP, which pushes the > preprocessor to its limits, is not meant to work with their flawed VC++ > emulation. I hope I am wrong about that supposition, but having spent much > time in Boost PP and Boost VMD trying to workaround VC++ non-standard > preprocessor behavior I can envision that having to code "down" to that > behavior in numerous complicated instances will be too much time consuming > work for the clang developers who have chosen to work with VC++ > preprocessor emulation. > I've successfully built boost-1.64 with VC1410 (from the developer command prompt). Trying to use boost with a project using Clang 4.0.0 (both the LLVM and C2 backends) gives me the following PP error messages: 1>------ Rebuild All started: Project: test, Configuration: Debug x64 ------ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(59,7): error : too many arguments provided to function-like macro invocation 1> 2 1> ^ 1> z:\vc\x64\include\boost/preprocessor/facilities/expand.hpp(26,10): note: macro 'BOOST_PP_EXPAND_I' defined here 1> # define BOOST_PP_EXPAND_I(x) x 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(58,1): error : expected a qualified name after 'typename' 1> BOOST_MPL_AUX_NA_SPEC2( 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/na_spec.hpp(166,44): note: expanded from macro 'BOOST_MPL_AUX_NA_SPEC2' 1> #define BOOST_MPL_AUX_NA_SPEC2(i, j, name) \ 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/na_spec.hpp(64,11): note: expanded from macro '\ 1> 1> BOOST_MPL_AUX_NA_SPEC_MAIN' 1> BOOST_MPL_PP_PARAMS(i, typename T) \ 1> ^ 1> z:\vc\x64\include\boost/mpl/aux_/preprocessor/params.hpp(58,11): note: expanded from macro 'BOOST_MPL_PP_PARAMS' 1> , BOOST_MPL_PP_AUX_PARAM_FUNC \ 1> ^ 1> In file included from test.cpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem.hpp:16: 1> In file included from z:\vc\x64\include\boost/filesystem/path.hpp:28: 1> In file included from z:\vc\x64\include\boost/iterat or/iterator_facade.hpp:12: 1> In file included from z:\vc\x64\include\boost/iterat or/interoperable.hpp:11: 1> In file included from z:\vc\x64\include\boost/mpl/or.hpp:43: 1> In file included from z:\vc\x64\include\boost/mpl/au x_/include_preprocessed.hpp:37: 1>z:\vc\x64\include\boost/mpl/aux_/preprocessed/plain/or.hpp(58,1): error : expected ',' or '>' in template-parameter-list Up till now I was using a hacked boost-1.62. So in order to see what would happen, I also built boost-1.63. Apart from a small change in type_with_alignment.hpp (adding a ckeck for _MSC_VER not to exist if __clang__ does exist in line 87), boost-1.63 compiles without a problem (no specific (relevant to the emulation) command line parameters). Is there a macro I should define or is there something else I should set/do in order to use boost-1.64 with Clang 4.0.0 on windows? Any other suggestions? degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

3 13