- Boost - lists.preview.boost.org

Re: [boost] double_ended - request formal review
by Mathias Gaunard 23 Aug '16

23 Aug '16

On 15 July 2016 at 16:51, Benedek Thaler <thalerbenedek(a)gmail.com> wrote: > Dear Boost, > > I'd like to request the review of the double_ended library. > > Code: https://github.com/erenon/double_ended > Documentation: http://erenon.hu/double_ended > > The library contains two classes. Excerpt from the documentation: > > * `devector` is a hybrid of the standard vector and deque containers, as > well as the small_vector of Boost.Container. It offers cheap (amortized > constant time) insertion at both the front and back ends, while also > providing the regular features of std::vector, in particular the contiguous > underlying memory. In contrast to the standard vector, however, devector > offers greater control over its internals. Like small_vector, it can store > elements internally without dynamically allocating memory. Not related to your request per-se, but I think this occasion is as good as any to discuss the library. devector is an interesting variant of vector, but it gives the illusion that is could be used as a queue. However given the implementation, it seems elements removed from either end will never be reclaimed. I suggest documenting that limitation or having a threshold above which memory is actually freed.

4 5

[CallableTraits] Seeking Review Manager
by Barrett Adair 23 Aug '16

23 Aug '16

Boost Developers, CallableTraits is a C++11/14/17 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal p0172. Library: https://github.com/badair/callable_traits Docs: http://badair.github.io/callable_traits/doc/html/index.html Boost Library Incubator: http://blincubator.com/bi_library/callabletraits-2/?gform_post_id=1574 Current Version: 1.0.1 I've received some great feedback on the mailing list. I consider the current version to be production-ready, which includes excellent cross-platform test coverage and thorough documentation filled with examples. Does anyone wish to be a review manager for this library? It is not a very large codebase, although the implementation is config-heavy and relatively noisy. The Library Submissions page on the Boost website indicates that a library manager should be found before requesting a formal review, but I noticed that there are many "scheduled reviews" that do not have a library manager. May I request a review as well? Thank you, Barrett

3 3

[release] Boost 1.62 closed for major changes.
by Rene Rivera 19 Aug '16

19 Aug '16

Reminder Boost 1.62, i.e. the master branches, are now closed for major changes. The only changes that should be going in at this time should be bug fixes for serious problems. Any documentation changes are fine to go in. And remember... Boost 1.62 will close for all changes a week from today. -- -- 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

[odeint ] Can fix for ticket #12034 be merged into master branch?
by Aparna Kumta 19 Aug '16

19 Aug '16

The fix for Boost ticket #12034 has been in the develop branch for about 6 months now. Could this please be merged into the master branch so it makes it in for Boost 1.62 release? Thanks, Aparna

1 0

[circular_buffer] Synchronize master with develop
by Andrey Semashev 18 Aug '16

18 Aug '16

Hi, I've created this PR to synchronize master with develop for Boost.CircularBuffer: https://github.com/boostorg/circular_buffer/pull/10 Rene has given the permission to merge in the "[boost] [release] Boost 1.62 closed for major changes." thread. I would appreciate if someone with permissions could merge the PR. Thanks.

1 0

Status on Travis
by Raffi Enficiaud 18 Aug '16

18 Aug '16

Hi dear list, Hi Rene, I would like to know more about Travis and its status. From what I understand, a lot of efforts have been made recently for making things running per commit on Travis and have a quick feedback. * Naturally the first question is: is the status given by Travis the "official" one? so we consider the status given by Travis an official source of information, especially wrt. to its competing regression dashboard. * What are the development plans for Travis? Right now I see 3 types of builds, and I do not fully understand what they cover (platform, compiler) nor their differences. * For boost.test, I am testing each feature branch before merging to develop, by 1. cloning boost superproject on develop 2. switching only boost.test to the feature branch This is for preventing the breakages on develop that we observed in the past since several libraries are depending on boost.test. Would it be possible to have that as well on Travis or any continuous CI? That would be per library then. Would it also be possible to have like a template .travis.yml coming from the boost.superproject which can partly be overiden by a library? (if we want to build things slightly differently) * The CI I am using is able to parse the junit files generated by the test framework, and summarizes the information of each build nicely (also tracks the tests history). Is there anything similar in Travis? Right now, apart from looking at the full logs (which is hard), is there any intermediate information than red/green overall status? * I can see many project under the boostorg of Travis https://travis-ci.org/boostorg/ . How do we do that? Thanks, Raffi

3 4

[Beast] Status: HTTP+WebSocket for Boost
by Vinnie Falco 17 Aug '16

17 Aug '16

I’m reporting on the status of Beast, a C++11 header-only library implementing HTTP and WebSocket which is submitted to the boost incubator. The official repository for Beast is at: https://github.com/vinniefalco/Beast It has been a few months since the last update and the number of users measured on GitHub has grown steadily. There is robust, active development with bug fixes and improvements. Unfortunately there hasn’t been much of in terms of attention from the Boost community, no feedback from the incubator was provided. If anyone would like to help out by checking out Beast in the incubator and leaving some comments that would be a tremendous help. Incubator link: http://blincubator.com/bi_library/beast-2/?gform_post_id=1579 The most exciting news is that Beast HTTP and WebSockets have been deployed in the production server environment for the company I work for, Ripple (http://ripple.com) On a side note, my co-worker David Schwartz is giving a CppCon 2016 Keynote speech on the relationship of C++ to public blockchain systems and cryptocurrencies: http://cppcon.org/schwartz-keynote-turner-plenary/ You can see the Beast integration in “rippled”, an open source server application that implements Ripple’s decentralized ledger: https://github.com/ripple/rippled/tree/develop/src/ripple/server/impl I will be doing a 15 minute lightning talk introducing CppCon 2016 conference attendees to Beast. The talk will have 8 minutes of presentation with the remainder of the time allocated for questions (if there are no questions I have additional materials which can be presented). At the conference I would love to meet anyone who is interested in the library or wants to have their questions answered - feel free to reach out to me through my email address vinnie.falco(a)gmail.com (also listed on my GitHub profile) if you’d like to get in contact. Thanks! -- Follow me on Github: https://github.com/vinniefalco/Beast

2 1

[contract] Contracts for constexpr functions
by Lorenzo Caminiti 16 Aug '16

16 Aug '16

Hello all, A couple of the proposals I read on adding Contract Programming to the C++ standard raise the question if contracts should be supported for constexpr functions or not. I tough about this question a bit... but I am still not sure of the answer. I wanted to discuss this topic with this mailing list, especially with respect to what Boost.Contract can currently do. My general impression is that preconditions, postconditions, and class invariants should useful for constexpr functions but noting that: * Probably old values will not be useful in constexpr functions because constexpr prevents its functions from having side-effects (so it seems there will no variable visible outside of the function that the function body can change, and those variables are usually the candidates for making old copies). * Subcontracting will never apply to constexpr functions because they cannot be virtual. For example: struct conststr { // No virtual function so no subcontracting. [[invariant: empty() == (size() == 0)]] // Useful class invariants. [[invariant: data() != nullptr]] template<unsigned N> constexpr conststr(char const (&s)[N]) [[requires: s != nullptr]] // Useful preconditions. : data_(s), size_(N - 1) {} constexpr char back() const [[ensures(result): result == data()[size() - 1]]] // Useful postconditions. // Old values never useful because constexpr has no side-effects? { return data_[size_ - 1]; } constexpr unsigned size() const { return size_; } constexpr bool empty() const { return size_ == 0; } constexpr char const* data() const { return data_; } private: char const* data_; unsigned size_; }; That said, if I understand it correctly, the following are not allowed from within constexpr functions: 1. (Literal) type local variables with non-trivial constexpr destructors (see N3597 and subsequent proposals). 2. Try-catch statements (see N3597 and subsequent proposals). 3. Lambda functions (see N4487). Reading a few proposals, it seems that supporting the above from constexpr functions would be technically possible, but difficult to implement (see N3597 and its subsequent proposals, N4487, etc.). I'm not really familiar with these constexpr restrictions and plans/discussions to relax them in future revisions of the standard... Boost.Contract implementation uses all the above 1-2-3 respectively to: a. Check class invariants and postconditions at function exit (using RAII). b. Catch assertion failures as well as any other exception that might occur while evaluating an asserted conditions and then call the appropriate contract failure handler. c. Conveniently program functors that check pre- and postconditions within the contracted function. Therefore Boost.Contract implementation does not currently support contracts for constexpr functions. --Lorenzo

2 1

'is_palindrome' and 'const char*'
by Зайцев Александр 14 Aug '16

14 Aug '16

Hello. I have some question about some case for 'is_palindrome' algo. 'is_palindrome' algorithm checks a sequence - if sequence is a palindromeor empty, function returns true, in other cases returns false. But in case e.g. "a" (is_palindrome("a")) result is false, because "a" = {'a', '\0'}. And maybe this behaviour is unexpected for users. So... what do you think about it? Should I implement special version for const char* or not? -- Best regards, Zaitsev Alexander

3 4

filesystem 1.61.0 and cygwin: Windows assumed, posix expected
by Frédéric Bron 12 Aug '16

12 Aug '16

Hi, On cygwin, the following program #include <iostream> #include <boost/filesystem.hpp> int main() { auto p = boost::filesystem::path{"foo"}; p /= "bar"; std::cout << p.string() << '\n'; return 0; } outputs: foo\bar but cygwin is a posix system and I expect: foo/bar I read in the doc that "User-defined BOOST_POSIX_API and BOOST_WINDOWS_API macros are no longer supported." So how can I have posix support on cygwin? Thanks, Frédéric

1 1