- Boost - lists.preview.boost.org

[serialization] uuid test_serialization ubsan error
by James E. King, III 01 Feb '18

01 Feb '18

I'm getting a ubsan test error in uuid/test/test_serialization - is the code in that test using archive the right way? testing.capture-output ../../../bin.v2/libs/uuid/test/test_serialization.test/gcc-7/debug/link-static/threadapi-pthread/test_serialization.run ====== BEGIN OUTPUT ====== ../../../boost/archive/detail/interface_oarchive.hpp:47:16: runtime error: downcast of address 0x7ffca0c6fe30 which does not point to an object of type 'text_oarchive' 0x7ffca0c6fe30: note: object is of type 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>' 00 00 00 00 e0 2f 78 8f 48 56 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^~~~~~~~~~~~~~~~~~~~~~~ vptr for 'boost::archive::text_oarchive_impl<boost::archive::text_oarchive>' EXIT STATUS: 1 ====== END OUTPUT ====== Thanks, Jim

3 3

Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
by Andrzej Krzemienski 01 Feb '18

01 Feb '18

2018-02-01 19:13 GMT+01:00 Emil Dotchevski <emildotchevski(a)gmail.com>: > On Thu, Feb 1, 2018 at 2:51 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> > wrote: > >> Boost.Outcome solves the problem decently: you get a compiler error or a >> compiler warning >> > > Do you? What if you have: > > result<void> foo(); > > void bar() > { > foo(); > } > > What compile error will that generate? > "ignoring returned value of type 'outcome_v2_f1696316::result<void>', declared with attribute nodiscard [-Werror=unused-result]" online example: https://wandbox.org/permlink/5vICxckvVG6QO0n1 > Now, in Boost.Noexcept, if the programmer forgets to test for the failure >> (with `try_`), the subsequent function is still executed with the default >> value of type `T` returned from the funciton that failed. Because in >> Boost.Noexcept when function fails it returns a default-constructed `T`. >> > > The idea in Noexcept is that since the function _must_ return something if > there is an error, it returns throw_return<T>() but that is not automatic; > the user still has to say e.g. return throw_(error()). > I understand the constraints you are under. I also acknowledge that this is the best one can do. Nonetheless, I still see the limitation of the solution. If a third party function is returning a type representing a resource, and this type does not provide a default constructor, there is no way to "throw_". You cannot even customize `throw_return<T>()` because what value would you return? You are reporting failure because you cannot acquire the resource. And because it is a third-party interface, you cannot adapt the type. So, in the end, there will be functions where you cannot apply Boost.Noexcept. > > >> And when you check it systematically it is all ok, but then you forget >> (and this is a tedious task), you violate the contracts. No compile-time >> check, no run-time check. >> > > In Noexcept there _is_ run-time check: if noexcept_::has_current_error() > is true at the time a thread terminates, it invokes std::terminate(). Not > ideal, and won't take action if the thread never terminates -- and it may > never terminate because, like in Outcome, if the caller doesn't check at > every function call, the program keeps going. > I was imprecise. you do have a run-time check, but it comes too late: it does not prevent functions to be called with failed preconditions. > > >> I consider this a serious issue. >> > > It is, programmers forget to check for errors all the time. > And Boost.Outcome helps detect these situations at compile-time (of course, at the expense of controlling the return type). > >> And taking into consideration the advantages of Boost.Noexcept you >> mention, I can only conclude that Boost.Noexcept is superior to >> Boost.Outcome in one aspect but inferior in another. >> > > The two libraries solve different problems. > Indeed. > Outcome helps you avoiding exception handling, so it assumes you can > freely use result<T,E> throughout your interfaces. > Well, it can help you avoid exceptions. But it also helps you deal with the lack of exception handling. As you say, the trade-off is that you use `result` in return type. > Noexcept helps you deal with a lack of exception handling, so it assumes > that at least some of the interfaces are beyond your control, and doesn't > impose a return type. > Yes, here the trade-off is, no altering of the return type, but unsafe consequences when you forget to check for "thrown" exceptions. And there must exist a "spare" value in the returned type. There are benefits to using a special return type (to protect against using > an invalid value), but Noexcept leaves that to the user because return > values don't transport errors, just the T; you could e.g. use > std::optional<T>. > And user may not be able to make this decision because he may not be in control of the return type. Regards, &rzej;

1 0

[GSOC18] Boost.Geometry Project 1 : Similarity between geometries
by sagarvijaygupta 31 Jan '18

31 Jan '18

I am Sagar Gupta, a student of IIT Mandi, pursuing my Bachelors in Computer Science. I want to work on the Project 1 of Similarity between Geometries. I read the source code of geometry and regarding the Frechet distance and its different variations and tried to work with it. Also I tried the competency test. Its my first time for GSOC but I have some good experience in C++ (from different projects and competitive programming). I wish to know where should I send the competency test? I wish to work on this project as it is a great learning experience which I realized while working on the implementation of Frechet Distance between linestrings. Thanks and Regards Sagar Gupta -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 2

International Conference on Information Society (i-Society 2018): Call for Submissions!
by International Conference on Information Society 30 Jan '18

30 Jan '18

Apologies for cross-postings. Please send it to interested colleagues and students. Thanks! Call for Submissions! ********************************************************************************** International Conference on Information Society (i-Society 2018) 15-18 July, 2018 Venue: Ballsbridge Hotel Dublin, Ireland www.i-society.eu ********************************************************************************* The i-Society is a global knowledge-enriched collaborative effort that has its roots from both academia and industry. The conference covers a wide spectrum of topics that relate to information society, which includes technical and non-technical research areas. The mission of i-Society 2018 conference is to provide opportunities for collaboration of professionals and researchers to share existing and generate new knowledge in the field of information society. The conference encapsulates the concept of interdisciplinary science that studies the societal and technological dimensions of knowledge evolution in digital society. The i-Society bridges the gap between academia and industry with regards to research collaboration and awareness of current development in secure information management in the digital society. The topics in i-Society 2018 include but are not confined to the following areas: *New enabling technologies - Internet technologies - Internet of Things (IoT) - Wireless applications - Mobile Applications - Cloud and iCloud - Multimedia Applications - Protocols and Standards - Ubiquitous Computing - Virtual Reality - Human Computer Interaction - Geographic information systems - e-Manufacturing - Electronic Discovery (eDiscovery) - Software Applications - Disruptive Technology *Intelligent data management - Intelligent Agents - Intelligent Systems - Intelligent Organisations - Content Development - Data Mining - Data Management Software - e-Publishing and Digital Libraries - Information Search and Retrieval - Knowledge Management - e-Intelligence - Compliance and Recovery from Data Loss - Knowledge networks - Risk Mitigation - Cost Efficiency - Quality Assurance - Information Management - Support Litigation - Complex Investigations *Secure Technologies - Internet security - Web services and performance - Secure transactions - Cryptography - Payment systems - Secure Protocols - e-Privacy - e-Trust - e-Risk - Cyber Security Investigations and Defence - Cyber law - Forensics - Information assurance - Mobile social networks - Peer-to-peer social networks - Sensor networks and social sensing - Information Security Compliance *e-Learning - Collaborative Learning - Curriculum Content Design and Development - Delivery Systems and Environments - Educational Systems Design - e-Learning Organisational Issues - Evaluation and Assessment - Virtual Learning Environments and Issues - Web-based Learning Communities - e-Learning Tools - e-Education *e-Society - Global Trends - Social Inclusion - Intellectual Property Rights - Social Infonomics - Computer-Mediated Communication - Social and Organisational Aspects - Globalisation and developmental IT - Social Software - Smart City *e-Health - Data Security Issues - e-Health Policy and Practice - e-Healthcare Strategies and Provision - Medical Research Ethics - Patient Privacy and Confidentiality - e-Medicine *e-Governance - Democracy and the Citizen - e-Administration - Policy Issues - Virtual Communities *e-Business - Digital Economies - Knowledge economy - eProcurement - National and International Economies - e-Business Ontologies and Models - Digital Goods and Services - e-Commerce Application Fields - e-Commerce Economics - e-Commerce Services - Electronic Service Delivery - e-Marketing - Gig Economy - Online Auctions and Technologies - Virtual Organisations - Teleworking - Applied e-Business - Electronic Data Interchange (EDI) - Innovative Strategies - Business Intelligence - Information Intelligence - Forensic Accounting *e-Art - Legal Issues - Patents - Enabling technologies and tools *e-Science - Natural sciences in digital society - Biometrics - Bioinformatics - Collaborative research *Industrial developments - Trends in learning - Applied research - Cutting-edge technologies - Industrial Control Systems - Communications Compliance * Research in progress - Ongoing research from undergraduates, graduates/postgraduates and professionals SUBMISSION INSTRUCTIONS: * You can submit your abstract, extended abstract or paper online at http://www.i-society.eu/paper-submission/ or email it to papers(a)i-society.eu * You can submit your speaker's proposal via email at speakers(a)i-society.eu or online at http://www.i-society.eu/format/speakers-participation/ * You can submit your poster via email at posters(a)i-society.eu * You can submit your workshop or tutorial proposal via email at workshop(a)i-society.eu or tutorial(a)i-society.eu * You can submit your panel discussion via email at pandis(a)i-society.eu IMPORTANT DATES: *Abstract Submission Date: February 10, 2018 *Notification of Abstract Acceptance / Rejection: February 17, 2018 *Extended Abstract (Work in Progress) Submission Date: February 20, 2018 *Notification of Extended Abstract Acceptance / Rejection: February 27, 2018 *Research Paper Submission Date: March 01, 2018 *Notification of Research Paper Acceptance / Rejection: March 12, 2018 *Camera Ready Paper Due: May 01, 2018 *Proposal for Workshops / Tutorials: February 25, 2018 *Notification of Workshop/Tutorials Acceptance / Rejection: March 01, 2018 *Poster / Demo Proposal Submission: March 01, 2018 *Notification of Poster / Demo Acceptance: March 12, 2018 *Early Bird Registration Deadline (Authors and Participants): April 15, 2018 *Late Bird Registration Deadline (Authors only): May 15, 2018 *Late Bird Registration Deadline (Participants only): May 30, 2018 *Conference Dates: July 15-18, 2018 For more details, please visit www.i-society.euIf you wish to unsubscribe from our newsletter, click http://r.confinfosoc.org/scyaulavbnjg.html

1 0

Interested in applying to the google summer of code
by Laouen Belloli 30 Jan '18

30 Jan '18

Hi, My name is Laouen Belloli, I'm a Computer Science student at Universidad de Buenos Aires currently doing my final thesis in Discrete Events Simulation, this is my 7th and last year on it. In the past I contributed to the cadmium project. This year, I want to join the google summer of code to contribute to Boost. In particular, I would like to work on the Boost.Real project proposed. Best regards, -- Laouen Mayal Louan Belloli. LIAA - DC - FCEyN - UBA. C.A.B.A. - Buenos Aires - Argentina. https://liaa.dc.uba.ar +54 9 11 38675694

2 2

[atomic] (op)_and_test naming
by Andrey Semashev 30 Jan '18

30 Jan '18

Hi, I would like to ask for the community opinion on the naming of the (op)_and_test functions that appeared in Boost.Atomic 1.66. As you probably know, 1.66 included a few new atomic operations, some of which have the name (op)_and_test (e.g. add_and_test, sub_and_test, etc.) These operations perform the (op) on the atomic value and test if the result is zero, so that instead of this: if (a.fetch_sub(1) - 1 == 0) one could write this: if (a.sub_and_test(1)) Also, the generated code for these operations can potentially be more efficient. Recently I received this request: https://github.com/boostorg/atomic/issues/11 which basically asks to change the result of the functions to the opposite. I can see that the current naming could be confusing, especially given that other operations like bit_test_and_set return the previous bit value (i.e. true if the bit was 1). That would be a breaking change, but the new operations were announced as experimental in the release notes, so if there is consensus that the result should indeed be changed, I'm ready to comply. Another solution is change (op)_and_test naming to something else that is more clear. In that case I could deprecate the (op)_and_test variants and provide the functionality under the new names. I would welcome suggestions for a better naming scheme, if you feel this is the right way. My only ask is that the new names be concise, if possible. Lastly, if you think the current naming is fine or there is another way to resolve the confusion, please comment as well. I would appreciate your opinion in any case. Thanks.

5 29

[review] Outcome v2: Review Period Concluded (Fri-19-Jan through Sun-28-Jan, 2018)
by charleyb123 . 29 Jan '18

29 Jan '18

Hi, Everyone-- The Boost Review Period for the formal review of Niall Douglas' Outcome (v2) library is concluded (having run Fri-19-Jan through Sun-28-Jan, 2018). Reviews were posted from: - Vinícius dos Santos Oliveira (Fri-26-Jan-2018) - Andrzej Krzemienski (Fri-26-Jan-2018) - Bjorn Reese (Sun-28-Jan-2018) - Daniela Engart (Sun-28-Jan-2018) - John P Fletcher (Sun-28-Jan-2018) In addition, online discussions included comments, observations, and critiques from a number of other community participants. It will take some time to review the discussion, make a final determination, and prepare the Review Report. Please: - Contact me (directly or on-list) if I missed identification of your review during the review period; - Contact me (directly or on-list) if you have any concerns; or to raise any salient observations or "final thoughts" Thank you! --charley Boost.Outcome(v2) Review Manager

1 0

[gsoc18] Interested in adding statistics and machine learning functions to Boost.uBLAS and Seeking for mentors
by Kanch 29 Jan '18

29 Jan '18

Dear community: My name is Long Zhang,currently in my third year of college. As subject suggests, I'm interested in adding statistics and machine learning functions to Boost.uBLAS library. I've basic knowledge of statistics (which I have been thought in school) and Machine Learning, I learned Machine Learning by Andrew Ng on Coursera, and I have tried to implement algorithms like PCA,LDA,K-means in Python, therefore, I think it won't be a problem if I have to implements it in C++. BTW, I have use C++ since my Senior High. Except components mentioned in wiki, I think I can also implement algorithms like KNN,Logistic Regression, even SVM during the summer. I also understand the efficiency of these algorithms is what matters, I will try hard to implement it as fast as it can. I know I have do some kind of programming competency test. When should I start? I mean I haven't find a mentor, don't know who should I contact if I finish the test. Can someone mentoring me? We can then talk about the test and code I used written in C++(open source code in C++) to check if I'm qualified to this project. Thank you. Best, Long -- Best regards, *Long Zhang (Kanch) <http://akakanch.com> *＠ Chengdu University of Information Technology 2015 Computer Science Major Mail:kanchisme@gmail.com No.24 Block 1, Xuefu Road, Chengdu, Sichuan, China

2 2

[outcome] Formal review
by Bjorn Reese 29 Jan '18

29 Jan '18

I. DESIGN --------- Boost.Outcome provides a useful alternative / complement to exceptions, and its design is clean. I like naming of functions with wide and narrow contracts. I suggest that result<> is renamed to basic_result<>, which will then be the customizable template class, and result<> then becomes as specialzation (template alias) that does the same as the current default result<>. This makes result<> an uncustomizable companion to std::error_code, which is useful when defining interoperable APIs. One design decision that I disagree with is the choice of sum types rather than product types for internal storage. I would rather have a lower run-time footprint at the expense of increased compile times. II. IMPLEMENTATION ------------------ Looks readable and solid. There may be an overemphasis on constexpr; I would rather have had support for C++11. BOOST_OUTCOME_TRY_UNIQUE_NAME generates identifiers starting with __t but according to the C++ standard [lex.name/3.1] "each identifier that contains a double underscore __ [...] is reserved to the implementation for any use", where implementation means the C++ compiler. III. DOCUMENTATION ------------------ The documentation is well-written, with a tutorial that is easy to understand. The API Reference could be improved though. 1. What are the requirements for ValueOrError? Looking up ValueOrError brings us to convert::value_or_error, which only states that it "matches the ValueOrError concept." The rather convoluted enable_if uses ValueOrError<U> which uses detail::ValueOrError<U> and here the trail disappears. The convert.hpp header file does contain the missing explanations though. 2. What are the requirements for EC and EP? EC and EP are used informally throughout the documentation, but are described in the Custom Payloads tutorial. In the API Reference they are suddenly called S and P instead. Please use a consistent naming throughout the documentation; preferably using more descriptive names, such as OutcomeErrorCode and OutcomeExceptionPtr. It would furthermore be helpful if they were described as concepts outside the tutorial. 3. The descriptions of value_type_if_enabled and error_type_if_enabled are obscure, and it is still not clear to me if they have any relevance for the library user. If they do, then their descriptions should be more clear; if they do not, then they should not be included in the documentation. 4. The documentation of OUTCOME_TRYX contains the full macro implementation which is not really helpful to users. This macro could possibly be expressed in terms of other macros. 5. noexcept('hidden') is used in several places. Does this mean that the noexcept condition is unspecified? If so, then it is more customary to use "unspecified" in italic. IV. MISC -------- I spent 4-5 hours reading the documentation and looking at the code. I did not compile it. V. VERDIC --------- I vote for the conditional acceptance of Boost.Outcome. The conditions are: 1. The documentation should be integratable into the Boost infrastructure. 2. People must be able to submit patches to the Boost version of the library without having to convert those patches to the standalone version.

2 1

Fwd: Fwd: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
by degski 28 Jan '18

28 Jan '18

---------- Forwarded message ---------- From: degski <degski(a)gmail.com> Date: 28 January 2018 at 17:11 Subject: Re: [boost] Fwd: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018) To: Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> On 28 January 2018 at 16:44, Vinícius dos Santos Oliveira < vini.ipsmaker(a)gmail.com> wrote: > Can you elaborate on your point? If I'm left alone I'll miss your point. > I was mostly just responding to your example (which you asked me to do), and how I would do that, without having to deal with exceptions and/or outcomes. But, the more general point is, which Spirit in this case does very well, is to deal with potential problems at the source, in an explicit (comprehensive) way, without propagation of errors or exceptions. > It's becoming confusing the more you go. > It's probably because I'm rowing against the tide here. degski

2 1

Fwd: [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018)
by degski 28 Jan '18

28 Jan '18

Accidentally sent privately, forwarded below: ---------- Forwarded message ---------- From: degski <degski(a)gmail.com> Date: 28 January 2018 at 15:46 Subject: Re: [boost] [review] Review of Outcome v2 (Fri-19-Jan to Sun-28-Jan, 2018) To: Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> On 28 January 2018 at 14:10, Vinícius dos Santos Oliveira < vini.ipsmaker(a)gmail.com> wrote: > 2018-01-28 12:12 GMT-03:00 degski via Boost <boost(a)lists.boost.org>: > >> 1. Use of outcome is more manual and cumbersome, i.e. more error-prone. >> > > What is complex about the following? > <snipped the code> I'd just use boost::cnv::spirit and specify explicitly what happens when conversion didn't work... much shorter, very well optimized (the best) when it does work (the conversion)... > Server side code... > There's more than servers in life. Handling f.e. O-O-M-situations is not gonna help me on my lap-top... a re-think and re-write of my app is in this case in order, though... or a trip to the shop and buy a bigger stick (both the "slow path"). > If the error is exceptional or not, it depends on context, not on the > algorithm (e.g. connection failure on game client code and game server code > and both of them being backed up by the same functions). Boost.Outcome > let's you do just that by converting an error into an exception. > Yeah, that's another discussion, isn't it? errors vs. exceptions. Should exceptions be exceptional, or getting back to your conversion example, should we use exceptions to indicate failure as this is the case in Boost::Lexical_cast? I know the answer I like best, and moved on to Boost.Spirit. degski

2 3

[spirit-x3]What's use case for x3::variant<OnlyOneComponent>?
by Larry Evans 28 Jan '18

28 Jan '18

Since: http://www.boost.org/doc/libs/1_65_0/libs/spirit/doc/html/spirit/qi/quick_r… doesn't mention a unary variant: variant<A> and the comments in: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/q… indicates variant<T> is collapsed to T, why isn't the x3::variant here: https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x… declared as: template <typename L, typename R, typename ...Types> struct variant instead of: template <typename ...Types> struct variant which allows sizeof...(Types)==0 instead of the minimum size of 2? That would disallow the primary and factor using's here: https://stackoverflow.com/questions/43791079/x3-linker-error-with-separate-… which make no sense because, for example, primary_def is *not* an alternative parser. -regards. Larry

1 0

Google Summer of Code with Boost
by David Bellot 28 Jan '18

28 Jan '18

Hi everyone, still a few days before we submit our proposal to Google. Don't loose the chance to become a mentor for Boost. It shines on your CV, it is a great opportunity to work with brilliant students around the world, it makes you an official C++ world-wide expert. So far, we have a nice but little list of proposals here: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 It would be good to have a bit more before I go and submit to Google. This will increase our chances to be selected again this year. For Boost it's a great funding worth several thousand of dollars every year. We just don't want to miss it. Best regards, David

2 7

[gsoc18] New Astronomy Library
by Pranam Lashkari 28 Jan '18

28 Jan '18

Boost has developed many libraries which is useful in the field of science. I would like to propose a library for "Astronomy" as a student. I have been an amateur astronomer since last 8 years and being a Computer Engineering student I will be able to develop this library with little mentoring. I have some ideas about what can be integrated into it, which I can propose if the proposal seems promising. If so are there anyone who can help me out with this and mentor me? Thank you, Pranam Lashkari

4 18

[gsoc18] ublas project 3
by Aperjump 28 Jan '18

28 Jan '18

I'm Wei Wang, a CS master student focusing on high-performance computing field. `boost::ublas` project 3 adding GPU computation interests me a lot and I'd like to help add this feature to ublas. I find this project was also on last years' list and I'm curious if anyone did this before or on which stage he/she has finished. I've already read the initial source code of `ublas` in `boost 1.29`(I also read 1.66 API, and found it add one concept `container`, which used to be `bounded_array` and `unbounded_array`). I wrote a passage describing its template parameter deduction relationships. Besides, I wrote a series blogs teaching how to use openCL efficiently with proper data partition and memory usage. This is my first time participating in GSOC, and I'm a bit of confused on following question: 1. Integrating openCL requires preparing for context, command_queue, event and other "environment objects", should they also be included in this lib? 2. Take matrix matrix multiplication A*B for example. The last stage before matrix copy assignment is in `matrix_matrix_prob` class and its evaluation requires loop through all items on both matrix. If I want to add GPU compute features, I need to launch kernel for each computation expression at this step, but it seems to be contradictory to `ublas`'s lazy evaluation rationale. How to reconcile that? 3. What should I implement in the competency matrix class? Just integer matrix or template matrix class?Should I support current `ublas` interface(those typedefs and traits)? Best regards, Wei Wang -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 1

Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2
by Glen Fernandes 28 Jan '18

28 Jan '18

I wrote a .travis.yml for your boost-outcome submission to run your unit tests against a few compilers: The output is at: https://travis-ci.org/glenfe/ned14.outcome/builds/334222400 I updated it to make sure the clang++-libstdc++ uses a more recent libstdc++. It looks like: - clang++-libc++ fails because of forgetting to #include a header. - GCC 7.2 with -std=c++17 is the one with the Internal Compiler Errors (I didn't investigate further) - clang++5-libstdc++ fails because it cannot find a type in std Is there a reason why you don't have travis and appveyor for boost-outcome? I remember your "Best Practices" document strongly advocating that every Boost library submission should have them. Glen

3 13

Re: [boost] [review] outcome broken on clang/libstdc++ (Linux) and Apple clang/libc++ and gcc 7.2
by Glen Fernandes 27 Jan '18

27 Jan '18

On Sat, Jan 27, 2018 at 4:55 PM, Glen Fernandes wrote: > I just tried boost-outcome unit tests with clang 4.0, 5.0 on Linux > with libstdc++ with -std=c++14 and -std=c++1z which fails with many > errors: > > e.g. [snip] > In file included from > libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:34: > libs/outcome/test/tests/../../include/boost/outcome/detail/../success_failure.hpp:54:42: > error: no template named 'conditional_t' in namespace 'std'; did you > mean 'conditional'? > template <class T> using devoid = > std::conditional_t<std::is_void<T>::value, void_type, T>; > ~~~~~^~~~~~~~~~~~~ > conditional > /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1780:12: > note: 'conditional' declared here > struct conditional > ^ > > > Then I also tried the boost-outcome unit tests with Apple clang 8.1.0 > with libc++ with -std=c++14 and -std=c++1z which fails with errors > like: > I pasted the wrong error output here; the right error output is: clang-darwin.compile.c++ bin.v2/libs/outcome/test/core-outcome.test/clang-darwin-4.2.1/debug/cxxstd-14-iso/tests/core-outcome.o In file included from libs/outcome/test/tests/core-outcome.cpp:30: In file included from libs/outcome/test/tests/../../include/boost/outcome/outcome.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/outcome_exception_observers.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:35: libs/outcome/test/tests/../../include/boost/outcome/detail/value_storage.hpp:181:22: error: no matching constructor for initialization of 'value_type' (aka 'boost::outcome_v2::outcome<int, std::__1::error_code, std::exception_ptr, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::__1::error_code, std::exception_ptr> >') new(&_value) value_type; // NOLINT ^ libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:270:11: note: in instantiation of member function 'boost::outcome_v2::detail::value_storage_nontrivial<boost::outcome_v2::outcome<int, std::__1::error_code, std::exception_ptr, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::__1::error_code, std::exception_ptr> > >::value_storage_nontrivial' requested here : _state(std::move(o._state)) ^ > Is this also a known issue? Only gcc 6 and gcc 7 with lisbtdc++ on > Linux seem to pass. The other combinations I tried (clang + lisbtdc++ > on Linux, Apple clang + libc++) do not. > I spoke too soon, here gcc 7 does not pass. It ICEs: libs/outcome/test/tests/../../include/boost/outcome/detail/result_value_observers.hpp:45:17: in constexpr expansion of ‘((boost::outcome_v2::detail::result_value_observers<boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >, int, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >*)this)->boost::outcome_v2::detail::result_value_observers<boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >, int, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >::<anonymous>.boost::outcome_v2::detail::result_storage<int, std::errc, boost::outcome_v2::policy::error_code_throw_as_system_error<int, std::errc, void> >::result_storage<int>(boost::outcome_v2::in_place_type_t<int>(), <anonymous>)’ libs/outcome/test/tests/core-result.cpp:330:41: internal compiler error: in adjust_temp_type, at cp/constexpr.c:1206 constexpr result<int, std::errc> a(5), b(std::errc::invalid_argument); [...] 0x6db788 cxx_eval_constant_expression ../../src/gcc/cp/constexpr.c:4034 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <file:///usr/share/doc/gcc-7/README.Bugs> for instructions. Let me know if you need more context, but it appears boost-outcome is also broken on gcc 7.2. Glen

2 1

Re: [boost] [review] outcome broken on clang with libstdc++ (Linux) and Apple clang with libc++
by Glen Fernandes 27 Jan '18

27 Jan '18

On Sat, Jan 27, 2018 at 3:07 PM, Niall Douglas wrote: > b2 libs/afio/test works fine with VS2017. So it would seem that that ICE > Vinnie encountered is some weird corner case nobody could have > anticipated. As I mentioned, almost all of the development of Outcome > was done on MSVC. It's very well tested on MSVC, and I've never seen > anything like that ICE before. I just tried boost-outcome unit tests with clang 4.0, 5.0 on Linux with libstdc++ with -std=c++14 and -std=c++1z which fails with many errors: e.g. In file included from libs/outcome/test/tests/comparison.cpp:35: In file included from libs/outcome/test/tests/../../include/boost/outcome/outcome.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/outcome_exception_observers.hpp:34: In file included from libs/outcome/test/tests/../../include/boost/outcome/detail/result_storage.hpp:34: libs/outcome/test/tests/../../include/boost/outcome/detail/../success_failure.hpp:54:42: error: no template named 'conditional_t' in namespace 'std'; did you mean 'conditional'? template <class T> using devoid = std::conditional_t<std::is_void<T>::value, void_type, T>; ~~~~~^~~~~~~~~~~~~ conditional /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/type_traits:1780:12: note: 'conditional' declared here struct conditional ^ Then I also tried the boost-outcome unit tests with Apple clang 8.1.0 with libc++ with -std=c++14 and -std=c++1z which fails with errors like: clang-darwin.compile.c++ bin.v2/libs/outcome/test/outcome-int-int-1.test/clang-darwin-4.2.1/debug/cxxstd-14-iso/outcome-int-int-1.o libs/outcome/test/compile-fail/outcome-int-int-1.cpp:12:26: error: no matching constructor for initialization of 'outcome<int, int, int>' outcome<int, int, int> m(5); ^ ~ libs/outcome/test/compile-fail/../../include/boost/outcome/outcome.hpp:222:31: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const boost::outcome_v2::outcome<int, int, int, boost::outcome_v2::policy::all_narrow>' for 1st argument class BOOST_OUTCOME_NODISCARD outcome ^ Is this also a known issue? Only gcc 6 and gcc 7 with lisbtdc++ on Linux seem to pass. The other combinations I tried (clang + lisbtdc++ on Linux, Apple clang + libc++) do not. Glen

1 0

Re: [boost] [review] outcome broken on MSVC, plus questions
by Glen Fernandes 27 Jan '18

27 Jan '18

Hi Niall, Still working on the review; I had the following questions while reading the threads: 1. Which versions of MSVC 2017 does boost-outcome not work on, right now? 2. According to the documentation, outcome and boost-outcome both require MSVC 2017, right? i.e. They do not support MSVC 2015 or lower? 3. Is standalone outcome fine with MSVC2017, only boost-outcome that is broken? 3.1. If so, is it right that the boost-outcome repository is "generated" from the outcome repository? And is that the reason that boost-outcome is broken on MSVC 2017? 4. Would you happen to know how does your outcome/result compare to Peter's outcome/result in variant2? (I saw you point out that Peter implemented expected, and then I saw he also had an outcome/result implementation in variant2). 4.1. What different compilers and standards does his support compared to yours? 4.2. What kind of code is generated from his implementation compared to yours? Thanks, Glen

3 2

[outcome] Purpose of value_type_if_enabled?
by Bjorn Reese 27 Jan '18

27 Jan '18

Are value_type_if_enabled and error_type_if_enabled supposed to be used by the library users? If so, how?

2 1

[spirit]why x3::alternative::parse not short-circuited?
by Larry Evans 27 Jan '18

27 Jan '18

https://github.com/boostorg/spirit/blob/develop/include/boost/spirit/home/x… shows both left.parse *and* right.parse are called. Shouldn't right.parse be skipped if left.parse succeeds?

1 1

[outcome] Andrzej's review
by Andrzej Krzemienski 27 Jan '18

27 Jan '18

Hi Everyone, This is my review of Boost.Outcome v2. The library should be *accepted* subject to conditions that I list down below. What is your evaluation of the design? Clean and logically divided. What is your evaluation of the implementation? > Some bugs aside, it is clean and well structured. I was able to read it and understand how things work. I will be filing bugs in GitHub. What is your evaluation of the documentation? > Good. You can get the idea what the library is doing and how you can use it. But I should mention that I wrote some pieces thereof, so my opinion is likely biased. The docs need some modifications before they can get into Boost. I mean macro names, and the technology required to build it. What is your evaluation of the potential usefulness of the library? > I find the library very useful in certain domains. I myself have found two applications in my job project, and they are not really related to light-speed efficiency: 1. We have a task scheduling framework built atop ASIO, and signalling failures through exceptions makes the code really difficult to read because try-catch blocks need to work as control statements. Also, we cannot pass them by exception_ptr as sometimes we need to classify the kind of failure to determine if we want to deal with it in the framework, or if we want to forward them to the user. 2. I have a validation routine that validates (and parses) the input data written using some syntax. I wan the syntax-errors in input files to be forwarded as failed `result`s (no exceptional about these), but other errors like memory shortage during the file parsing to be signaled via exceptions (and I will probably kill the module in response). Why accepting this library when we have `expected` being standardized? I do not really mind having two in Boost. First, it is ready, being proposed, and applied in a number of non-trivial code-bases. Niall claims that his trade-offs are better tailored to predictable-latency applications. I do not have enough knowledge to asses it. They look convincing. The only way to test it is to give this library the Boost blessing and have the user test it. I am bought by the TRY operations, and the upgrade to `outcome` looks really convincing. Did you try to use the library? With what compiler? Did you have any > problems? > Yes. A lot of compilers. For instance GCC 6.4.0, also different GCC and Clang versions in WandBox. No problems encountered. How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > I have read most of the final implementation. I have read many versions of the documentation. I have spent a lot of time (prior to the review) asking Niall lots of questions about the details. I have also built lots of small examples to test the library and some corner cases. Are you knowledgeable about the problem domain? > I do report failures (by different means) in my programs. I have given it quite some thought. I am well familiar with implementation and formal specification of `boost::optional` and `std::optional` which had to address some similar implementation problems. Do you think the library should be accepted as a Boost library? > Yes, conditionally. Here are three conditions: 1. Documentation is adjusted to use boost-standard names of macros and namespaces. Also, it is not clear if Boost release process is capable of handling the technology that Niall has chosen. If not, the contents of documentation should be migrated to another format, manageable by Boost release process. 2. Because there has been some confusion around the meaning of storing default-constructed `std::error_code` (is it an error or lack thereof?) and `std::exception_ptr` (e.g., see this issue: https://github.com/ned14/outcome/issues/115) I request that you state in the docs, before the API Reference how library treats default-constructed values of `EC` and `EP`. For instance, you can say "default-constructed error_code is considered an error, and treated as such by the library", or "the library sometimes may make use of the fact that a default-constructed EC/EP is not an error, so make sure not to pass us such values": I am fine with any answer, but I need you to spell it out, so that I know what to expect. 3. Similarly, I request that you put in the docs what is the "value" of an object of type `outcome<>` or `result<>` in the sense in which John Lakos talks about "salient attributes". I know that T, EC, and EP constitute the value. But in the middle of the tutorial we learn that apart from these you also store "spare_storage" -- is it also included in copying and comparisons? API reference on `operator==` only says "compares if two objects are equal", but it is not that clear what it means. Also, what does it mean that result is equal to optional. Define it somewhere and paste links to it. Finally, I wan to thank Niall for his now many-year effort to deliver this really cool library to the community. Regards, &rzej;

4 7

Re: [boost] [review] Outcome: internal compiler error
by Vinnie Falco 27 Jan '18

27 Jan '18

On Thu, Jan 18, 2018 at 2:07 PM, charleyb123 . via Boost <boost(a)lists.boost.org> wrote: > GitHub: > *- https://github.com/ned14/boost-outcome > > 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: I have put together the following sample program to test integration of Outcome into Boost.Beast: #include <boost/outcome.hpp> int main(int argc, char** argv) { } The result of compilation for this translation unit is shown here: 1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507) Compiler used: MSVC Part of: Microsoft Visual Studio Community 2017 Version 15.5.1 Upon investigation, I discovered a newer version of the compiler and IDE. Updating to "Version 15.5.5" produced the following results when compiling the same translation unit: 1>c:\users\vinnie\src\boost\boost\outcome\detail\value_storage.hpp(141): 1>fatal error C1001: An internal error has occurred in the compiler. 1>(compiler file 'msc1.cpp', line 1507) Is this a supported configuration? Thanks

3 4

[review] outcome
by Vinícius dos Santos Oliveira 27 Jan '18

27 Jan '18

That is my review of Boost.Outcome. What is your evaluation of the design? Niall did an excellent job weighting trade-offs and coming up with such an pleasant and convenient interface that not only is convenient, but it has customization points in the appropriate layers to fit not-close-to-trivial use cases. I've read the changes between v1 and v2 and I agree with the rejection reasons of previous version (the v1's null state specially made little sense at all). Version 2 is a very realistic and solid project. It might seem teasing to just port abstractions from functional languages to C++ (e.g. Expected), but C++ is its own beast and we cannot just ignore some features that we have been dragging all along like exceptions if we expect to have any realistic usage in the real world. Niall's intuition on how to weigh trade-offs was outstanding and just proves his C++ familiarity and expertise. In special, default actions/behaviours could only be defined by intuition of some experienced programmer and not "mathematically". What is your evaluation of the implementation? I did not check the implementation. What is your evaluation of the documentation? Very well written. The tutorials are excellent-quality. The use cases and examples were chosen in such a way that it was intuitive to understand why/when Boost.Outcome and not Expected. I noted a few small problems, but they were reported already. The comments on the example codes were seemingly foreseeing ahead enough about "pumping doubts" so that my mind would calm down and actually pay attention to the documentation instead doing mind exercises trying to guess the non-point of the example. I wish I had this skill. What is your evaluation of the potential usefulness of the library? Very useful. Error handling is a core constant in any programming activity. Introduction of Boost.Outcome could potentially remove duplication of throwing and non-throwing APIs. I personally prefer Expected with its monadic operations, but it is unrealistic to ignore exceptions in many code bases and I'd certainly go for Boost.Outcome in these cases. Did you try to use the library? With what compiler? Did you have any problems? Yes. The one-header version of the library made testing incredibly easy. No problems. Clang 5.0.1. How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? A few hours over a span of a few days. I've tried to examine documentation carefully and end up sending a pull request and a few comments to ask for further changes. I've read all threads that came up during review. I also tested the library when in doubt. Are you knowledgeable about the problem domain? I worked for more than one year under contract using the Rust programming language and Boost.Outcome is pretty much the error system we have in Rust (with some C++-ification and an experienced C++ unique programmer "intuition" to also cover exceptions... and w/o monad ops, of course). Do you think the library should be accepted as a Boost library? Yes. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 1

[config] Positive feature macros, r2
by Peter Dimov 26 Jan '18

26 Jan '18

I'd like to revisit the topic of Boost.Config feature macros, specifically that in my opinion, positive feature macros (BOOST_CXX17_FEATURE) make more sense than negative macros (BOOST_NO_CXX17_FEATURE) in the current environment. Negative macros made sense in the past when they signified bugs and deficiencies in the compiler as measured against a static standard. Nowadays, the standard, such as it is, is in constant motion and macros indicate merely a current state of development for both the compiler and the standard. The arguments for positive macros are the same as last time: - adding a new negative macro requires changes to all legacy compilers that do not and will never implement the feature; a positive macro only requires changes to active compilers. - positive macros are a better match for the standard feature macros, which are positive. When we see a standard feature macro being set, we typically would set ours as well. This means that the amount of changes required to add a new macro is further reduced; we only need to touch compiler-specific config files if the compiler either does not implement feature macros, or sets them incorrectly (in our considered opinion.) TL;DR we should switch to positive feature macros in Boost.Config, and delaying this switch just accumulates more unnecessary code in Boost.Config.

7 13

[gsoc18][ublas] Proposal to add advanced matrix operations
by SHIKHAR SRIVASTAVA 26 Jan '18

26 Jan '18

Hi everyone, I am a 4th year undergraduate student pursuing a degree in Computer Science and Engineering. I have strong programming experience in C++ through internships, self projects and programming events. I wish to be a part of gsoc18 under boost and am particularly interested in the linear algebra library Boost.ublas. The ublas library can be made more useful for Machine Learning applications like recommendation systems, clustering and classification, pattern recognition by adding some operations required in those. I propose to add advanced matrix operations to ublas including - 1. Triangular Factorisation (LU and Cholesky) 2. Orthogonal Factorisation (QR and QL) 3. Operations to find Singular Value lists 4. Eigenvalue algorithms 5. Singular Value Decomposition (SVD) 6. Jordan Decomposition 7. Schur Decomposition 8. Hessenberg Decomposition This is a very brief description of what I would like to propose. Any suggestions that help in refining the requirements before making a draft proposal would be great. Regards Shikhar Srivastava Github: https://github.com/shikharsrivastava

7 12

[outcome] success-or-failure objects
by Vinícius dos Santos Oliveira 26 Jan '18

26 Jan '18

I'm liking what I saw so far. Just a small comment on the documentation. I'm curious what the following sentence does even mean? Is it supposed to confuse the user or something? It's a sign of bad taste really. >Outcome’s default is to not provide value-or-error objects. It provides success-or-failure objects. What does that even mean? value-or-error... well, if it is non-error, I assume it is success. Both sentences mean just the same. As do their API (encapsulate either A or B). The rest of the paragraph is okay. If you just remove this comment, confusion will go away. No other changes need to be done in this paragraph. Just remove this misleading means-nothing comment. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

[Root Pointer] Deterministic C++ memory manager (update)
by Phil Bouchard 26 Jan '18

26 Jan '18

Greetings, I wanted to give an update to the community regarding the memory manager I wrote called: Root Pointer. I now have a working template to solve all memory leaks in C++ and C but both requires some meta data generator. The code can be found here; it is working but not polished: https://github.com/philippeb8/root_ptr In this code we can find: - node_ptr: main class of the smart pointer / memory manager. - root_ptr: generic derived class that includes an "iterator" and a pointer to the name of the instance (for debugging purposes). Also I commented some code that logs the exact location of the memory leak. Furthermore I would like to bring some observations that I found in the C and the C++ language: - Pointers and iterators are not the same; i.e. pointers should point to allocated blocks only and shouldn't have arithmetic operators while iterators shouldn't be used to deallocate anything. - C pointers can only point to dynamic arrays (size known at run-time). - C++ pointers can point to both inherited objects and static arrays (size known at compile-time). This creates a problem (see attached: array_inherited_pointer.cpp). - std::array<T> should have constructors with T objects that have no default constructor. Lastly, before I submit anything, I will have to propose a way to apply a template function to all non-static member variables of a class. This will require implicit meta data generation. This idea is not new as other libraries such as Qt is based on meta data and they certainly could make us of this. For the moment I have a parser that does the job correctly by specializing a boost::proxy() template function but eventually this will have to be integrated into the standards. Hopefully this is an important milestone! Regards, Phil Bouchard www.fornux.com

2 5

clang-format file
by Damian Vicino 25 Jan '18

25 Jan '18

Hi, I was wondering if someone has a .clang-format file that works fine to check boost code. I looked into the github repositories, but I couldn't find any. Best regards, Damian

9 11

[outcome] Some documentation suggestions
by Vinícius dos Santos Oliveira 24 Jan '18

24 Jan '18

Maybe I could send some PRs later (I've already sent one a few moments ago). But, for now, I'll have to postpone. Notes: - You put too much focus in "open (error) type hierarchies" (e.g. `error_code`). Not a problem. Also, do not change anything just because this comment. Really, it is not a problem. - The beginning of the documentation gave me the impression that I could only use EC types that were convertible to `std::error_code`[1], “it need in fact to merely satisfy trait::has_error_code_v<EC>”. Later pages corrected my understanding. - “only works when the EC type is the same in the try expression as the calling function”[2] is misleading. `OUTCOME_TRYV(outcome::result<int, err>{err::success})` works inside a function returning `outcome::result<void>` given `err` is convertible to `std::error_code`. [1] https://ned14.github.io/outcome/tutorial/payload/ [2] https://ned14.github.io/outcome/tutorial/default-actions/error-codes/ -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

2 3

[outcome] comments on Regular ops
by Andrzej Krzemienski 24 Jan '18

24 Jan '18

Hi Everyone, This is not my final review (yet), but I wanted to raise some issues with Regular ops: comparisons and swap. 1. Comparisons. Equality comparison for `result` makes a strange choice for `T`s without comparisons: two such `result<T>`s just compare unequal. This is somewhat contradictory to semantics of Regular types. For value-semantic types we expect that a copy of the original object `x` compares equal to `x`: ``` int i = 1; int j = i; assert (i == j); ``` For some types, copy-construction makes a copy with the same value, but there is no way to define operator==. In this case, in order not to confuse anyone operator== is simply not provided: ``` using transformation = std::function<int(int)>; transformation f = [](int i) { return i; }; transformation g = f; // assert (f == g); <-- does not compile ``` And now, when we wrap it into `result`, we get: ``` // continuing previous example: out::result<transformation> of = f, og = g; f == g; // <-- compiles fine, returns false. ``` Now you are just telling lies. Two objects have the same value, yet they compare unequal! Here is a live example: https://wandbox.org/permlink/I hqgXDfHW6WqAXHW My recommendation would be not to provide comparison operators if either `T` or `EC` does not provide them. 2. Swap For non-trivially-copyable types, it looks like (similarly to std::variant) `result` cannot provide the strong exception safety guarantee. You may need to both move-construct `T` and `EC` and both can fail. ``` void swap(result &o) noexcept(detail::is_nothrow_swappable<value_type>::value // &&detail::is_nothrow_ swappable<error_type>::value) { using std::swap; #ifndef BOOST_NO_EXCEPTIONS this->_state.swap(o._state); try { swap(this->_error, o._error); } catch(...) { swap(this->_state, o._state); throw; } #else swap(this->_state, o._state); swap(this->_error, o._error); #endif } ``` The trick with catch-reswap-rethrow assumes that `T` is more likely to throw while swapping/moving than `EC`, but it might be quite the opposite. Also, it is possible that while reswapping, another exception will be thrown. In general, you cannot guarantee the roll-back, so maybe it would be cleaner for everyone if you just declared that upon throw from swap, one cannot rely on the state of `result`: it should be reset or destroyed. Another problem is that in the noexcept() clause you are mentioning is_nothrow_swappable<value_type> and is_nothrow_swappable<error_type>, but in the implementation you might be using move constructors rather than swaps. This means that for types that do not throw in swap but throw in move constructor (like std::list), a throw from move constructor will cause a call to `std::terminate`. See live example here: https://wandbox.org/permlink/8jIyb0fx7U72cZSt The noexcept clause should be extended to include move-constructors. This is the case for `std::optional`. Regards, &rzej;

5 14

yomm2 - open methods
by Jean-Louis Leroy 24 Jan '18

24 Jan '18

Hi, in 2013 I posted a proposal for an "open multi-methods" library, see here: https://lists.boost.org/Archives/boost/2013/07/205383.php Due to insufficient interest, I did not go forward with a formal submission, and I published my work on github, under the name yomm11. I have now completely rewritten the library. The new version - yomm2 - is available here: https://github.com/jll63/yomm2 This iteration is much better because it does not require any modifications to classes involved in method dispatch, yet the speed of a method call with one virtual argument is within 15% of the equivalent virtual function call. Over the years I realized that the value of such a library resides more in the 'open' than in the 'multi' aspect. Open methods are virtual functions that live outside classes, like free functions. They solve several problems, notably the Expression Problem (http://wiki.c2.com/?ExpressionProblem) and Cross-Cutting Concerns (http://wiki.c2.com/?CrossCuttingConcern) They provide an elegant replacement for the Visitor pattern. yomm2 also implement multiple dispatch, which can come (occasionally) handy. Well I am just touching base to see if things have evolved and if there might now be an interest in seeing this in Boost. Jean-Louis Leroy

3 12

Contributing in the algorithm library
by Surayans Tiwari 24 Jan '18

24 Jan '18

Hello Boost Community! My name is Surayans Tiwari currently pursuing Bachelors of Engineering at BITS Pilani, India . I am an algorithms enthusiast and c++ programmer with 3 years of experience coding in the language. I want to get a head start on how to add new modules in algorithm library of boost. Please can someone help me with this. Thank you. ‌

4 10

[outcome] Whether to default EC = error_code for result?
by Niall Douglas 23 Jan '18

23 Jan '18

Just wondering what the reviewers' opinion is on the choice by Outcome to default `result<T, EC = std::error_code>`? That made sense back when Boost.System's error_code aliased `std::error_code` when being compiled under C++ 11 or better (i.e. always in the case of Outcome). But now that Boost.System's error code looks to be becoming a superset of `std::error_code`, I am now wondering whether to no longer default it at all to anything. Arguments in favour of this: 1. Expected no longer defaults E to anything, thus avoiding including <system_error> which drags in <string> and imposing compile time costs on those who don't use <system_error>. I did some more benchmarking, on a recent GCC on a 4Ghz CPU it's about 0.6 secs per compiland being added on Linux, and more like a second on Windows with MSVC. 2. As is pretty clear from the tutorial, we expect all non-trivial uses of Outcome to typedef `result` into the local namespace anyway. So defaulting `EC` only really benefits trivial use cases. 3. I think it now inevitable I need to go implement a much lighter weight <system_error2> without the problems with <system_error> (e.g. header only use problems, heavy includes, underspecified semantics, hardcoded use of `int`, memory allocation and so on). I'll send it to SG14 for them to get it into the standard if they like it (they will, it'll tick all their boxes, WG21 may be more challenging). Arguments against this: 1. Use of `std::error_code` ought to be encouraged rather than UDTs such that Outcome using code is not anti-social to other code. Defaulting the type sends a clear message on this. 2. Removing the defaulted `EC` on `result` is asymmetrical to defaulting `EC` and `EP` on `outcome`. I personally don't mind it, different typical use cases means different defaults, but others may find the asymmetry upsetting. 3. The relevant policies need to include `<system_error>`, otherwise they don't compile. So the include of `result.hpp` would need to be split into a `result.hpp` and a `error_code_support.hpp` with the latter containing the `<system_error>` stuff. Thoughts? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

2 2

23 Jan '18

While refactoring the test Jamfile for Boost.System, I wrote this rule: rule system-run- ( sources + ) { local result ; result += [ run $(sources) : : : <link>static : $(sources[1]:B)_static ] ; result += [ run $(sources) : : : <link>shared : $(sources[1]:B)_shared ] ; result += [ run $(sources) : : : -<library>/boost/system//boost_system <define>BOOST_ERROR_CODE_HEADER_ONLY : $(sources[1]:B)_header ] ; return $(result) ; } to avoid repeating each test three times. The inconsistency is somewhat annoying. We could normalize the third line by introducing a third link type, <link>header, in response to which the library can switch to header-only mode. This is more or less the same suggestion as Niall's _hl targets from the CMake discussion, but it fits Boost.Build better, because the <link> property is automatically propagated to dependencies. Furthermore, after thinking about it a bit, I think that we might even have room for a fourth link type, <link>source, in response to which the library target would pass an appropriate <source> usage-requirement upwards. (<source>error_code.cpp in Boost.System's case.) <link>source is kind of best of both worlds, as it doesn't reparse the source code each time the library is used, and at the same time is not prone to the ODR violations introduced by inadvertently compiling the library and the executable with different, ABI-incompatible options. Comments?

2 4

[git][releases] removing beta tags
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi all, I would like to know if it is allowed to delete the git tags that are associated to beta releases (such as "boost-1.45.0-beta1"). Thanks, Raffi

2 2

[trac] email notifications?
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi, Is trac sending email notification on comments and changes regarding tickets? It used to do so, but I am not receiving anything. I am asking because I am waiting for ppl to comment on the tickets for some time. If people do not receive email notifications, I think I will wait for ever. Thanks, Raffi

2 2

[trac] new versions of boost
by Raffi Enficiaud 22 Jan '18

22 Jan '18

Hi there, Would it be possible to add the next versions of boost to trac/milestones ? Thanks! Raffi

7 12

[system] Would it be possible to trial a breaking change to Boost.System and see what happens?
by Niall Douglas 22 Jan '18

22 Jan '18

SG14 the low latency study has been looking into how to improve some design decisions in <system_error>. The relevant WG21 paper is https://wg21.link/P0824 and recent discussion can be found at https://groups.google.com/a/isocpp.org/forum/#!topic/sg14/j7tQybEjP5s. What we'd like to do is to test whether some very mildly breaking changes to <system_error> are so mild as to affect no users, and on that basis propose WG21 to make those mildly breaking changes to <system_error> in the next C++ standard. And to test this, we'd like to modify Boost.System with those mildly breaking changes, ship a release and see how many users complain. If it is zero, we have evidence for WG21 that this is not a consequential change. What we'd like to change is this: 1. Stop treating code zero as always meaning success irrespective of category. This remedies a defect where some custom error code domains cannot be represented by error_code due to using value 0 for an error. In actual code, I've never seen anyone ever use comparison to anything but a default constructed error code, so I think this will be safe. 2. Success becomes solely the default constructed error code, which is code zero and a new category of "null_category". This is internally represented by { 0, nullptr }, and thus makes the default constructor trivial which is highly desirable as it eliminates any compiler magic static fencing for the default constructor. Right now the default constructor uses system_category with value 0, and I suspect no code will notice this change either. 3, Make the default constructor constexpr, now possible. No code should notice a difference, except less runtime code will be generated. 4. error_code::message() returns a std::string_view instead of std::string if running C++ 17 or better. This lets us remove the <string> dependency, and thus stop dragging in half the STL with <system_error> which in turn makes <system_error> actually useful to the embedded systems crowd. The guess here is that std::string_view has such excellent interoperation with std::string that I think 99% of code will compile and work perfectly without anybody noticing a thing. I appreciate that this would undo Peter Dimov's excellent work at having Boost.System alias <system_error> under C++ 11 and later. I also appreciate that we are deliberately going to potentially break end user code. But my personal guess is that in practice, the breakage will not be noticed by 99% of code out there right now. It'll just compile against the improved Boost.System and everything will work as before. Boost was originally intended as an incubator for C++ standard changes. This ticks that box perfectly. Thoughts on feasibility? Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

15 76

Travis CI Resources
by James E. King, III 22 Jan '18

22 Jan '18

Last summer we had a discussion about Travis CI Resource Usage for boostorg. Originally the discussion was about purchasing more resources; however the discussion quickly focused on finding the root cause of the backlog. The desire is to ensure that pull requests submitted to repositories are processed in a timely manner. This is not happening, and there is at least a 12 hour backlog on pull request builds for boostorg right now. Summarizing the discussion back then, it was proposed that the backlog was caused by folks working on feature branches directly in their boostorg repository, with the Travis CI setting enabled to "build branch updates". The proposed solution was to encourage everybody to fork their repository and set up their own Travis CI and Appveyor under their account, and work feature branches on your fork. If working alone, this is efficient for everyone as we all end up with faster builds because your account will not contend with boostorg for resources. So please, use your personal account to build up features if you can. Additionally, tuning your Travis CI build script to do a little bit less work will help. If you have a script that builds with gcc, gcc-5, gcc-6, gcc-7, clang, and cxxstd of 03,11,14,1z - for most libraries that are at the c++03 language level this is going to be significant overkill for use as a pull request gate. In the example above, there are 20 builds to do; double that if you build debug and release variants. If each build takes just 2 minutes that's still an 80 minute CI cycle. Please spend some time reviewing your practices around the use of the free CI resources we all share. Thanks, Jim

5 11

[config] Supporting newer compilers: what does it take?
by Olaf van der Spek 22 Jan '18

22 Jan '18

Hi, What does it take to support new compilers, especially MSVC? 15.6 Preview 1 has been released now. Is some documentation or policy regarding test runners etc available? https://blogs.msdn.microsoft.com/vcblog/2017/12/19/c17-progress-in-vs-2017-… Gr, -- Olaf

1 1

[gsoc18] RSS
by Greger 22 Jan '18

22 Jan '18

Got some code/idea for RSS. possibly an GSoC18 topic?anyone? br g

2 3

[bjam] Can I disable a test based on an environment variable?
by James E. King, III 21 Jan '18

21 Jan '18

I'd like to disable some serialization tests if I am running a ubsan build on travis. Is there a way in the Jamfile I can make it conditional on an environment variable, or should I define something like BOOST_DATE_TIME_UBSAN and put "if !defined" in the appropriate tests?

2 2

[gsoc2018] Dynamic Shortest Path Tree
by a.i＠acm.org 21 Jan '18

21 Jan '18

Hi, I am Donghyuk Kim, a Ph.D. Student at Korea Advanced Institute of Science and Technology. I tried to contribute something last year but was not able to start the project for some reason. So I am about to re-try again this year. What I would like to contribute is a specific algorithm, "Dynamic Shortest Path Tree" which is simply, a dynamic version of Dijkstra's algorithm. It is a tree-based data structure to maintain single-source to all destination shortest paths and known to outperform Dijkstra or A* where the insertion and deletion of vertex/edge frequently occur. The concept of "Dynamic Shortest Path Computation" was originally introduced in [Fully Dynamic Algorithms for Maintaining Shortest Paths Trees] by D. Frigioni, et al. (http://dl.acm.org/citation.cfm?id=338900) I have already implemented a working prototype for my research, but unit test, coding style unification, and much more c++ style modifications are required for the general purpose. I hope someone finds it interesting and be a mentor on this journey. Thanks in advance. Best Regards, Donghyuk Kim a.i(a)acm.org _____________________________________ Sent from http://boost.2283326.n4.nabble.com

2 1

[gsoc18] SafeFloat proposal
by Damian Vicino 21 Jan '18

21 Jan '18

Hi, I added a proposal to get SafeFloat ready for review: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018#3-b… This was a project I started in gsoc2015 as student mentored by Robert Ramey. Please contact me if you are interested in further details. Best regards, Damian Vicino

2 1

Google Summer of Code 2018
by David Bellot 20 Jan '18

20 Jan '18

Dear Boost community, once again this year, we will apply to be a mentoring organization for the Google Summer of Code 2018. Our organization has been quite succesful for the last decade and this year we hope to be selected again. As part of filling in our application for 2018, we must supply to Google a list of potential GSoC mentors and potential GSoC projects for summer 2018 in order to be approved as an organisation this year. Therefore a lengthy page of awesome project ideas at https://svn.boost.org/trac/boost/wiki/SoC2018 before *January 23rd* would be an enormous help to getting us approved again this year and bringing to Boost another Google funding (worth dozens of thousands of dollars on average). If you think yourself able to mentor a student doing some work on Boost this summer, *please* consider adding a description of the proposed work item and your name to the list. If you want to have a better chance receiving funding for your project ideas, it is better to find good students early and that is best done by getting project ideas floated *early*. If you want to know more about mentoring a Google Summer of Code funded student work before you nominate yourself, please feel free to ask on the main Boost developers mailing list boost(a)lists.boost.org or via gsoc-admin(a)boost.org. Thank you in advance for your time. Finally, I would like to thank Niall Douglas, our previous Boost admnistrator for GSoC, who did an awesome work during many years and helped the Boost community grow thanks to all the funding we received years after years from Google. Best regards, David

4 9

Fwd: Re: [gsoc18][ublas] Proposal to add advanced matrix operations
by Mike Gresens 20 Jan '18

20 Jan '18

Hi Mike, Apart from the operations I was proposing, the idea of solving polynomials via QR reduction seems a great idea to me. I can add this module in the list of operations to be added to Boost.ublas in my proposal. I am looking for someone to mentor me on this project. Regards, Shikhar Srivastava On Sat, Jan 20, 2018 at 10:34 AM, SHIKHAR SRIVASTAVA <shikharsri1996(a)gmail.com <mailto:shikharsri1996@gmail.com>> wrote: Hi Mike, It looks like some of the operations that I suggested were already implemented as a part of GSOC15, though never got merged into the main branch. https://www.google-melange.com/archive/gsoc/2015/orgs/boostcpp/projects/raj… <https://www.google-melange.com/archive/gsoc/2015/orgs/boostcpp/projects/raj…> https://github.com/BoostGSoC15/ublas/ <https://github.com/BoostGSoC15/ublas/> My Idea was to add generalised modules for the operations (Now) - 1. LU and Cholesky 2. QR and QL 3. SVD On Fri, Jan 19, 2018 at 9:14 PM, Mike Gresens <mike.gresens(a)googlemail.com <mailto:mike.gresens@googlemail.com>> wrote: Hi Shikhar, does this include something for solving polynomials (via balanced-QR reduction of the companion matrix)? See https://www.gnu.org/software/gsl/doc/html/poly.html#general-polynomial-equa… <https://www.gnu.org/software/gsl/doc/html/poly.html#general-polynomial-equa…> Thanks! Best regards, Mike... Am 19.01.2018 um 07:37 schrieb SHIKHAR SRIVASTAVA via Boost: Hi everyone, I am a 4th year undergraduate student pursuing a degree in Computer Science and Engineering. I have strong programming experience in C++ through internships, self projects and programming events. I wish to be a part of gsoc18 under boost and am particularly interested in the linear algebra library Boost.ublas. The ublas library can be made more useful for Machine Learning applications like recommendation systems, clustering and classification, pattern recognition by adding some operations required in those. I propose to add advanced matrix operations to ublas including - 1. Triangular Factorisation (LU and Cholesky) 2. Orthogonal Factorisation (QR and QL) 3. Operations to find Singular Value lists 4. Eigenvalue algorithms 5. Singular Value Decomposition (SVD) 6. Jordan Decomposition 7. Schur Decomposition 8. Hessenberg Decomposition This is a very brief description of what I would like to propose. Any suggestions that help in refining the requirements before making a draft proposal would be great. Regards Shikhar Srivastava Github: https://github.com/shikharsrivastava <https://github.com/shikharsrivastava> _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost <http://lists.boost.org/mailman/listinfo.cgi/boost>

1 0

[geometry][gsoc2018] Similarity between geometries
by Xing GUO 20 Jan '18

20 Jan '18

Hello, My name is Guo Xing, I have sent a mail for some ideas on gsoc18 projects. David's uBLAS project on GPU computation is a little bit hard for me. Still thanks for his kind reply :) . These days, I found a project that I could possibly work on. So, I decide to take "Similarity between geometries". Below is my short self-introduction. Name: Guo Xing University: Southeast University Major: Electronic Engineering Email: higuoxing(a)gmail.com Github: https://github.com/higuoxing Homepage: https://higuoxing.com Availability: (Feb-Jun 4 hr/day) (Jun-Aug 6hr/day or more) As for my code competency, I will take the project 1 competency test after my final exam. Thank you! Regards, Guo Xing

1 0

[callable_traits] Incorrect newlines in git
by Andrey Semashev 20 Jan '18

20 Jan '18

Hi, I've created this PR to fix newlines and tabs in Boost.CallableTraits: https://github.com/boostorg/callable_traits/pull/170 Without it, I cannot update my local Boost tree because git treats the files are modified. Could someone, please, merge this PR? It's really annoying that the update process breaks every time. Thanks.

2 1

[gsoc18] Implement HTTP Library
by Xing GUO 19 Jan '18

19 Jan '18

Dear community: I'm Guo Xing, who is currently a student in his third year of college(bachelor's degree). I have interests in web development. I've done some projects with Python and node before. I want to do some work with C++ in GSoC18. So, is there any ideas for me? Or, someone could be my mentor? I love open source, but never contribute to them. I want to do some contribution. Regards, Guo Xing https://github.com/higuoxing

3 2

crypto hash library
by kerukuro 19 Jan '18

19 Jan '18

While boost::hash and the proposed additions and are good for generic hashing, its API is not very suitable for cryptographic hashes and XOFs. Would there be any interest in boostifying this library eg under name 'boost::digest' and putting cryptographic hashes in there? https://github.com/kerukuro/digestpp

1 0

[gsoc18] R-tree serialization
by Kirill Mishchenko 19 Jan '18

19 Jan '18

Hi, My name is Kirill. I’m interested in the contribution to the project “R-tree serialization”. The search through the mailing list archive has shown there was an interest in this project among students in 2017, but as the GSoC 2017 archive site displays there was no student that participated to accomplish this project. Is it possible to work on this project as a GSoC 2018 participant? It seems like last year Adam Wulkiewicz was ready to be a mentor for the project. Briefly about myself. I am a PhD student working on Computational Humor. More precisely I’m working on the problem of finding/generating a humorous response given a textual input. My C++ programming experience includes a summer internship at Yandex Search and my contribution to mlpack (a machine learning library written in C++) as a GSoC 2017 participant (https://summerofcode.withgoogle.com/archive/2017/projects/4812231682293760/ <https://summerofcode.withgoogle.com/archive/2017/projects/4812231682293760/>). For mlpack I designed and implemented cross-validation and hyper-parameter tuning modules with significant usage of C++ metaprogramming. Best regards, Kirill Mishchenko

2 1

mingw and windows.h
by Raffi Enficiaud 18 Jan '18

18 Jan '18

Hi all, I recently pushed something for boost.test on develop that is apparently breaking the builds on mingw: http://www.boost.org/development/tests/develop/developer/output/igaztanaga-… What I do in the code is this: ---------- #ifdef _WIN32 #include <Windows.h> #endif ---------- and then later ---------- #ifdef _WIN32 class setcolor { protected: void set_console_color(std::ostream& os, WORD *attributes = NULL) const { DWORD console_type; /// some additional windows specific code #endif ---------- I thought that this would be enough for having the windows specific code, but apparently mingw disagrees with the error that some windows specific define is not there. Is this an issue with the code, the SDK, the machine? I have no experience with mingw, but if we are able to include windows.h, then we have to have the defines there (the missing macro is there since Windows 2000). Thanks for the help, Raffi

3 4

Google Summer of Code 2018: submit your proposal
by David Bellot 17 Jan '18

17 Jan '18

Hi all, I migrated the GSoC'18 pages to our wiki on Github. Please contribute your proposals here now: https://github.com/boostorg/boost/wiki/Boost-Google-Summer-of-Code-2018 I would love to see plenty of nice proposals before the end of the week so that we are in good conditions to obtain it again this year. If you have problems with permission please contact me directly Best regards, David

1 0

Change Trac wiki permissions
by David Bellot 17 Jan '18

17 Jan '18

Hi, does anyone have access to the boost Trac wiki. I need to change permissions on a page to allow users to edit the page as well, but I can't find any option. There should be an Admin button next to the Search button but it doesn't appear. The page in question is the Google Summer of Code 2018: https://svn.boost.org/trac10/wiki/SoC2018 Thanks David

2 2

Reforming Boost.System and <system_error> round 2
by Niall Douglas 17 Jan '18

17 Jan '18

Many thanks to those who have contributed to the discussion in the other thread regarding making a breaking change to Boost.System in order to provide empirical test data to persuade WG21 to similarly break <system_error> in a future C++ standard for its own good. This fresh email is hopefully to start finishing the discussion. To summarise discussion to date, Peter has made Boost.System's error_code and error_category constexpr except for the virtual functions. A big win for codegen, and the choice of the default constructor of error_code to use system_category now no longer prevents constexpr, so the request for a new special null_category() can also be dropped. There is substantial opposition to making message() return string_view, so let's drop that request. That leaves the request to fix "if(ec) ..." which right now returns true if the value is 0, despite that much code writes "if(ec) ..." to mean "if error then ...". There is also the issue of error coding schemes not being able to have more than one success value, which usually must be 0. That's the remaining discussion point. Myself and Peter feel this is worth fixing despite the increased runtime overhead. Others, including one of its original inventors, feel it is too much overhead. To add some empirical evidence to the discussion, I have coded up a mock up of the improved error_code which can be viewed at https://godbolt.org/g/dDAWih. This demonstrates constexpr error_code and error_category in action as well. To summarise what the mock up demonstrates: 1. error_category() gains a new virtual function called `bool failure(int code)` which is now called by error_code's operator bool. 2. Thanks to the new constexpr construction, the compiler now completely elides from runtime the case where an inlined function returns an error code and the caller acts upon it. As in, **zero code is now generated**. Far better than before. No virtual functions are called, they are optimised out entirely. 3. For unknown error codes from extern sources where the linker is generating an executable, the "final" modifier removes a layer of indirection when calling `failure()` after the linker has run, and indeed clang seems to go ahead and inline the implementation entirely despite us not asking for LTO. Which is kinda cool. 4. Thus only in shared objects, and only for unknown error codes from extern sources, is a virtual function call actually performed. And given the frequency of doing `if(ec) ...`, it'll almost certainly be hot in the branch predictor i.e. no stalls. Question: is this still considered too much overhead? Note that there is no longer ANY proposed breaking change with existing code. This is now 100% enhancement only. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

17 57

[GSoC2018] About Summer Projects of Boost
by 郭兴 17 Jan '18

17 Jan '18

Hi, there, GSoC2018 is coming, I am in my third year of college(bachelor's degree) and want to be enrolled in this interesting program as student. I want to do some contribution for community. Are there some open projects? Maybe I could do some work? I am interested in [geometry], [ublas] and [asio]. I think I could prepare for it from now on. Cheers, Xing GUO

3 2

Re: [boost] Reforming Boost.System and <system_error> round 2
by Andrey Semashev 17 Jan '18

17 Jan '18

On Wed, Jan 17, 2018 at 2:44 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > 2018-01-17 0:29 GMT+01:00 Andrey Semashev <andrey.semashev(a)gmail.com>: >> >> On Wed, Jan 17, 2018 at 1:16 AM, Andrzej Krzemienski via Boost >> <boost(a)lists.boost.org> wrote: >> > 2018-01-16 19:58 GMT+01:00 Andrey Semashev via Boost >> > <boost(a)lists.boost.org> >> > : >> >> >> >> There's nothing ambuguous about the conversion operator, as it is >> >> specified in the standard, and I find the syntax quite intuitive. >> > >> > You say you find the syntax quite intuitive. But do you also find the >> > semantics intuitive? When you type or read `if(ec)` do you interpret it >> > as >> > "if operation failed" or as "if operation returned code of numeric value >> > zero, regardless of the domain and regardless of whether in this domain >> > zero means success or failure"? >> >> The two interpretations are equivalent for me, because in my code >> error code of zero always means "success". Why? Because I pick the >> error values that way (or map them that way, if the values come from >> an external API) so that they play nicely with `error_code` design and >> the rest of the code. >> >> If we support multiple "success" values or non-zero success values, I >> would expect "if (err)" to mean "if some error happened". Why? Because >> that "if" controls error handling, not an arbitrary non-zero result >> handling. I've never seen or written code that does otherwise. >> >> If I want to test for a particular error code, I would write "if (err >> == x)" or "if (err != x)" - that's the syntax that communicates the >> intent to check for the particular value, including when `x` happens >> to be zero (which doesn't really matter, because `x` is always an enum >> value and never a magic number). You may ask the what is the >> difference between "if (err)" and "if (err != success)" and it is that >> the latter only tests for failure in the particular domain. Now, this >> difference may not be obvious, and that is why I generally avoid >> writing "if (err != success)". > > Yes, that would also be my expectation. So, if I understand your position > correctly, you oppose to introducing yet another function `failure(ec)`, but > you would be ok with fixing `if(ec)` so that it always means "failure" (of > course provided that you can be convinced that there is anything that needs > fixing). Yes. Not actively opposed, though. I just don't see the point in having this more verbose syntax for something that we already have and that is more succint. I'm not opposed to adding support for multiple success codes, quite the opposite. My only condition is that this enhancement doesn't penalize too much the existing usages with a single zero success code. > It has been always my understanding that `error_code` is intended to be used > so that the numeric value is always *exactly* the value returned by the > system call: you do not change it, do not adapt it. You keep it unchanged so > that when logged, the programmer can easily retrieve the original number say > from the log file to check what went wrong with the system call. Instead, > you use all this machinery with conditions to perform different queries, on > what kind/sort of failure it was. > > Now, if you adapt the error code so that 0 means success and non-0 means > failure, you are violating this idea that numeric value of `error_code` > should be delivered unchanged, un-adapted. Mapping foreign success codes to zero may be viewed as a hack, but in practice it rarely matters. When you present error codes to the user, you rarely want to present the numeric value. Most likely, you want to present the human-readable result of `message()`, and it will be produced using the mapped error code values. I agree that ideally you would not have to map error codes, but that is an acceptable compromise to have a decent performance and unified syntax with the existing `std::error_code`. Hopefully, if we settle on an efficient solution, we won't have to do this anymore.

1 0

Upcoming formal review of the [Boost.]Yap library
by Louis Dionne 16 Jan '18

16 Jan '18

Hi everyone, The formal review of Zach Laine's 'yap' expression template library will be starting in 3 weeks, from Feb 05 to Feb 14. yap is a C++14-and-later library to build expression templates, much like Boost.Proto currently does. yap uses new features introduced in C++14/17 to make the library simpler to use and compile faster than existing solutions. The documentation is available here: https://tzlaine.github.io/yap The official repository is here: https://github.com/tzlaine/yap We encourage folks to become familiar with the library and submit feedback to the author even before the review starts. Thanks! Louis Dionne (review manager for this submission)

1 0

[convert][align][coroutine2][dll][endian][fiber][metaparse][check_build][qvm] Missing .gitattributes
by Steven Watanabe 15 Jan '18

15 Jan '18

AMDG I noticed that the following submodules have no .gitattributes: convert align coroutine2 dll endian fiber metaparse tools/check_build Also, qvm forces Windows line endings in its .gitattributes In Christ, Steven Watanabe

1 0

Bug report rejected as conformant
by Edward Diener 13 Jan '18

13 Jan '18

I recently reported a preprocessor bug in Oracle C++ 12.6 on their online forum when compiling a C program example. I even cited the C11 standard in showing that Oracle C++ 12.6's actions were non-conformant. The answer I was given, from an Oracle C++ developer who said he was a member of the C++ standard committee, is that since Oracle C++ 12.6 gives a warning message rather than a compiler error the compiler was compliant with the C standard, since the standard only requires a diagnostic message to be considered standard compliant when it does not implement the compiler according to the standard, and that a warning was a diagnostic message. Furthermore since there was a way to force the particular warning to be considered an error, Oracle was not going to change their compiler. At that point I "lost it" so to speak. I cannot conceive that any C/C++ standard would specify that giving a warning rather than an error, when not complying with the C/C++ standard, would then make the compiler compliant. Comments ?

5 11

[git] Git problem with Boost
by Edward Diener 13 Jan '18

13 Jan '18

git checkout develop git pull git submodule update --init from my local main Boost repository gives me: error: no such remote ref 0ce9138ce86095eab9c09d171fecb5f72c4457f7 Fetched in submodule path 'libs/callable_traits', but it did not contain 0ce9138ce86095eab9c09d171fecb5f72c4457f7. Direct fetching of that commit failed.

3 4

Re: [boost] Potential Boost SAX library
by Bjorn Reese 13 Jan '18

13 Jan '18

On 01/09/18 18:36, Oliver Adams via Boost wrote: > I was wondering if a library I'm developing would be of value to the > Boost community. It is basically an event-driven parsing/serialization > library for common formats using a standard internal representation or > simple pass-through conversions. Would anyone be interested in something > like this being added to Boost? There are two kinds of incremental parsers: push parsers (SAX) and pull parsers (approximately StAX.) Briefly put, push parsers traverses the input automatically and generates events for each token it finds, whereas pull parsers traverses the input manually like an iterator and the current token can be queried. Pull parsers have some significant advantages over push parser: * It is straight-forward to implement a push parser on top of a pull parser. This involves a loop and a switch statement (see [1] for a complete example.) Going in the other direction involves the use of coroutines; most likely stateful coroutines. * Contextual parsing can be done directly, unlike push parsers where you have to maintain contextual state in the event handler. * Push parsers can be used directly in Boost.Serialization archives. * Pull parsers are composable. For instance, you could insert a URL pull parser directly into an HTTP pull parser. For a pull parser framework see: https://github.com/breese/trial.protocol The documentation is a bit old though. [1] http://breese.github.io/trial/protocol/trial_protocol/json/tutorial/push_pa…

3 2

Re: [boost] [system] Would it be possible to trial a breaking change to Boost.System and see what happens?
by Bjorn Reese 13 Jan '18

13 Jan '18

On 01/12/18 18:43, Niall Douglas via Boost wrote: > 2. Success becomes solely the default constructed error code, which is > code zero and a new category of "null_category". This is internally > represented by { 0, nullptr }, and thus makes the default constructor > trivial which is highly desirable as it eliminates any compiler magic > static fencing for the default constructor. Right now the default > constructor uses system_category with value 0, and I suspect no code > will notice this change either. Does this mean that custom error categories have to change their make_error_code(e) function to either return a default constructed error_code in case the error value indicates success, or a custom error_code otherwise? In other words, today we do this: namespace my { std::error_code make_error_code(my::errc e) { return std::error(e, my::category()); } } Should that be changed to this? namespace my { std::error_code make_error_code(my::errc e) { if (e == my::success) return std::error_code(); return std::error_code(e, my::category); } }

1 0

[date_time] building documentation?
by James E. King, III 12 Jan '18

12 Jan '18

I cannot build the documentation for Boot.DateTime on the develop tip - I get an error - am I doing something wrong in the command line or is it just broken? jking@ubuntu:~/boost/libs/date_time/doc$ ../../../b2 boostdoc Performing configuration checks - default address-model : 64-bit - default architecture : x86 ../xmldoc/Jamfile.v2:54: in modules.load *** argument error * rule doxygen ( target : sources + : requirements * : default-build * : usage-requirements * ) * called with: ( date_time_autodoc : : <doxygen:param>ENABLE_PREPROCESSING=NO <xsl:param>boost.doxygen.reftitle=Date Time Reference <doxygen.doxproc.title>Date Time Reference <doxygen.doxproc.id>date_time_reference ) * missing argument sources /home/jking/boost/tools/build/src/tools/doxygen.jam:622:see definition of rule 'doxygen' being called /home/jking/boost/tools/build/src/build/project.jam:325: in load-jamfile /home/jking/boost/tools/build/src/build/project.jam:64: in load /home/jking/boost/tools/build/src/build/project.jam:145: in project.find /home/jking/boost/tools/build/src/build/targets.jam:401: in find-really /home/jking/boost/tools/build/src/build/targets.jam:474: in class(a)project-target.find /home/jking/boost/tools/build/src/build/targets.jam:858: in resolve-reference /home/jking/boost/tools/build/src/build/targets.jam:875: in targets.generate-from-reference /home/jking/boost/tools/build/src/build/targets.jam:1226: in generate-dependencies /home/jking/boost/tools/build/src/build/targets.jam:1280: in class(a)basic-target.generate /home/jking/boost/tools/build/src/build/targets.jam:770: in generate-really /home/jking/boost/tools/build/src/build/targets.jam:742: in class(a)main-target.generate /home/jking/boost/tools/build/src/build-system.jam:796: in load /home/jking/boost/tools/build/src/kernel/modules.jam:295: in import /home/jking/boost/tools/build/src/kernel/bootstrap.jam:139: in boost-build /home/jking/boost/boost-build.jam:17: in module scope

3 10

[date_time] [build] new windows class of build error?
by James E. King, III 12 Jan '18

12 Jan '18

I enabled appveyor for Boost.DateTime pull requests and they are failing miserably when <cxxstd> is specified more than once. I don't remember this occurring in the past. This happens on Visual Studio, cygwin, mingw builds. Is this new Boost.Build behavior? https://ci.appveyor.com/project/jeking3/date-time-1evbf/build/1.0.3-develop error: Name clash for '<pstage\lib>libboost_atomic-vc140-mt-x32-1_67.lib' error: error: Tried to build the target twice, with property sets having error: these incompatible properties: error: error: - <cxxstd>14 error: - <cxxstd>17 error: error: Please make sure to have consistent requirements for these error: properties everywhere in your project, especially for install error: targets. Command exited with code 1

2 1

Informal CMake meeting at CPPCon
by Robert Ramey 12 Jan '18

12 Jan '18

Thursday 28 Sept 8 AM at CPPCon a small group of us met to talk a little regarding the situation regarding support of CMake by Boost. I promoted this meeting as I've been concerned that the only discernible results of the recent Boost Steering Committee announcement on the subject was a certain level of antagonism among boost members regarding the subject. Participants ============ Robert Ramey (me) Rene Rivera Vinnie Falco Louis Dionne David Sankel Matt Calabrese This was a small but I think a representative group. After some preliminary back and forth, I think we agreed: a) Nothing was going change regarding the current build system until there was a real alternative in place. b) That we should support serious proposals to implement CMake support within boost. c) And that any such proposals should go through the Boost formal review process. Traditionally, the boost formal review process has never applied to boost tools so this would be a departure from traditional practice. d) Questions regarding the scope/implemention of such support for CMake can be handled within the formal review process. e) Other questions regarding support CMake and Boost, transition to new system, related requirements on boost libraries, etc. can be better addressed once we have some sort of consensus on the form that CMake support will take. I had contacted Paul Fultz who is the only one I know of that has proposed something specific to submit to formal review. He told me he couldn't do it at the time, but shortly there after posted such a request on the list. So I guess for now we're on our way. My motivation for posting this is to keep the boost community up to date on what's happening so that no one gets overly surprised when things start to happen. I'm not really soliciting feedback - though it wouldn't surprise me if I get some. Robert Ramey

9 18

[scope_exit] (Boost >= 1.65) VS 2015 internal compiler error in lambda
by Tobias Loew 12 Jan '18

12 Jan '18

Hi, starting from Boost version 1.65 and using VS 2015 Update 3 (MSVC 19.00) the following code raises an internal compiler error: fatal error C1001: An internal error has occurred in the compiler. (compiler file 'msc1.cpp', line 1468). With earlier Boost versions it compiles fine. Tobias -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

3 8

Issue with bjam and building for NDK
by Robert Dailey 11 Jan '18

11 Jan '18

I filed an issue over at the Android NDK github page here: https://github.com/android-ndk/ndk/issues/616 When I invoke b2 to build boost using the standalone toolchain generated by the NDK, bjam seems to be wrapping the command in quotes, like "clang++". This throws off their logic in the clang++.cmd batch script. I was asked to test running b2 without quotes (e.g. clang++), but I am not sure how to do this. Could someone help me understand if this is a code change to b2? Or if there's a jam script somewhere I can modify? I'm not sure if this is a boost issue or an NDK issue at this point. I appreciate any help from the boost developers.

2 1

[contract] ready to release
by Lorenzo Caminiti 10 Jan '18

10 Jan '18

Hello release managers & all, Boost.Contract in master is ready to be added to the next Boost release (regression tests pass, docs are updated, etc.). What do I have to do to put https://github.com/boostorg/contract.git master into Boost release 1.67? Thank you. --Lorenzo

2 3

Potential Boost SAX library
by Oliver Adams 10 Jan '18

10 Jan '18

Hi all, I was wondering if a library I'm developing would be of value to the Boost community. It is basically an event-driven parsing/serialization library for common formats using a standard internal representation or simple pass-through conversions. Would anyone be interested in something like this being added to Boost? Thanks.

4 6

[outcome] Training video in post-Toronto std::expected<T, E>
by Niall Douglas 09 Jan '18

09 Jan '18

In preparation for the Outcome v2 review next week, reviewers may find the video of my Meeting C++ talk in Berlin last year useful to watch beforehand. The talk is a literature review covering all the WG21 papers related to the post-Toronto std::expected<T, E>, which is quite different to the Expected during the Outcome v1 review. https://www.youtube.com/watch?v=JfMBLx7qE0I My thanks to Jens for prioritising the release of this video, and for running a great C++ conference. I'm still building a list of errata for the video, once complete I'll post a list underneath it. Any mistakes that I made, please do let me know, ideally with a timestamp offset into the video. My thanks to all those who are currently reporting so many, many bugs in the reference docs. I'll try my best to fix them all before end of next week, but keep them coming! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Re: [boost] seeking endorsement for histogram library
by Bjorn Reese 09 Jan '18

09 Jan '18

I endorse boost.histogram.

6 11

[date_time] recommending upgrading the timezone database
by James E. King, III 07 Jan '18

07 Jan '18

The timezone database in Boost.DateTime doesn't have enough information in it to be accurate all the time. For example if a region changes time zone rules, when applying timezone only the current rule will be applied regardless of the date involved. If a region stops using daylight savings time, but a date/time falls before that rule change, it should still use daylight savings in printed output, correct? The IANA timezone database is more complete, and we could switch Boost.DateTime to use that instead. It is also maintained more frequently than the built-in one, which was last updated 7 years ago, and 4 years before that. Any thoughts on this? https://github.com/boostorg/date_time/issues/67 - Jim

2 1

Adding AppVeyor as a required check to a Boost repository on Github
by Edward Diener 07 Jan '18

07 Jan '18

I am trying to add AppVeyor as a required check to the boostorg/date_time repository on Github. I have gone through the step of adding 'develop' as a protected branch, checking "Require status checks to pass before merging", and checking "Require branches to be up to date before merging". The only thing that then appears in the settings for the protected 'develop' branch is: "Status checks found in the last week for this repository" is "continuous-integration/travis-ci" "required", which is checked. Nothing about AppVeyor whatsoever. Anyone know what the Github voodoo is for getting this to happen ? I see other Boost repository with both Travis-CI and Appveyor required checks but evidently the doc for doing this for AppVeyor is non-existent in Github.

1 0

[hash] Extract module from functional + std::hash_combine
by Daniel James 06 Jan '18

06 Jan '18

Hi, I'm planning to extract hash from functional into its own module, as that will apparently break the circular dependencies that functional is part of. Any objections? Also, any opinions on what the module should be called? 'hash' might suggest a more general purpose hash function, so maybe it should be called something more specific. Daniel

10 29

[date_time] Eliminate pre-1.33.0 io facet code?
by James E. King, III 06 Jan '18

06 Jan '18

There was a bug change around the 1.33.0 release timeframe that added new io facet handling for date_time. It is conditionally disabled using the definition USE_DATE_TIME_PRE_1_33_FACET_IO. I suggested in a github issue that the pre-1.33 mode be removed at this point. Any thoughts on that? https://github.com/boostorg/date_time/issues/61 - Jim

2 1

[outcome v2] Pre-review feedback
by Niall Douglas 05 Jan '18

05 Jan '18

Outcome v2's review starts on Friday 19th January, after which I can't fix even obvious problems. The documentation is by far the newest and most experimental part using bleeding edge tooling, so getting a few rounds of fixes in now before locking everything down for the review would be great. Can those who are super keen have a look at the reference API docs and find problems that me and Jonathan can fix before the review begins? You can find the reference API docs at: https://ned14.github.io/outcome/reference/ And issues can be logged to https://github.com/ned14/outcome/issues or https://github.com/foonathan/standardese/issues if you're sure of the source of the problem. Potential problems to look out for (not a complete list): - Lack of documentation summary string - Confusing or meaningless documentation - Incomplete or mangled documentation for some entity (e.g. sentences missing sections, lines reordered) - Leakage of "detail" namespace or of types or macros clearly of internal implementation detail - Stray or missing commas, angle brackets, brackets - Missing or insufficient requirements, effects or throws clauses - Appearance of any `std::enable_if`, these are supposed to be suppressed into requirements, but I know `outcome.hpp` is particularly bad on that (tracked by https://github.com/ned14/outcome/issues/76) - Lack of hyperlinking to other parts of the reference docs where that was clearly intended. To expand on the "bleeding edge tooling" part, these reference API docs are generated using https://github.com/foonathan/standardese which is based on clang libtooling. Some of the problems are caused by clang libtooling, some by standardese, some by me. I don't doubt that these reference API docs are an enormous improvement over those from doxygen - especially the ability to search semantically for stuff related to search term - but there are a lot of very small problems I'd love to clean up before the formal review begins. Thanks in advance. Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Changing the website (Was: Need help with bootstrap.bat)
by Andrzej Krzemienski 05 Jan '18

05 Jan '18

2018-01-03 13:54 GMT+01:00 Daniel James via Boost <boost(a)lists.boost.org>: > On 3 January 2018 at 10:04, Andrzej Krzemienski via Boost > <boost(a)lists.boost.org> wrote: > > > (n.b. It was very difficult to find this page as there is no direct link > > from www.boost.org) > > I'll add a link to the 'getting started' section. Maybe we should move > more content onto the github wiki? It's just a git repo with markdown > pages so it shouldn't be too hard to serve it from the website if > people would like it to be more integrated. > Let me share with you my recent experience. I was looking for something like "getting started for Boost developers" and could not find a place.In the front page there is section "INTRODUCTION", but it looks like content for potential users (rather than developers). There is section "DEVELOPMENT" but the content is more like "how to submit a new library", but no "getting started with developement" (on somebody else's library) There is a "WELCOME" -> "Getting started", but it looks like one for the users. (it recommends downloading a zip file). There is this non-obvious path: DEVELOPEMENT -> Reporting and Fixing Bugs. While there, click on "git repositories". It opens a stub page that says it has been superseded by another, and when you push on a link you get there. But this really should be simpler. Maybe in the front page we should have "DEVELOPMENT" -> "Getting Started" that links directly to https://github.com/boostorg/boost/wiki/Getting-Started Or maybe the topics should be divided differently: - Getting started with using Boost Libraries - Getting started with applying improvements to existing Libraries - Getting started with submitting a new library. I consider this more important than where actually the content is hosted. Regards, &rzej;

7 13

[test] Test cases parametrized by both type and value?
by Andrzej Krzemienski 05 Jan '18

05 Jan '18

Hi, Can anyone tell me if Boost.Test can solve the problem that I describe below. I have a function template inspect: ``` template <typename T> bool inspect(T const& v); ``` I want to test if it returns `true` for the following values: 1 (type int) 10 (type int) 1.0 (type double) "Y" (type const char *) Basically, different values of different types, but sometimes different values have the same type. I would like to write one test or "test template" with the following contents: ``` BOOST_TEST((inspect(v))); ``` Where `v` is name of the currently tested value. (But `v`s will have different types). I can emulate this behavior using template test cases and artificial types: ``` struct int_1 { static int value() { return 1; } }; struct int_10 { static int value() { return 10; } }; struct double_1 { static double value() { return 1.0; } }; struct cstr_Y { static const char * value() { return "Y"; } }; typedef boost::mpl::list<int_1, int_10, double_1, cstr_Y> test_types; BOOST_AUTO_TEST_CASE_TEMPLATE( my_test, T, test_types ) { BOOST_TEST(inspect(T::value())); } ``` (See working example in WandBox: https://wandbox.org/permlink/KcJqT8KvL3zIqAxL) But maybe there exists a direct solution in Boost.Test? Where I would just pass a list of values: `{1, 10, 1.0, "Y"}` It is easy to deduce types from values: ``` template <typename... T> mpl::liss<T...> Values(T... values); using test_types = decltype(Values(1, 10, 1.0, "Y")); ``` Does something like this exist, or ois it a reasonable extension? Regards, &rzej;

4 3

[regression] results pages not updating
by Joaquin M López Muñoz 04 Jan '18

04 Jan '18

Hi, Just a heads up, regression tests result pages: http://www.boost.org/development/tests/master/developer/summary.html http://www.boost.org/development/tests/develop/developer/summary.html aren't updating since Jan 1. Thank you, Joaquín M López Muñoz

3 5

Interest for a Fixed Point Arithmetics library
by Julien Vernay 03 Jan '18

03 Jan '18

Hello everybody. I am working on a project that needs and can use fixed point numbers, so I started searching for a library implementing fixed point numbers, but I didn't find anything. So I was wondering if people would need fixed point arithmetics, and here I am. The aim of this FixedPointNumber is to fix the point at compile-time using template, and having another template argument for the underlying type. So we have : template<typename T, size_t N> class FixedPointNumber { T value; public: //interface }; The N last bits of value is the decimal part : so to convert a FixedPointNumber to an int, we need only to use a bitshift operator (and same for construction from int). sizeof(FixedPointNumber<T,N>) == sizeof(T) , so there is no overhead in this implementation. Arithmetic and relational operators will be implemented. Multiplication needs one int multiplication and one bit shift. Division needs one int division and one bit shift. There is only one value for zero. Sign can be extracted with Most Significant Bit. I have already a basic implementation but if it interests more people I will do a proper implementation. Thank you for reading !

4 7

[multiprecision] Help needed with strange constexpr slowdown
by John Maddock 03 Jan '18

03 Jan '18

Folks I have a very strange issue that I need help with understanding, it comes from https://github.com/boostorg/multiprecision/issues/32 but in summary: Given: #include <iostream> #include <boost/multiprecision/cpp_int.hpp> using namespace std; using namespace boost::multiprecision; int main() { __int128_t i =0; __int128_t j =0; int256_t sum =0; for (; i <1e9; i +=19, j +=13) { int256_t diff = j; sum += i * diff; } std::cout <<"Result: " << sum << std::endl; return 0; } There is a 20-30% slowdown when compiled in C++11 or later compared to C++03 with gcc 5.x or 6.x. I've tracked this down to the constexpr default constructor for int256_t (which is called inside operator* to create a temporary for the result), if I make the default constructor non-constexpr by removing BOOST_CONSTEXPR from any of: number.hpp:44 (number()) cpp_int.hpp:1077 (cpp_int_backend()) cpp_int.hpp:501 (cpp_int_base()) cpp_int.hpp: 435 (cpp_int_base::data_type()) Then the slowdown disappears. All the line numbers refer to current develop BTW. gcc-7 is better, but I notice it still generates different code if the constructor is constexpr - that greatly surprises me to be frank - is there something I'm missing about constexpr-ness that could cause this? Confused yours, John. --- This email has been checked for viruses by AVG. http://www.avg.com

3 3

Need help with bootstrap.bat
by Andrzej Krzemienski 03 Jan '18

03 Jan '18

Hi Everyone, Maybe someone can help me with configuring bootstrap.bat. I am trying to set up the environment for developing boost libraries, and it is my understanding that the first step (after cloning a git repository) is to build b2 itself using the script bootstrap.bat. I got this from instructions at https://github.com/boostorg/boost/wiki/Getting-Started (n.b. It was very difficult to find this page as there is no direct link from www.boost.org) I am using MinGW on Windows, no Visual Studio installed. Nonetheless bootstrap.bat concludes that it should compile with cl.exe, and it does not work. I know that MinGWis not supported, but I have to take my chances. Maybe somebody knows how to instruct bootstrap.bat to select a GCC compiler and tools? Regards, &rzej;

5 6

help for contribution
by ashwin.pathak 03 Jan '18

03 Jan '18

Hi Developers, I am very interested in computer programming and I find boost c++ libraries really exciting. I would like to contribute to the organization, I am new to this organization. Can someone please help me to get started in contributing to the organization. Thank you, Best Regards, Ashwin Pathak

1 0

Re: [boost] Boost.HTTPKit, a new library from the makers of Beast!
by Vinnie Falco 01 Jan '18

01 Jan '18

On Sun, Oct 8, 2017 at 5:38 PM, Vinícius dos Santos Oliveira <vini.ipsmaker(a)gmail.com> wrote: > Now, moving on... given that you have __not__ answered how your parser's > design[1] compares to the parser I've developed I'll try to provide more clarity. `beast::basic_parser` is designed with standardization in mind, as I intent to eventually propose Beast for the standard library. Therefore, I have made the interface as simple as possible, exposing only the minimum required necessary to achieve these goals which the majority of users want: * Read the header first, if desired * Feed Asio style buffer sequences into the parser * Set independent limits on the number of header and body octets * Optional fine-grained receipt of chunked body data and metadata The design of basic_parser (the use of CRTP in particular) is meant to support the case where a user implements their own Fields container, or if they want a bit more custom handling of the fields (for example, to avoid storing them). Like all design choices, tradeoffs are made. The details of parsing are exposed only to the derived class. Complexities are hidden from the public-facing interface of `basic_parser`. Implementing a stream algorithm that operates on the parser is a straightforward process: template< class SyncReadStream, class DynamicBuffer, bool isRequest, class Derived> std::size_t read(SyncReadStream& stream, DynamicBuffer& buffer, basic_parser<isRequest, Derived>& parser, error_code& ec) { parser.eager(true); if(parser.is_done()) { ec.assign(0, ec.category()); return 0; } std::size_t bytes_transferred = 0; do { bytes_transferred += read_some( stream, buffer, parser, ec); if(ec) return bytes_transferred; } while(! parser.is_done()); return bytes_transferred; } > [1] at most it hides behind a “multiple people/stakeholders agree with me” > __shield__ There's no hiding going on here. One can only measure the relative success of designs based on the feedback from users. They opened issues, and I addressed their use-cases, sometimes with a considerable amount of iteration and back-and-forth as you have seen in the GitHub issues quoted in the previous message. Now, I don't know if the sampling of users that have participated in Beast's design are representative of the entire C++ community. However, I do know one thing - if GitHub stars are any measure of the sample size of the participants, then Beast is off to a good start. Here's a graph showing the number stars over time received by boostorg/beast, tufao, and Boost.Http (the last 2 libraries having you as the author I believe): <http://www.timqian.com/star-history/#boostorg/beast&BoostGSoC14/boost.http&…> (Note that the HTTP+WebSocket version of Beast was released in May 2016). We need to be careful interpreting results like this of course so perhaps we should look at different metrics. Here are the links to the number of closed issues for Beast, tufao, and Boost.Http: 502 Closed issues in Beast: <https://github.com/boostorg/beast/issues?q=is%3Aissue+is%3Aclosed> 38 Closed issues in tufao <https://github.com/vinipsmaker/tufao/issues?q=is%3Aissue+is%3Aclosed> 13 Closed issues in Boost.HTTP, from 6 unique users not including the author <https://github.com/BoostGSoC14/boost.http/issues?q=is%3Aissue+is%3Aclosed> Again we have to be careful interpreting results like this. But it sure looks like there is a lot of user participation in Beast. If approval from a large number of stakeholders is not a compelling design motivator then what is? > This tutorial is full of “design implications” blocks where I take the time > to dissect what it means to go with each choice. Thus far, no one has asked for more fine grained access to incoming HTTP tokens in the manner of `code::method` and `code::request_target`. If this becomes something that users consistently ask for, it can be done by changing the requirements for the derived class for `basic_parser`. This way, details about HTTP parsing which most people don't care about will not leak into the beast::http:: namespace. Such a change would not affect existing stream algorithms on parsers. Thanks

5 17

Re: [boost] What hash functions should be included in a hypothetical Boost hash-v2 library?
by Bjorn Reese 31 Dec '17

31 Dec '17

On 12/31/17 01:28, Peter Dimov via Boost wrote: > What (non-cryptographic) hash functions should a hypothetical future > Boost hash library contain? Have clear winners emerged by now? Which > ones do people prefer? I vote for FNV hashes: https://en.wikipedia.org/wiki/Fowler%E2%80%93Noll%E2%80%93Vo_hash_function

1 0

What hash functions should be included in a hypothetical Boost hash-v2 library?
by Peter Dimov 31 Dec '17

31 Dec '17

What (non-cryptographic) hash functions should a hypothetical future Boost hash library contain? Have clear winners emerged by now? Which ones do people prefer? SipHash is basically a given, but it's not optimized for speed.

5 6

Removing hash from Boost.Functional broke modules
by James E. King, III 28 Dec '17

28 Dec '17

See: https://github.com/boostorg/type_index/issues/18 There is no forwarding header to keep things compatible. - Jim

2 1

Maintenance of Boost.DateTime
by James E. King, III 28 Dec '17

28 Dec '17

The backlog for Boost.DateTime in trac has over 130 issues; the project is holding on to very old backwards compatibility code (pre-boost-1.33.0 i/o facets), and the CI builds do not currently have appveyor, codecov.io, or coverity scan integration. It needs a proper maintainer in order to resolve these issues, so I would like to ask for that privilege. Thanks, Jim

1 0

Appveyor and Travis CI notifications of Boost library tests
by Edward Diener 26 Dec '17

26 Dec '17

Is there a way to tell Appveyor or Travis CI to send notifications of its Build runs of Boost libraries to someone other than myself ?

4 7

Candidate for 1.66.1, if there is one
by James E. King, III 25 Dec '17

25 Dec '17

In Boost 1.66.0, there was a fix to date_time for the year 2038 problem: https://github.com/boostorg/date_time/pull/35 The serialization code in date_time had no static assertions enforcing the size of data values, and adding proper versioning support was missed in the release by myself and not picked up in the code reviews. As a result, serializing in anything written by earlier boost versions fails for date_time related structures, which might be considered serious enough to justify a 1.66.1 release. (We could also get the latest msvc compatibility in there I suppose...) I'm adding proper versioning right now, however Boost 1.66.0 will remain a problem since it serializes in/out as Version 0 with 64-bit values; and 1.65.1 serializes in/out Version 0 with 32-bit values so I'm not certain there will be a way to detect this issue. The issue is recorded in github here: https://github.com/boostorg/date_time/issues/56 Any additional thoughts are appreciated. I'm looking at adding a test to write out a version 0 and then read it in when the current version is 1, but I don't want to add test-only support code to the headers that get shipped, so if anyone can point me at a current example unit test that writes out a "n-1" version and then reads in a "n" version with boost::serialization I would appreciate it. Thanks, Jim

9 22

Getting Started
by ishan garg 25 Dec '17

25 Dec '17

Hello everyone, I am new to OpenSource Development. I know basics of C++ and acquainted with it's STL. I have basic knowledge of DSA as well as few git commands (clone, push, commit, etc). I wanted to know how can I start contributing to BOOST library? Thanks in Advance -- Regards, Ishan Garg

2 1

library maintainer list
by Robert Ramey 24 Dec '17

24 Dec '17

I'm curious about how I might go about discovering and contacting the person(s) who might be maintaining a particular library. As an example, I have a couple of questions about possible enhancements to the boost interval library (what about making this constexpr?). Ideally, I'd like to see a summary page for each library which steers me to the appropriate links like issues, comments/issues page, maintainence status etc. such as the boost library incubator has. Actually, I considered just adding these pages to the boost library incubator website, but I didn't have the motivation and it might stir a pot I personally don't want to stir right now. Robert Ramey

6 10

regarding mailing list traffic
by Mudit Sharma 22 Dec '17

22 Dec '17

Dear All, I have recently not been receiving the daily Boost mailing list digest, is there some maintenance work going on ? Thanks! M

2 1

[date_time] Trac 13194 - %e posix time_input_facet specifier behavior
by James E. King, III 21 Dec '17

21 Dec '17

https://svn.boost.org/trac10/ticket/13194 Just looking at this one, and looking at the documentation, it states that %e is the same as %d however when the value is less than 10, a leading space is to be used instead of a leading zero. The example in the description has a flaw, I believe, and I commented on that. Do folks agree with my comment? Should parsing fail if it says "December 5" (with one space) and the format string is "%B %e"? Valid input would be "December 5" (with two spaces). I also found that the code blindly ignores delimiter specifiers, so I opened a github issue for it: https://github.com/boostorg/date_time/issues/53. Comments appreciated there as well. Thanks, Jim

2 2

[endian] undefined behaviour in boost.endian
by Arvid Norberg 21 Dec '17

21 Dec '17

Hi, I've submitted an issue to the github project for boost.endian. I'm starting to wonder if this is in fact not the preferred channel for reporting issues. There are at least two separate issues causing undefined behaviour to be invoked in boost.endian. The first one is fundamentally based on the assumption that if the target architecture is x86, the C++ alignment requirements don't apply. I've posted more details here: https://github.com/boostorg/endian/issues/21 with a proposed patch here: https://github.com/boostorg/endian/pull/22 The second issue involves shifting negative integers, both invoking implementation defined and undefined behaviour. I don't have a patch to fix the issue, just to extend the tests to exercise the problem, which is then detectible with the undefined behaviour sanitizer. Patch is here: https://github.com/boostorg/endian/pull/24 I would really appreciate it if someone could review these and/or suggest a better venue than github to propose patches. thanks! -- Arvid Norberg

3 2

[build] Currently broken with Xcode 8?
by John Maddock 20 Dec '17

20 Dec '17

Current develop appears not to build with XCode 8.0 causing Travis tests to fail, for example: https://travis-ci.org/boostorg/config/jobs/318188889 Thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

5 6

[release] Boost 1.66.0
by Daniel James 19 Dec '17

19 Dec '17

Release 1.66.0 of the Boost C++ Libraries is now available. These open-source libraries work well with the C++ Standard Library, and are usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. This release contains N new libraries and numerous enhancements and bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/news/version_1.66.0> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.66.0/> To install this release on your system, see <http://www.boost.org/doc/libs/release/more/getting_started/index.html> Thanks to everyone who participated in this release. Thanks, -- The Boost Release Team Vladimir Prus, Marshall Clow, Eric Niebler, Daniel James, Beman Dawes

2 1

[release] 1.67.0 open for merging
by Daniel James 19 Dec '17

19 Dec '17

The master branch is open for merging all stable changes from develop, including bug fixes and major upgrades to existing libraries. Breaking changes should be coordinated via the mailing list with the developers of the other libraries affected. New libraries may be added, but require permission of a release manager. In other words, merging does not require permission from a release manager, except for new libraries. Boost Calendar with the release schedule: http://www.boost.org/development/index.html Release schedule explanation: https://github.com/boostorg/boost/wiki/Release-Schedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Boost Release Team

1 0

[release] 1.66.0 post-beta merges
by Daniel James 19 Dec '17

19 Dec '17

The master branch is is now open for post-beta merges, but only as described in the Post-Beta Merge Policy. See <https://github.com/boostorg/boost/wiki/Release-Beta-Merge-Policy>

14 32

[release] Boost 1.66.0 Release Candidate 2
by Daniel James 18 Dec '17

18 Dec '17

The second release candidates for the 1.66.0 release are now available at: <https://dl.bintray.com/boostorg/prerelease/> The in progress release notes are: <http://www.boost.org/users/history/in_progress.html> Library documentation is available at: <http://www.boost.org/doc/libs/1_66_0/> The SHA256 checksums are as follows: 596389389c005814ecb2a6b64c31dccd2c3e6fbc5a802b4dfada999ae5844628 boost_1_66_0_rc2.7z 5721818253e6a0989583192f96782c4a98eb6204965316df9f5ad75819225ca9 boost_1_66_0_rc2.tar.bz2 bd0df411efd9a585e5a2212275f8762079fed8842264954675a4fddc46cfcf60 boost_1_66_0_rc2.tar.gz e1c55ebb00886c1a96528e4024be98a38b815115f62ecfe878fcf587ba715aad boost_1_66_0_rc2.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

12 31

boost-1.66.0 tag?
by James E. King, III 18 Dec '17

18 Dec '17

I just refreshed Boost.Uuid locally and don't see a boost-1.66.0 tag. I had assumed this would be added by the upstream build and release procedure? Am I supposed to make that tag? - Jim

2 2

[chrono][timer][release] Non-inline functions in inlined headers
by Daniel James 14 Dec '17

14 Dec '17

Hi, We've had a link problem reported. for this code on Visual Studio, using auto-linking: #include "boost\chrono.hpp" #include "boost\timer\timer.hpp" int main() { auto now = boost::chrono::steady_clock::now(); boost::timer::cpu_timer cput; return 0; } I haven't got the binaries installed yet, so I haven't reproduced it, but I think it's caused because timer now includes the chrono headers using BOOST_CHRONO_HEADER_ONLY, and in the chrono inlined headers not all functions are BOOST_CHRONO_INLINE. It looks like this problem was always in chrono, but BOOST_CHRONO_HEADER_ONLY was widely used enough for it to be detected. I'd quite like to fix this for 1.66.0, which requires either reverting the change to timer, or fixing the problem in chrono. The error is in chrono, but I'm more inclined to revert the change in timer for this release, as it's a less disruptive way of quickly fixing the problem. https://github.com/boostorg/timer/pull/5

3 8

Building only x86 /MDd and /MT on msvc 2017
by Fredrik Stax{ng 13 Dec '17

13 Dec '17

The docs says For instructions on how to build only specific variants, please ask on the Boost.Build mailing list. but I gmane gives a 411 for Boost.Build so I ask the question here. For 1.60.0 I used this cd modular-boost rem call .\bootstrap .\b2 headers .\b2 toolset=msvc variant=debug address-model=32 link=static threading=multi runtime-link=shared .\b2 toolset=msvc variant=release address-model=32 link=static threading=multi runtime-link=static Has this changed? -- Fredrik Stax\"ang | rot13: sfgk(a)hcqngr.hh.fr This is all you need to know about vi: ESC : q ! RET

1 0

[beast] Security
by Phil Endecott 13 Dec '17

13 Dec '17

Dear All, To what extent do we think that Beast should be "secure"? I am thinking mostly about handling malicious input. Has it been reviewed by anyone with specific experience of how HTTP can be attacked? Has it been "fuzzed"? Regards, Phil.

6 10

linker error in 1.66 rc1 (regression from 1.65.1)
by Mark Incley 13 Dec '17

13 Dec '17

Hi, Using Visual Studio 2017 15.5, the following minimal test case causes a linker error with Boost 1.66 RC1 but builds fine with 1.65.1: Produces... 1>------ Build started: Project: aZ80, Configuration: Debug Win32 ------ 1>libboost_timer-vc141-mt-gd-x32-1_66.lib(cpu_timer.obj) : error LNK2005: "public: static class boost::chrono::time_point<class boost::chrono::steady_clock,class boost::chrono::duration<__int64,class boost::ratio<1,1000000000> > > __cdecl boost::chrono::steady_clock::now(void)" (?now@steady_clock@chrono@boost@@SA?AV?$time_point@Vsteady_clock@chrono@boost@@V?$duration@_JV?$ratio@$00$0DLJKMKAA@@boost@@@23@@23@XZ) already defined in libboost_chrono-vc141-mt-gd-x32-1_66.lib(chrono.obj) 1>libboost_timer-vc141-mt-gd-x32-1_66.lib(cpu_timer.obj) : error LNK2005: "double __cdecl boost::chrono::chrono_detail::get_nanosecs_per_tic(void)" (?get_nanosecs_per_tic@chrono_detail@chrono@boost@@YANXZ) already defined in libboost_chrono-vc141-mt-gd-x32-1_66.lib(chrono.obj) 1>C:\Projects\aZ80\vs\Debug\aZ80.exe : fatal error LNK1169: one or more multiply defined symbols found Swapping the order of the includes appears to workaround the problem. Mark. -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 5

[release] Boost 1.66.0 Release Candidate 1
by Daniel James 11 Dec '17

11 Dec '17

The release candidates for the 1.66.0 release are now available at: <https://dl.bintray.com/boostorg/release/1.66.0/source/> The in progress release notes are: <http://www.boost.org/users/history/in_progress.html> Library documentation is available at: <http://www.boost.org/doc/libs/1_66_0/> The SHA256 checksums are as follows: c9d29486dd12f19d321da65eb5f0a157ec0f0edfd4701ade48c644310c8f0676 boost_1_66_0_rc1.7z 6232f7e7873b2d1f112fb62c726f7066e9a7e0643ed2aac7d31d20bf5749fbc0 boost_1_66_0_rc1.tar.bz2 30ad6d1c7380d6e6a87ce1bc54388ab957de67a2e8fa44dd3c106eafad0f6ac2 boost_1_66_0_rc1.tar.gz cd2c64f243c89e04329e94f3b803f0744171b44fee7a8b4e3256b3a625dcbd1c boost_1_66_0_rc1.zip As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

5 5

Info: Boost.Config is older than your compiler version - message is surprising
by Paul A. Bristow 11 Dec '17

11 Dec '17

I've just updated to the latest and greatest Visual Studio 15.5 and also got my Boost develop branch up-to-date. But I'm still getting this message: "Info: Boost.Config is older than your compiler version - probably nothing bad will happen - but you may wish to look for an updated Boost version. Define BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE to suppress this message." I've just rebuilt my library files that have the new -x64- x32 in the name (great - but grrrr because I have had to change all my command files to generate them, previously in /x64 and /win32 folders ;-) The library files have names like libboost_chrono-vc141-mt-x64-1_66.lib so version number is still at 1.66 (a fact confirmed by the config_info Boost version 106600) The config_info.txt output is attached. So I am surprised to get this potentially useful warning. It would *much* more helpful if the warning told which version number of both compiler and Boost? (Just like the 'File not found' message that provokes "Which *&%$%^!!ing file" expletives). Paul PS The Good news is that defining BOOST_CONFIG_SUPPRESS_OUTDATED_MESSAGE quiets as promised. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

4 15

Help requested for boost documentation for polymorphic_value
by Jonathan Coe 11 Dec '17

11 Dec '17

I have been preparing polymorphic_value for submission to boost. I have draft documentation here: https://drive.google.com/open?id=1xpD8s8zDzedVDDlqjsl1JtYGaJBHWoGy but am having problems generating doxygen docs. A forward declaration seems to stop generation of docs for methods of polymorphic_value. I'm at a loss as to why doxygen is not working properly for boost doc (it works fine when run in isolation) and would be grateful for any insight anyone can offer. I suspect it's a simple problem but I'm not very experienced with doxygen and am new to the boost docs tools. source is here: https://github.com/jbcoe/polymorphic_value/tree/boost regards, Jon

2 2

Optional third-party libraries
by James E. King, III 09 Dec '17

09 Dec '17

The boost documentation on the web site talks about building boost from source, but I don't see information on how to leverage optional third party libraries easily accessible in the documentation from the place the user will most likely end up: "Building From Source". This information seems to be tucked away in documentation of various components, making it difficult to actually build a complete boost. I think it would be a good idea to bring this information up to the top level build instructions, at the very least itemize these third party packages and then link to the relevant project-specific documentation pages that talk about configuring to use them. Here are the third party optional libraries I know about so far and the libraries that use them: bzip2 (iostreams) iconv (locale - if icu not available) icu (locale, regex) lzma (iostreams) openssl (asio, beast) pthread-win32 (sync, thread) zlib (beast, gil, iostreams) Any others? Would folks find it useful if this information was part of the standard "Building From Source" sections of the upper layers of documentation? Thanks, Jim

5 5

[config] msvc-15.5, updating tests
by John Maddock 09 Dec '17

09 Dec '17

While working on updating Boost.Config for msvc-15.5 I've managed to break the test case for boost_no_cxx17_iterator_traits (both GCC and msvc agree on this) but can't see what's wrong :( The change is this one: https://github.com/boostorg/config/commit/305f5a58ef879037b0fd9fdaa8e05615c… which removes use of std::iterator as a base class. Anyone any ideas? Many thanks, John. --- This email has been checked for viruses by AVG. http://www.avg.com

2 2

[release] Boost 1.66.0 Beta 1 Release Candidate 1
by Daniel James 09 Dec '17

09 Dec '17

The release candidates for the 1.66.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/> The SHA256 checksums are as follows: 0e137e61069e95f61fe0e46aa4a5432e65e209e87d470ea3c15b0ea1327583ac boost_1_66_0_b1_rc1.7z eff4854c1a672830c55fd2323ebe42d5d83e0f7a3d0a9d354d8bf55289831fa0 boost_1_66_0_b1_rc1.tar.bz2 f4fb07aa1ec639707570e42a848796d9a8155f23d1ece0f0a6a0cbee99807038 boost_1_66_0_b1_rc1.tar.gz d5f480441223f45427199697edbdd78145499084f835597247a452d2a7e1e798 boost_1_66_0_b1_rc1.zip The in progress release notes are at: <http://www.boost.org/users/history/in_progress.html> And the documentation is at: <http://www.boost.org/doc/libs/1_66_0_beta1/> As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

11 42

[beast] Security Review: Hybrid Application Assessment
by Vinnie Falco 09 Dec '17

09 Dec '17

Since 2005, Bishop Fox has provided security consulting services to the Fortune 1000, high-tech startups, and financial institutions worldwide. The author of Beast, Vinnie Falco, engaged Bishop Fox to assess the security of the Boost C++ Beast HTTP/S networking library. The following report details the findings identified during the course of the engagement, which started on September 11, 2017. The assessment team conducted a hybrid application assessment of the Beast library. Bishop Fox’s hybrid application assessment methodology leverages the real-world attack techniques of application penetration testing in combination with targeted source code review to thoroughly identify application security vulnerabilities. These full-knowledge assessments begin with automated scans of the deployed application and source code. Next, analyses of the scan results are combined with manual review to thoroughly identify potential application security vulnerabilities. In addition, the team performs a review of the application architecture and business logic to locate any design-level issues. Finally, the team performs manual exploitation and review of these issues to validate the findings. <https://vinniefalco.github.io/BeastAssets/Beast%20-%20Hybrid%20Application%…> Note: The permessage-deflate vulnerability described in the report is confirmed to be fixed in the version of Beast which is included in Boost 1.66.0 Thanks

1 0

Requesting endorsements for YAP review
by Zach Laine 07 Dec '17

07 Dec '17

I mailed the list several months ago about YAP, an expression template library written against C++14 and later standards. The sources can be found here: https://github.com/tzlaine/yap and online docs here: https://tzlaine.github.io/yap I'd like to put this in the review queue, and so I'm looking for endorsements for this. At the time of my initial emails, there was some interest, but not much. Expression templates are a niche technology, so this makes sense. I'm trying to make ETs less expert friendly, so that they leave their experts-only niche. I feel this library does a fairly good job of that. If you do too, please endorse! Thanks, Zach

4 4

Discovering and handling missing override keyword in project conversion
by James E. King, III 06 Dec '17

06 Dec '17

I'm in the middle of converting a large project from C++03 to C++14, and of course crossing the C++11 gap, I want identify all of the places where the override keyword should be used but is not, and add it. When I turned on -Wsuggest-override in gcc-7.2 I got a fair number of warnings from boost code, for example: ...boost/program_options/value_semantic.hpp:304:14: error: â€˜bool boost::program_options::typed_value<T, charT>::is_composing() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] bool is_composing() const { return m_composing; } ^~~~~~~~~~~~ ...boost/program_options/value_semantic.hpp:306:18: error: â€˜unsigned int boost::program_options::typed_value<T, charT>::min_tokens() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] unsigned min_tokens() const ^~~~~~~~~~ ...boost/program_options/value_semantic.hpp:315:18: error: â€˜unsigned int boost::program_options::typed_value<T, charT>::max_tokens() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] unsigned max_tokens() const { ^~~~~~~~~~ ...boost/program_options/value_semantic.hpp:325:14: error: â€˜bool boost::program_options::typed_value<T, charT>::is_required() const [with T = std::basic_string<char>; charT = char]â€™ can be marked override [-Werror=suggest-override] bool is_required() const { return m_required; } ^~~~~~~~~~~ (There were others - this is just a small sample) This is probably not the first time this has been brought up, but there is no BOOST_OVERRIDE (or BOOST_FINAL, for that matter) definition in Boost.Config that would allow Boost itself to be compatible with C++03 or C++11 cleanly relative to this language feature. I found a number of posts about this issue elsewhere. Has this issue been discussed here before? I could spend some time adding this to Boost.Config and then making boost compile cleanly with cxxstd=03,11 toolset=gcc-7 cxxflags="-Wsuggest-override", as it would help support a more complete conversion to the new language level for projects, and it would enable existing projects to turn on the warning to improve their code, as well as improve Boost. Thoughts? - Jim

1 0

[release] 1.66.0 closed for release
by Daniel James 06 Dec '17

06 Dec '17

The master branch is now closed for all changes except by permission. The commit-bot isn't running on master, so the super project will need to be manually updated for any changes. If all goes well, the release candidate should be out this weekend. You can still modify the release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.q…> Thanks, -- The Boost Release Team

1 0

Policy for breaking changes
by Louis Dionne 05 Dec '17

05 Dec '17

Hi all, So far, I've been careful about not doing any breaking changes to Hana. Hana obeys semantic versioning, and I'm accumulating desirable breaking changes until I'm ready to publish a new major version. I'm wondering what's the policy for major breaking changes with Boost libraries. For example, let's say I wanted to do an update of Hana with C++17 features; this would be a large breaking change, with all kinds of API changes, etc.. - Are such drastic changes prohibited altogether? Or perhaps they’re not prohibited but there’s historical evidence showing it’s always a bad idea? - Do such changes require going through a mini review? - Is it customary to leave the old version of the library there in a separate directory (or put the new one in a separate directory)? I think Spirit does that, e.g. Spirit Classic is still available IIRC. I think I know the answer to these questions from observing other author's behavior, but I'd like to see what the community thinks about this. It has an impact on the Boost libraries as a whole, since a major breaking change in one library could prevent users from updating Boost as a whole, which has an impact on all of us. I'm looking forward to hearing other people's thoughts on the matter. Thanks, Louis

18 30

[type_index] type names string cross-platformness
by Damien Buhl 05 Dec '17

05 Dec '17

Dear Boost, MSVC differs from GCC & Clang in the way it present the pretty_name of a type_info within Type Index. Indeed for the following type : struct why {}; Is presented as `struct why` while on GCC it is `why`. Is there any reason why pretty_name wouldn't strip / add the information from one of the compiler in order to reach a cross-plaftorm string name of types ? MSVC:http://rextester.com/QNMB58390 <http://rextester.com/QNMB58390> GCC: http://coliru.stacked-crooked.com/a/1aa52003605d4936 Would such a patch to the library be possible & welcome ? Best regards, -- Damien Buhl Software Developer +33 6 77 43 10 05

2 1

MSVC 15.5 support
by Olaf van der Spek 05 Dec '17

05 Dec '17

Hi, 15.5 Preview has been released: https://blogs.msdn.microsoft.com/vcblog/2017/10/11/productivity-structure-v… > Unknown compiler version - please run the configure tests and report the results How do I do this? Could this message be updated to indicate it comes from Boost? Gr, -- Olaf

4 7

Announcement: Faber, a new build system based on bjam
by Stefan Seefeld 05 Dec '17

05 Dec '17

Hello, about a year ago I started to experiment with a new Python frontend for Boost.Build. After many iterations of prototyping things are starting to fall into place, and the project stabilizes. I'm thus happy to announce the release of Faber version 0.2: code: https://github.com/stefanseefeld/faber docs: https://stefanseefeld.github.io/faber While Faber retains most of the features from Boost.Build, it is redesigned from the ground up. bjam is still used as scheduling engine, but everything else is written in Python. In particular, Jamfiles are replaced by fabscripts, which are essentially Python scripts. The project contains a range of examples to demonstrate various simple use-cases, from a simple "hello world" example to demos involving autoconf-style config checks, and unit testing. I have added build logic to Boost.Python to use Faber on Travis-CI as well as AppVeyor, which also is a good litmus test for Faber's capabilities. I'd be very interested in feedback as well as contributions. Perhaps it might become possible one day to integrate Faber with other efforts to add a Python frontend to Boost.Build. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

13 48

BOOST_PRAGMA_MESSAGE?
by Peter Dimov 04 Dec '17

04 Dec '17

In what module does the following utility macro: #if defined( __GNUC__ ) #define BOOST_PRAGMA_MESSAGE_IMPL_1( x ) _Pragma( #x ) #define BOOST_PRAGMA_MESSAGE( x ) BOOST_PRAGMA_MESSAGE_IMPL_1( message( x ) ) #elif defined( _MSC_VER ) #define BOOST_PRAGMA_MESSAGE_IMPL_2( x, f, ln ) __pragma( message( f "(" #ln "): note: " x ) ) #define BOOST_PRAGMA_MESSAGE_IMPL_1( x, f, ln ) BOOST_PRAGMA_MESSAGE_IMPL_2( x, f, ln ) #define BOOST_PRAGMA_MESSAGE( x ) BOOST_PRAGMA_MESSAGE_IMPL_1( x, __FILE__, __LINE__ ) #else #define BOOST_PRAGMA_MESSAGE( x ) #endif belong? Use: BOOST_PRAGMA_MESSAGE( "something" ) MS output: .\testbed.cpp(10): note: something g++ output: testbed.cpp:10:35: note: #pragma message: something BOOST_PRAGMA_MESSAGE( "something" ) ^

3 10

[accumulators] No maintainer?
by Sergiu Deitsch 04 Dec '17

04 Dec '17

Boost.Accumulators does not seem to have an active maintainer anymore. My PR hast been waiting for any reaction from a maintainer for over a year now. Can someone of the Boost devs take a look at my (pretty trivial) PR at https://github.com/boostorg/accumulators/pull/5 and possibly merge it?

3 2

[hash][array][stacktrace][type_index] Adding noexcept to hash
by Daniel James 04 Dec '17

04 Dec '17

Hi, I want to add noexcept support to the hash library, but a few libraries (array, stacktrace, type_index, maybe more) forward declare hash_range for themselves, causing errors if I add a noexpect specifier to hash_range. If I move hash_fwd.hpp into the core module, so that it doesn't add a dependency on the functional module, would they be okay with including it from there? thanks, Daniel

2 4

Re: [boost] PSA: Travis OS X bottleneck, <cxxstd> new Boost.Build feature
by Robert Ramey 02 Dec '17

02 Dec '17

On 11/29/17 1:10 AM, Boris Kolpackov wrote: > In this light, I think it makes more sense to ask Boost users > who are using Boost on Mac OS to contribute hardware resources > for CI testing. This is the right idea. Let's go the full monte and take it to it's logical conclusion. a) Encourage users to run tests on the libraries they use by making testing more user friendly. b) Create a CMake or CMake-like dashboard where users can more or less automagically post their results to a common database. Presumable boost regression.py does something similar already. c) Create a program to permit display of this giant "data cube" according to the needs of the user/developer. My personal contribution to moving in this direction can be found at https://github.com/robertramey/library_status This permits me to: a) run the serialization test suite with boost build. This is a single button which builds all the libraries that the serialization depends upon, and runs all the tests. b) The results are displayed on a giant cumulative matrix which permits me to see which tests are failing on which platforms. Here is a recent copy of that matrix http://htmlpreview.github.com/?https://github.com/robertramey/library_statu… more information is available here: http://htmlpreview.github.com/?https://github.com/robertramey/library_statu… If this idea were implemented we would have: a) recent tests on all platforms actually being used regardless of how obscure. b) an easily browsable data base of test results. c) less dependency on centralized CI testing resources d) less pressure on boost testers e) more people participating and being a member of the boost community - helping to promote the "Boost Brand (c)" f) Since Appveyor, Travis, regression.py, and individual users would be posting all results to a common database, we'd be decoupling test results presentation from any particular testing platform. g) Should CMake solution every get accepted, it could easily be adjusted to post the the database as well. Boost needs this going back at least a decade. Robert Ramey

1 0

[release] 1.66.0 closing for release on Wednesday
by Daniel James 02 Dec '17

02 Dec '17

There's still a little time for any remaining bug fixes, documentation updates and release notes. Schedule: 6 Dec - Closed for all changes, except by permission of a release manager 9 Dec - Closed for all changes 13 Dec - Boost 1.66.0 release You can edit the release notes here: https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.q…

5 13

[contract] move operations and class invariants
by Lorenzo Caminiti 01 Dec '17

01 Dec '17

Hello all, This is not really a question about Boost.Contract, but more a question on how contract programming interacts with C++ move operations. C++ requires that moved-from objects can still be destructed. Because contract programming requires class invariants to hold at destructor entry, it follows that moved-from objects must still satisfy class invariants. That sounds restrictive... and it might force the class invariants to be empty. For example, for vector a class invariant is size() <= capacity(). Should that sill hold after the vector has been moved? That means I can still call size() and capacity() on a moved-from object, which might not be the case. If some sort of moved() function could be called on a moved-from object, the invariants could be programmed as follow to work around this issue: class vector { void invariant() cont { if(!moved()) BOOST_CONTRACT_ASSERT(size() <= capacity()); ... // Only invariants that are truly needed to execute the destructor. } bool moved() const; public: vector(vector&& other) { boost::contract::check c = boost::contract::constructor(this) .postcondition([&] { BOOST_CONTRACT_ASSERT(!moved()); BOOST_CONTRACT_ASSERT(other.moved()); }) ; ... } ... }; I'm not really sure... What do you think? Do you know if this topic "C++ move & class invariants" has already been discussed somewhere? Thanks. --Lorenzo

6 11

Re: [boost] [contract] move operations and class invariants
by Peter Dimov 01 Dec '17

01 Dec '17

Lorenzo Caminiti wrote: > > read() can fail, so you can drop its "valid" precondition and just fail > > when the handle is invalid. > > Calling read() on a moved-from object so violating its is_valid() > precondition is a bug, not a run-time error while reading the file. The > precondition legitimately remains in place to catch bugs, even after it is > noted that read() can fail because of file-system or other run-time > errors. On one hand, you want to have a precondition. On the other, you say that if you have the precondition, the class would be crippled and not very useful: >> 2. How useful is a class like the one above with "crippled" invariants >> and is_valid() preconditions on all its useful public methods like >> read()? The answer seems to be: not very useful. These are contradictory. Either the class that has preconditions is crippled and not very useful, in which case we drop the preconditions as I suggest; or it's useful, in which case we keep them.

1 0

[spirit] x3 status and docs?
by Andrey Semashev 29 Nov '17

29 Nov '17

Hi, I'm wondering what is the status of Boost.Spirit x3? Is it considered stable and ready for production use? If yes, how can I find its docs? There seem to be no mention of x3 in the docs on the Boost website.

3 2

[histogram] Working with standard algorithms
by Bjorn Reese 29 Nov '17

29 Nov '17

I would like to see a better integration between boost.histogram and standard algorithms, especially those from <numeric>. Today they do not work together because the dereference operator of the axis iterator returns a pair (index and content) rather than the content. An example of where standard algorithms could be useful is calculating the cumulative distribution of a one-dimensional histogram, which ought to be a simple as: auto& axis = h.axis(); std:partial_sum(axis.begin(), axis.end(), axis.begin()); Another example is ranking a set of histograms based on the cosine similarity [1] using std::inner_product(). [1] https://en.wikipedia.org/wiki/Cosine_similarity

2 4

[release][fusion] Permission to merge
by Kohei Takahashi 29 Nov '17

29 Nov '17

Hi release manager, I'd like to merge a PR, which fixes a regression on buggy compiler. https://github.com/boostorg/fusion/pull/162 Boost.regression shows the test was passed on develop. Regards, Kohei Takahashi

1 0

[Build] x32
by Olaf van der Spek 28 Nov '17

28 Nov '17

Hi, > libboost_system-vc141-mt-gd-x32-1_66.lib Why is this named x32? AFAIK the normal name is x86. -- Olaf

5 4

Re: [boost] Adding polymorphic_value to boost
by Phil Endecott 28 Nov '17

28 Nov '17

Peter Dimov wrote: > You can have > > vector<polymorphic_value<Shape>> v; > > and then > > v.push_back( Circle(10) ); > v.push_back( Ellipse(10, 15) ); > v.push_back( Square(11) ); Good example. Yes please. There's another way of implementing this, though; rather than pointing to the object in the heap you can store it in-place by allocating enough space for the largest possible derived subclass: class Base { ... }; class Derived: public Base { ... }; template <typename B> class polymorhpic_value_2 { B base; char enough_space_for_dervided_classes_members[1024]; public: template <typename D> // requires D is same as or derived from B void operator=(const D& d) { B::~B(this); new (this) D(d); } }; polymorphic_value_2<Base> p; Derived d; p = d; That's just a sketch; many details omitted! There are some obvious advantages and disadvantages of each approach and I'm definitely not saying this is better than the pointer-to-heap design. But I mention it for this reason: * If your proposed interface for polymorphic_value could also work for this method of implementation, then it is probably a better interface. > It's unfortunate we have to use -> instead of . but that's what's available. There have been proposals for operator. ; has this been evaluated to see how it would work with them? Similarly the unified a.b() vs. b(a) syntax proposal. Regards, Phil.

4 6

Outcome v2 peer review dates set
by Niall Douglas 28 Nov '17

28 Nov '17

Outcome v2 will be up for its post-peer-review second review between Friday 19th January and Sunday 28th January with Charley Bay once again serving as review manager. In case you'd like to give it a whirl before then: Docs: https://ned14.github.io/outcome/ Single file edition: https://github.com/ned14/outcome/raw/develop/single-header/outcome.hpp Boost edition repo: https://github.com/ned14/boost-outcome Standalone edition repo: https://github.com/ned14/outcome List of changes since v1: https://github.com/ned14/outcome#changes-since-v1 Compilers needed: GCC 6, clang 4, VS2017 (C++ 14 minimum, C++ 20 preferred) Acknowledgements ---------------- This post-peer-review complete rebuild of Outcome was actually a collaborative effort by a number of the Boost community, and it has been significantly influenced for it. I'd firstly like to thank Charley for taking on the role of review manager for a second time, especially given that he knows from the first time what an awful lot of work it's going to be for him. I am *hoping* that seeing as v2 Outcome is literally a tick box set of the changes you guys recommended last time, that this review will be a quick and simple review. We shall see. I'd like to thank Andrzej for writing the beginning of the tutorial. It set the tone and pacing which I then extended to the rest of the tutorial, and I think the benefit of that shows through as this should be a vast improvement on the (many) v1 tutorials. Andrzej also found many bugs, asked many clever "stupid questions", and acted as a constant peer reviewer throughout the development of v2, including suggesting the present design for payload transport. Andrzej has had a huge influence in the shape, and direction, of this library. I cannot thank him enough, and although he declined being listed as coauthor, I'm thinking of "special thanks to" or something like that in the authorship list as he went above and beyond in his contribution. I'd like to thank Jonathan Müller for doing so much work on his Standardese tool to support Outcome. The current reference API docs on the Outcome website are but a wisp of what will hopefully be in place by the time of the review. Jonathan has had to wrestle with many libclang demons smoked out by Outcome pushing the state of the art, and will have to wrestle with many more yet, but already the huge improvements over the doxygen reference API docs are evident. If anybody has any questions or feedback between now and the review, please let rip. Otherwise thanks for reading! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

1 0

Fwd: Using 'detail' folder from a another Boost library
by Jean Guegant 27 Nov '17

27 Nov '17

Hi everyone, I am trying to unify the way Boost.Beast and Boost.Asio pick an implementation of string_view (std::experimental::string_view, std::string_view). In order to do so, I am including the header file <boost/asio/detail/string_view.hpp> within <boost/beast/core/string.hpp> (see PR: https://github.com/boostorg/ beast/pull/910/files). Is that a bad practice to include the a "detail" folder from another library? If so, what would you recommend to solve my unification problem? Sincerely, Jean

2 1

Getting started with open source
by Faisal Riyaz 26 Nov '17

26 Nov '17

Hi, I am Faisal.I am new to open source community.I am familiar with C and C++ language.I am pursuing computer engineering and presently i am in first year.I am interested in contributing to your organisation and learn some stuff. It will be very helpful for me if someone can help me get started. Faisal Riyaz

1 0

[release][build] Permission to merge
by Jürgen Hunold 22 Nov '17

22 Nov '17

Hi! I'd like to merge commit e07c805e to master. This fixes https://github.com/boostorg/build/issues/236 with my PR from https://github.com/boostorg/build/pull/263 Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * jhunold(a)gmx.eu ! Germany

2 1

[optional] regression failures on Linux teeks
by Lorenzo Caminiti 22 Nov '17

22 Nov '17

Hello all, I see the following Boost.Option regression test failures on develop branch: http://www.boost.org/development/tests/develop/developer/optional.html === error 1 === Test output: teeks99-02-dc3.7-14-Docker-64on64 - optional - optional_test_conversions_from_U / clang-gnu-linux-3.7~c++14 Rev 05c2033df7b99d19f4939bf81ca2aeeec592993d / Fri, 03 Nov 2017 00:24:42 +0000 Compile [2017-11-03 01:39:15 UTC]: fail "clang++-3.7" -c -x c++ -Wno-c99-extensions -std=c++14 -O0 -g -fno-inline -Wall -g -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -I".." -o "/var/boost/run/results/boost/bin.v2/libs/optional/test/optional_test_conversions_from_U.test/clang-gnu-linux-3.7~c++14/debug/threadapi-pthread/optional_test_conversions_from_U.o" "../libs/optional/test/optional_test_conversions_from_U.cpp" In file included from ../libs/optional/test/optional_test_conversions_from_U.cpp:12: In file included from ../boost/optional/optional.hpp:64: ../boost/optional/detail/optional_config.hpp:152:48: error: expected value in expression # if BOOST_WORKAROUND(BOOST_GCC, >= 50000) && ^ 1 error generated. === error 2 === Test output: teeks99-02-dc5-1z-lc-Docker-64on64 - optional - optional_test_conversions_from_U / clang-gnu-linux-5.0~c++1z~lc Rev 420dd51fb237f5e75cae0aeb01ec427717e4a748 / Sat, 04 Nov 2017 15:00:43 +0000 Compile [2017-11-04 15:49:56 UTC]: fail "clang++-5.0" -c -x c++ -Wno-c99-extensions -std=c++1z -stdlib=libc++ -isystem/usr/include/libcxxabi -O0 -g -fno-inline -Wall -g -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -I".." -o "/var/boost/run/results/boost/bin.v2/libs/optional/test/optional_test_conversions_from_U.test/clang-gnu-linux-5.0~c++1z~lc/debug/threadapi-pthread/optional_test_conversions_from_U.o" "../libs/optional/test/optional_test_conversions_from_U.cpp" In file included from ../libs/optional/test/optional_test_conversions_from_U.cpp:18: In file included from ../boost/core/lightweight_test.hpp:25: In file included from /usr/include/c++/v1/iostream:38: In file included from /usr/include/c++/v1/ios:216: In file included from /usr/include/c++/v1/__locale:15: /usr/include/c++/v1/string:1942:14: error: expected ';' at end of declaration _NOEXCEPT ^ /usr/include/c++/v1/string:1947:9: error: expected unqualified-id _NOEXCEPT ^ /usr/include/c++/v1/__config:368:21: note: expanded from macro '_NOEXCEPT' # define _NOEXCEPT noexcept ^ 2 errors generated. === The first error only shows on develop, the second error shows up on both develop and master regression tests. Do you know what the issue is on this toolset/platform? I am asking because Boost.Contract uses Boost.Option so it is showing the same failures. Thank you. --Lorenzo

5 7

Re: [boost] [contract] _NOEXCEPT errors in <ostream> for Clang 5.0 C++1z on Teeks Linux
by Lorenzo Caminiti 22 Nov '17

22 Nov '17

Hello Tom, On Tue, Nov 21, 2017 at 7:16 PM, Tom Kent <lists(a)teeks99.com> wrote: > On Mon, Nov 20, 2017 at 9:06 PM, Tom Kent <lists(a)teeks99.com> wrote: >> >> I was able to get to the bottom of this, I hope the libc++ builds start >> cycling normally now. >> >> > This was marked (by me!) as a clang bug - that was fixed in clang trunk >> > in January 2013. >> > I find it hard to believe that you're running a clang built from those >> > sources. >> > >> > -- Marshall >> >> It turns out I had put in a script patch the broken ubuntu header: >> >> https://github.com/teeks99/boost-cpp-docker/blob/11e6d31ca8d28dee8bbb5536f2… >> >> This was a very brittle patch, and when ubuntu fixed it upstream (just two >> months ago!) it caused some kind of conflict. I've removed the patch from my >> teeks99/boost-cpp-docker images, so the clang-3.9, -4, -5, and -6 images >> should be able to use libc++ correctly now. >> >> Thanks for all who helped me straighten this out! >> > > There was a further issue with the need for a `-lc++abi` linker option, it > has been added and the results look better now. Yes, Boost.Contract regression tests now pass on this compiler/platform. The issue was fixed. Thanks a lot. --Lorenzo

1 0

Re: [boost] Interest for Algorithmic Adjoint Differentiation (AAD) in Boost?
by Antoine Savine 22 Nov '17

22 Nov '17

I just realized that the attachment exceeds (by far) the maximum size. With apologies (this is my first post), re-posting now without the attachment. The introduction can be found at the top level of the repository, under the name AADIntro.pdf Thank you. Antoine Savine From: Antoine Savine Sent: 22 November 2017 12:38 To: 'boost(a)lists.boost.org' <boost(a)lists.boost.org> Subject: Interest for Algorithmic Adjoint Differentiation (AAD) in Boost? AAD is a hot topic in machine learning, computational finance, and, I think, other disciplines such as meteorology. Adjoint differentiation computes a large number of derivatives sensitivities for some calculation code in constant time, and operator overloading in C++ permits its semi-automatic implementation over templated code. Please see the intro attached for details. I have been working with AAD (in finance) for 5 years. I have been developing and using professional AAD libraries, I have given dedicated talks and workshops at professional conferences such as Global Derivatives and WBS, and I have been teaching AAD at the MsC in Mathematical Finance at the Copenhagen University in Denmark (Mathematics Department). Our implementation in Danske Bank obtained in 2015 the In-House System of the Year 2015 Risk award. I am planning a book on AAD. And, although that publication is biased towards finance, I have developed an independent, simple and efficient AAD engine that can be found here: tinyUrl.com/aadCentral The implementation uses the latest developments in AAD technology for maximum performance, in particular expression templates. I thought that given the wide interest for AAD, a Boost.Aad module could make sense and I was hoping that it could be based on my developments. Please could somebody let me know if there is interest, and, if so, how I should proceed? Million thanks. Kind regards, Antoine Savine

1 0

[release][poly_collection] Permission to merge to release
by Joaquin M López Muñoz 22 Nov '17

22 Nov '17

Hello, I'm asking for permission to merge the following commit chain into release: https://github.com/boostorg/poly_collection/commit/3609895bd01e5add5971345a… https://github.com/boostorg/poly_collection/commit/18b7d88df360001c2c006f02… https://github.com/boostorg/poly_collection/commit/ce7e7aac60747c6fad5e97d2… https://github.com/boostorg/poly_collection/commit/ab32df47f8811dc7f136a166… https://github.com/boostorg/poly_collection/commit/df754527917b7be013ce558f… Fixes bring compatibility with Clang 3.3 and solve a potential UB problem related to CWG 232 and detected at http://www.boost.org/development/tests/develop/developer/Marshall-UBSAN-pol… I'm waiting for Marshall-UBSAN to cycle through these but all recently updated test runners are working fine. Clang 3.3 is already verified to work by teeks99-02-dc3.3-11-Docker-64on64. Thank you, Joaquín M López Muñoz

2 2

Adding polymorphic_value to boost
by Jonathan Coe 22 Nov '17

22 Nov '17

I'd like to propose adding the class-template `polymorphic_value` to boost. `polymorphic_value` is designed to allow the compiler to correctly generate special member functions for classes with polymorphic components (It's `any` with an interface). `polymorphic_value` has been proposed for standardisation in P0201 and has advanced through the Library Evolution group in Albuquerque (Nov 5-10). https://wg21.link/p0201 A working draft of the proposal and implementation can be found at https://github.com/jbcoe/polymorphic_value I gave a presentation about polymorphic_value at C++::London here: https://skillsmatter.com/skillscasts/9539-a-polymorphic-value-type-for-c-pl… Matt Calabrese has kindly offered to be review manager. Kind regards, Jon

17 56

[release] Boost 1.66.0 Beta 1
by Daniel James 21 Nov '17

21 Nov '17

Boost release 1.66.0 beta 1 is now available at: <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/> The SHA256 checksums are as follows: e7b23e638e8c3a9da1512439385b04850829cea7bd56d8398677c096857d830b boost_1_66_0_b1.7z 5d0405eb73bd609ebcd54bbc96d4f1e2d97c51b96c4703706695ddd94f942d6b boost_1_66_0_b1.tar.bz2 f0f455e39bc47b2b670a17cb221687506e9a22dc478956d3d8aabb9cb835a7dc boost_1_66_0_b1.tar.gz 694c8b9e902b7981670bce166f675f3875c19326936db51aabd98d2ddfea9b45 boost_1_66_0_b1.zip For details of what's in the release, see <http://www.boost.org/users/history/version_1_66_0.html>. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

2 1

icl mainainership?
by Avi Kivity 21 Nov '17

21 Nov '17

Hello, I see there are 7 pull requests outstanding against icl (including one of mine), but not activity. Joachim, are you still maintaining the library? If not, perhaps someone can step up.

3 4

Fwd: Adding polymorphic_value to boost
by THOMAS JORDAN 20 Nov '17

20 Nov '17

On 19 November 2017 at 23:41, <boost-request(a)lists.boost.org> wrote: > > Message: 12 > Date: Mon, 20 Nov 2017 01:41:10 +0200 > From: "Peter Dimov" <lists(a)pdimov.com> > To: <boost(a)lists.boost.org> > Subject: Re: [boost] Adding polymorphic_value to boost > Message-ID: <E0D82A60493A491CBFFD0E264E3917D1@pdimov5> > Content-Type: text/plain; format=flowed; charset="iso-8859-1"; > reply-type=original > > Peter Bartlett wrote: > > > The only nit I had in the paper was that after all the banging on about > it > > being a value type, we are given operator bool, operator* and operator->, > > making it pointer-like again. Could operator T& and operator T const& > > work? > > Polymorphic means virtual functions, and when you have a > polymorphic_value<T> pv, where T has a virtual function `f`, you can call > `pv->f()`. With a conversion to T&, you can't call `pv.f()`. > I believe I've seen other libraries (maybe Optional) provide the helpful comment above accessors used like this to the effect that 'this accessor syntax does not imply pointer semantics.' I guess -> and * accessors would not be required if there was such as thing as overloaded dot operator.

1 0

MSVC toolset versions on VS2017
by Tom Kent 20 Nov '17

20 Nov '17

I just came across this article on feature updates for their compiler during the VS2017 lifetime, I thought the section talking about version numbers might be of interest to the boost build maintainers and boost config maintainers. The blog post can be found here: https://blogs.msdn.microsoft.com/vcblog/2017/11/15/msvc-conformance-improve… The interesting part about version numbers is three-quarters of the way down the post, under the "MSVC toolset version number increases to 14.12". The table that they have there is also illuminating: Visual Studio Version | MSVC Toolset Version | _MSC_VER --------------------------------------------------------------- VS2015 and updates 1, 2, & 3 | v140 in VS; version 14.00 | 1900 VS2017, Version 15.1 & 15.2 | v141 in VS; version 14.10 | 1910 VS2017, Version 15.3 & 15.4 | v141 in VS; version 14.11 | 1911 VS2017, Version 15.5 | v141 in VS; version 14.12 | 1912 --------------------------------------------------------------- Just wanted to give people a heads-up that this is something that may be encountered in the wild soon. Tom

2 1

[multiprecision]: 15% slowdown using -std=c++11 compiler flag
by Kim Walisch 20 Nov '17

20 Nov '17

I have been investigating a 15% performance regression in my C++ primesum program (https://github.com/kimwalisch/primesum/tree/256-bit) over the last 2 days. By lots of benchmarking I was able to identify the boost multiprecision library together with -std=c++11 (or -std=gnu++11) as the culprit for the performance regression because I have also a version of the primesum program which does not use the boost multiprecision library and in this version there is no performance regression when compiling using -std=c++11. I have tested using multiple versions of the boost multiprecision library including the latest 1.65.1. The slowdown happens on both GCC (versions: 5.4, 6.4, 7.2) and Clang (version 3.8) on x86_64 Linux. I am only using the int256_t and uint256_t types (hence cpp_int backend) and I am doing only simple integer arithmetic: +, - and *. Is this a known issue and is there a known workaround e.g. special compiler flag? I could revert to C++98 but I really don't want to do that... Thanks, Kim Walisch

2 2

[contract] _NOEXCEPT errors in <ostream> for Clang 5.0 C++1z on Teeks Linux
by Lorenzo Caminiti 20 Nov '17

20 Nov '17

Hello all, Most of Boost.Contract regression test fail for toolset clang-gnu-linux-5.0~c++1z~lc on platform teeks99-02-dc5-1z-lc-Docker-64on64 because of the following error on #include <ostream> done by Boost.Range (and sometimes by Boost.IOStreams): "clang++-5.0" -c -x c++ -Wno-c99-extensions -std=c++1z -stdlib=libc++ -isystem/usr/include/libcxxabi -O0 -g -fno-inline -Wall -g -fPIC -m64 -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTRACT_DISABLE_THREADS -DBOOST_CONTRACT_DYN_LINK -DBOOST_SYSTEM_DYN_LINK=1 -I".." -I"../libs/contract/test/function" -o "/var/boost/run/results/boost/bin.v2/libs/contract/test/function-smoke.test/clang-gnu-linux-5.0~c++1z~lc/debug/threadapi-pthread/function/smoke.o" "../libs/contract/test/function/smoke.cpp" In file included from ../libs/contract/test/function/smoke.cpp:9: In file included from ../libs/contract/test/function/../detail/oteststream.hpp:10: In file included from ../boost/iostreams/tee.hpp:18: In file included from ../boost/iostreams/detail/adapter/device_adapter.hpp:22: In file included from ../boost/iostreams/detail/call_traits.hpp:15: In file included from ../boost/iostreams/traits.hpp:38: In file included from ../boost/range/iterator_range.hpp:14: In file included from ../boost/range/iterator_range_io.hpp:32: In file included from /usr/include/c++/v1/ostream:138: In file included from /usr/include/c++/v1/ios:216: In file included from /usr/include/c++/v1/__locale:15: /usr/include/c++/v1/string:1942:14: error: expected ';' at end of declaration _NOEXCEPT ^ /usr/include/c++/v1/string:1947:9: error: expected unqualified-id _NOEXCEPT ^ /usr/include/c++/v1/__config:368:21: note: expanded from macro '_NOEXCEPT' # define _NOEXCEPT noexcept ^ 2 errors generated. Of course, Boost.Range and Boost.IOStreams show the same error on this toolset/platform independently of Boost.Contract. Any idea what the issue might be? Thanks, --Lorenzo

5 9

[operators] A modern SFINAE-based version of boost::operators?
by Beman Dawes 19 Nov '17

19 Nov '17

Peter Sommerlad, committee member and C++Now presenter who often proposes additions to fill in holes in the standard library, asked me: Are you aware of anybody who tried to provide a boost::operators style of automatically providing additional operators with a single base class that through SFINAE injects all possible operators based on the ones defined in the template parameter? This won't give you the control of the current boost::operators, but would be much easier to teach. For example struct Me : make_operators_for<Me>{ Me& operator+=(Me const&); // You get + bool operator<(Me const&) const; // You get all relops (<=> will make that obsolete) Me& operator++(); // you get postfix //etc. }; Today we have the facilities and compilers to make that happen. What do you think? Who should I ask? Anyone doing any work on operators or have any thoughts about updating boost::operators? --Beman

14 31

[python] Incorrect link
by Christian Henning 19 Nov '17

19 Nov '17

Hi all, on page http://boostorg.github.io/python/doc/html/tutorial/tutorial/embedding.html the link to http://www.python.org/doc/api/exceptionHandling.html is dead. Perhaps, it should be this link: https://docs.python.org/3/tutorial/errors.html Regards, Christian

1 0

[release] Boost 1.66.0 Beta 1 Release Candidate 2
by Daniel James 19 Nov '17

19 Nov '17

The release candidates for the 1.66.0 beta release are now available at: <https://dl.bintray.com/boostorg/beta/1.66.0.beta.1/source/> You need to scroll past the first release candidates to find the downloads. The SHA256 checksums are as follows: e7b23e638e8c3a9da1512439385b04850829cea7bd56d8398677c096857d830b boost_1_66_0_b1_rc2.7z 5d0405eb73bd609ebcd54bbc96d4f1e2d97c51b96c4703706695ddd94f942d6b boost_1_66_0_b1_rc2.tar.bz2 f0f455e39bc47b2b670a17cb221687506e9a22dc478956d3d8aabb9cb835a7dc boost_1_66_0_b1_rc2.tar.gz 694c8b9e902b7981670bce166f675f3875c19326936db51aabd98d2ddfea9b45 boost_1_66_0_b1_rc2.zip The in progress release notes are at: <http://www.boost.org/users/history/in_progress.html> And the documentation is at: <http://www.boost.org/doc/libs/1_66_0_beta1/> As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy.

3 2

Re: [boost] Adding polymorphic_value to boost
by Tom 19 Nov '17

19 Nov '17

> Message: 10 > Date: Thu, 16 Nov 2017 02:14:30 -0700 > From: Jonathan Coe <jonathanbcoe(a)gmail.com> > To: boost(a)lists.boost.org > Cc: Matt Calabrese <calabrese(a)google.com> > Subject: [boost] Adding polymorphic_value to boost > Message-ID: > <CAAbBDD9Ck+LhQ4iUraBtBkxexVKDt167qxyfTpDQqYM9bcMqLQ(a)mail.gmail.com> > Content-Type: text/plain; charset="UTF-8" > > I'd like to propose adding the class-template `polymorphic_value` to boost. > > `polymorphic_value` is designed to allow the compiler to correctly generate > special member functions for classes with polymorphic components (It's > `any` with an interface). > > `polymorphic_value` has been proposed for standardisation in P0201 and has > advanced through the Library Evolution group in Albuquerque (Nov 5-10). > https://wg21.link/p0201 > > A working draft of the proposal and implementation can be found at > https://github.com/jbcoe/polymorphic_value > > I gave a presentation about polymorphic_value at C++::London here: > https://skillsmatter.com/skillscasts/9539-a-polymorphic-value-type-for-c-pl… > > Matt Calabrese has kindly offered to be review manager. > > Kind regards, > > Jon Hi, I'd be interested in such a utility. Mathias Gaunard proposed something similar on the mailing list a long while ago, I implemented a simple version myself based on that. I have a small number of questions. Given that this is a value type, does the current approach over-expose pointer (ownership) in the interface (in essence it still appears to be a glorified smart pointer) and understate its more fundamental purpose as a regular value with dynamic type? There might be other things which can usefully be added for such a value type, for example permitting direct construction of an object of specific (derived) type, by passing the type as well as the arguments for the constructor of that type (or wrapping the arguments in some kind of in-place factory with explicit type). Something like: // Simple wrapper to enable a static type to be passed through a forwarding constructor. template <typename T> struct Type {}; // Forwarding constructor - actual type is deduced from type wrapped in (unnamed) first argument's type template <typename D, typename... Args> explicit poly_obj(Type<D>, Args&&... args); // Also could have an emplace member function template <typename D, typename... Args> void emplace(Type<D>, Args&&... args); In theory you wouldn't need to expose pointers in the interface at all? In fact, should a type-erasure library be preferred (e.g., Boost.TypeErasure or Adobe.Poly) as it provides a more general solution for manipulating polymorphic value types (though typically harder to use)? Would you be considering supporting C++98 via using the boost::move library? Regards, Tom

1 0

[gil][test] HOWTO set up the Boost testing process for projects with extra prerequisites ?
by Stefan Seefeld 17 Nov '17

17 Nov '17

Hi, I just merged some work to GIL's `develop` branch. This notably involves improvements to the testing infrastructure. Testing GIL is a bit involved, as it requires various backend libraries (PNG, JPEG, TIFF, etc.) to be installed. While the stand-alone testing works fine (https://github.com/boostorg/gil/blob/develop/.travis.yml#L304-L306) the integrated testing will thus fail, until the testing logic is augmented by the necessary instructions to a) install the prerequisites and b) invoke the build system with the appropriate flags (https://github.com/boostorg/gil/blob/develop/io/test/Jamfile#L13-L22) Thus my question: do we have any documentation that explains how to do this ? What do I (as GIL maintainer) or any testers need to do for the integrated testing to work ? (I can't resist: all these libraries that have special requirements really shouldn't be built and tested in such a monolithic process. It's a burden to all tester, maintainers, and packagers. It would be far better to handle them more independently.) Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 8

[density] paged memory and concurrency
by Giuseppe Campana 17 Nov '17

17 Nov '17

Hi, in the last year I’ve been experimenting concurrent data structures on density, a C++11 library focused on: - Page-based memory management. - Heterogeneous and function queues. Single-threaded, mutex-ed, lock-free and spin-locking versions are available. Lock-free and spin-locking queues support any combination of single/multiple producers/consumers. - Lifo memory management, mainly to provide a safe alternative to alloca with almost the same performances. - Parametric control of the progress guarantee in concurrent algorithms. I have to do a major update to fix the known issues, so I’d like to receive any feedback before it, especially about the design. The document http://giucamp.github.io/density/doc/html/implementation.pdf explains the implementation of almost everything, though it’s quite long. Documentation: http://giucamp.github.io/density/doc/html/index.html Repository: https://github.com/giucamp/density Is there any interest on it? Giuseppe Campana.

1 0

Re: [boost] [Boost-users] Could guys help me on a boost MPI link error
by degski 16 Nov '17

16 Nov '17

On 16 November 2017 at 07:33, Renfan Luo <Renfan.Luo(a)perpetuum.com> wrote: > Thanks a lot! After changing X64 to X86 on the top of drop-down window > of IDE, the problem has been fixed. > You're welcome, degski

1 0

bjam boost build on windows - changing the path strategy (stage)
by James E. King, III 16 Nov '17

16 Nov '17

I would like to build boost into a prefix directory (.\b2.exe --prefix=C:\prefix) containing "C:\prefix\include\boost\..." and "C:\prefix\lib", just like the linux build does. On Windows it builds into ""C:\prefix\include\boost-1_66\boost\..." instead - is there a bjam control to get rid of the version in the prefix include path for header copies? - Jim

5 5

[release] 1.66.0 fully closed for beta
by Daniel James 15 Nov '17

15 Nov '17

I've stopped updating the master branch of the super project, and will try to get the beta release out tomorrow, so there's only a little delay. You can still add your release notes at: <https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.q…> Thanks, -- The Boost Release Team

1 1

Re: [boost] seeking endorsement for histogram library
by Hans Dembinski 15 Nov '17

15 Nov '17

Dear Fabian, I am CCing boost, because maybe some others want to read this as well and/or correct me. > On 15. Nov 2017, at 14:21, Fabian Bösch <boeschf(a)student.ethz.ch> wrote: > > Thanks for clarifying. While it is true that Boost.Accumulators does > this, it is for the uni-variate case only, afaik. Please correct me, if > I'm wrong. I believe you can compute a multi-dimensional mean, if you feed an appropriate Boost.Accumulator with std::valarrays. Maybe there is an easier way. > Now you have multi-variate histograms for which one would probably also > like to know the Covariance (rank-2 tensor), for example. Maybe this is > out of scope but a general solution for this would be nice. But perhaps > this would rather be addressed in another generalized accumulator > library. What do you think? I think you are right. You can compute the covariance of two variables with Boost.Accumulators: http://www.boost.org/doc/libs/1_65_0/doc/html/accumulators/user_s_guide.htm… but it does not give you a full matrix for N covariates. Maybe you could contact the maintainer of Accumulators, Eric Niebler. It is a reasonable request that would fit better into Accumulators than in Histogram. Best regards, Hans

1 0

Re: [boost] seeking endorsement for histogram library
by Hans Dembinski 15 Nov '17

15 Nov '17

Dear Francesco, > On 13. Nov 2017, at 19:09, Francesco Guerrieri <f.guerrieri(a)gmail.com> wrote: > > Hi this proposal is of great interest to me, thanks for sharing your work with us. Which compilers/OSs are supported? I tested the code on OSX with Apple clang, and via TravisCI on several versions of gcc on Linux. The CMake build works on both OSX and Linux. I wanted to also test Windows via Appveyor, but couldn't get my CMake build script to work with msvc. I am passing compiler flags directly, which works for clang and gcc, but naturally not for msvc. Debugging this non-interactively, by committing a change to github, letting Appveyor run, seeing it breaking again..., was a pain and I stopped at some point. If an expert for Windows had a look at my CMakeLists.txt, it is probably something that could be easily fixed. Best regards, Hans

2 2

seeking endorsement for histogram library
by Hans Dembinski 14 Nov '17

14 Nov '17

Dear Boost developers, I believe the histogram library is now ready to be presented here and I am looking for endorsement. Histogram is a C++11 header-only library that provides a safe, convenient, and fast multi-dimensional histogram for statistical analysis and visualisation. The library has a unique feature set, among it a safety guarantee that the counts in the histogram cannot overflow. It is easily customisable for power users, while providing defaults that just work for the occasional user. Meta-programming is used to provide an especially fast histogram implementation that can be used when the histogram configuration is known at compile-time. A dynamic implementation is also provided for the other case when the configuration is only known at run-time. The two implementations share a common interface, so it is easy to switch between them. Python bindings are included for the dynamic implementation. The Python interface supports Numpy arrays to greatly speed up the exchange of data between the Python and C++ side. I tested the performance of the library in benchmarks against other libraries, which have fewer features, and this library beats them in almost all cases. I am stealing the style of the rest of the email from Antony Polukhin. Library: https://github.com/HDembinski/histogram <https://github.com/HDembinski/histogram> Docs: https://htmlpreview.github.io/?https://raw.githubusercontent.com/HDembinski… <https://htmlpreview.github.io/?https://raw.githubusercontent.com/HDembinski…> Boost Library Incubator: http://blincubator.com/bi_library/histogram-2/?gform_post_id=1582 <http://blincubator.com/bi_library/histogram-2/?gform_post_id=1582> Library changes since last mail: * Support for efficient adding of multiple histograms and scaling * Support for reduce transformation * Re-design of category axis as a general mapping between unique values and bins * Re-design of the bin description an axis returns upon element access * Regular axis can accepted bijective (user-provided) transformations * Interface cleanup, refactoring, and simplification * Finished documentation Best regards, Hans

3 4

[test] [build] best practices for looking up data files from test executables
by Stefan Seefeld 14 Nov '17

14 Nov '17

Hi there, I'm trying to write a test that needs to access a data file. As I'm surely not the first wanting to use external data in my tests, I wonder whether there are established "best practices" or idioms when using Boost.Build and Boost.Test. My first attempt was to compute the relative path using the test source's `__FILE__`, until I realized the path was invalid due to the build logic moving executables before running them. Then I considered using a command-line option to point at the data directory, but that seems quite involved when using boost::test (and BOOST_TEST_MODULE)... Any suggestions for how to approach this ? Thanks, Stefan -- ...ich hab' noch einen Koffer in Berlin...

7 10

Exceptions vs Assertion for library API?
by Jonathan Biggar 13 Nov '17

13 Nov '17

Any advice in choosing between throwing an exception vs asserting for invalid uses of a library API? I'm building a small "transactional" library I'd like to contribute to boost where certain API calls are constrained to only be valid if the transaction is still "in-progress". Such calls will never succeed, and are easy for the implementation to diagnose. I'd like to have the library fail an assertion, which is far clearer to the user that the code logic is incorrect, but it bothers me that assertions are much more difficult to write unit tests for. (Is there even a concept of a test that passes if if fails to compile or fails with an assertion in the boost testing framework?) I suppose I could mangle the interface to ensure that the user has nothing to invoke the API calls in question unless the transaction is in-progress, but that generally requires a custom "lock" interface for my RAII implementation that makes the API more complex to grasp. -- Jon Biggar jon(a)biggar.org

5 4

[release] 1.66.0 closing for beta tomorrow
by Daniel James 13 Nov '17

13 Nov '17

Hi, I'll close the master branch for the beta release tomorrow. Sorry we've been quiet about the release and that this is a bit short notice. If you haven't written your release notes yet, you can add them to: https://github.com/boostorg/website/blob/master/feed/history/boost_1_66_0.q… Use the pencil icon at the top right of the code to edit it, or you can mail your notes to me, and I'll add them. thanks, Daniel

10 28

[release][1.66.0] Permission to merge Hana
by Louis Dionne 12 Nov '17

12 Nov '17

Hi, Being at a C++ meeting all week, I did not see the release coming and the email in time. None of the changes to Hana have been merged to master, and I'd like to get them in for the release. Can I merge them, or should I wait until after the beta? Thanks and apologies for the untimeliness, Louis -- Sent from: http://boost.2283326.n4.nabble.com/Boost-Dev-f2600599.html

2 2

[release][1.66.0] Permission to merge Predef.
by Rene Rivera 10 Nov '17

10 Nov '17

Some late fixes for Predef came in over the past two days: < https://github.com/boostorg/predef/commit/4a230ebe853980e27e7fb7cb36605fd6c… > < https://github.com/boostorg/predef/commit/74f88005cc2227b4f8fd4d640daae18c2… > < https://github.com/boostorg/predef/commit/5e8f5d5a4b9df640ffaeaf51e89c83e28… > Can I merge those to master for the beta? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

2 1

Seeking endorsement for the reflection library (PFR)
by Antony Polukhin 10 Nov '17

10 Nov '17

Hello, PFR is a C++14 library that provides tuple-like methods for aggregate initializables. Library has a set of predefined operators and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Seeking for some endorsement, as per http://www.boost.org/development/submissions.html Library changes since last mail: * Now works on latest MSVC in C++17 mode * C++14 limitations in reflection were significantly relaxed * Removed UB (no more reinterpret casting of unrelated types!) * Thaler Benedek was approved as a review manager for the library. Boost libraries that may benefit from PFR: * Convert - for out-of-the-box conversions of user types * Hana - for using user types instead of tuples * Intrusive - for reusing unused bits in user provided types * Serialization - for out-of-the-box serialization of user types * Spirit - for putting rule results into user provided types without Phoenix or Fusion macro * Test - for outputting content of user provided types * TypeTraits - for traits like has_unique_object_representations in C++14 -- Best regards, Antony Polukhin

5 11

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

[devector] optimum growing/insertion policy
by Joaquin M López Muñoz 08 Nov '17

08 Nov '17

Hi, Much an worthy discussion has taken place with respect to growing and insertion policies of boost::double_ended::devector. I think I can justify what the optimum policy is when the overall goal is to minimize number of element movements. What follows is *not* a formal optimality proof, though it's my hunch one could be provided relatively easily. Assumptions * The cost of allocating new memory is negligible when compared to the cost of moving elements around (either intra-buffer or when migrating to a new buffer); so, the growing/insertion policy should focus on minimizing number of elements moved. This implies fully occupying free space before reallocation is *not* the primary goal of the growing/insertion policy. * For the purposes of our discussion, we consider an ever-growing devector without intervening erasures --erasures can be accomodated later as we will see. * Element insertion is modelled as a process where each new insertion happens at a random position within the current devector. The minimal characterization (i.e. its 1st moment in stochastic process theory terminology) is just the percentage R of insertions that happen within the right half of the devector --we call these *right insertions*; left insertions happen then with a frequency L=1-R. push_back is a right insertion, push_front a left insertion. Facts * When a right insertion arrives, if there's free back capacity the optimum insertion policy is to shift elements to the right, as this involves fewer movements than the other way around. The symmetrical applies for left insertions. * If a right insertion at position N arrives and there's no free back capacity (but there is free front capacity), we have only two options: A. Reallocate to get back free capacity. B. Shift elements to the left. The key observation here is that A is cheaper in the long run: as the scenario is one of an ever-growing sequence, reallocation will happen eventually and we can just amortize it in our analysis, so reallocating early saves us the extra movements incurred when left shifting on a right insertion, namely N - (size()-N) = 2*N - size() movements. In fact, we save more than that as insertion is done simultaneously with reallocation, hence no shifting occurs additionally to the (amortized) reallocation cost. All this analysis applies symmetrically to left insertions, of course. * The optimum growing policy is that which maximizes the probability that *both* front and back free capacities get exhausted at the same time. With our 1st moment characterization of the insertion random process, this implies that when reallocating a percentage R of the new space should be devoted to the right side, and a percentage L to the left side. Description of resulting policy * Fix the growing factor to G (this can be 1.5 or 2 or anything greater than one, the actual figure is orthogonal to the discussion). * Maintain a counter right_ of right insertions that gets incremented when a right insertion occurs and *decremented* when an erasure is issued past the middle of the devector. * Right insertions trigger right shifting except when there's no back free capacity, in which case a reallocation is performed. * Left insertions trigger left shifting except when there's no front free capacity, in which case a reallocation is performed. * Reallocation reserves space for G*size() elements: of the resulting G*size()-size() free space, a fraction right_/size() is devoted to back free capacity, the rest to front free capacity. In practice, we may want to keep some minimum space at each end as determined by some empirical threshold. And that's it. Comments welcome. Joaquín M López Muñoz

6 37

Including a system link library for every test, but only on mingw-w64 builds?
by James E. King, III 08 Nov '17

08 Nov '17

Is BOOST_AUTO_LINK supposed to work on mingw-w64 builds with gcc? I'm guessing not since I believe this is a MSVC concept, so I am looking for a bjam recipe that will allow me to add the link library bcrypt.lib to all of the tests in a project's test directory if the build is on a windows system and not using msvc toolset. Are these any examples out there? Thanks, Jim

6 9

[type_traits] is_nothrow_move_constructible gives false positive on GCC 4.7
by Andrzej Krzemienski 08 Nov '17

08 Nov '17

Hi, It seems that boost::is_nothrow_move_constructible sometimes gives false positives on GCC 4.7. See the Git issue for details: https://github.com/boostorg/type_traits/issues/56 Regards, &rzej;

1 0

Boost.Uuid and header-only support
by James E. King, III 08 Nov '17

08 Nov '17

Hi folks, I have an open defect related to a random seed generator that's currently in boost::uuids::detail called seed_rng. The class does a fair bit more than it really needs to, and does not support Universal Windows Platform (UWP) store targets. It is otherwise quite similar to boost::random::random_device however it is a header-only implementation (in fact seed_rng has a comment about putting it into Boost.Random). I was planning on removing it and leaving randomness to Boost.Random because that's where the code really belongs, however this would introduce a new library dependency on Boost.Random for any code using boost::uuids::random_generator. So I'm curious on how important folks believe it is to maintain the header-only status of Boost.Uuid. Thanks, Jim

8 48

Preferred way to simulate system calls
by James E. King, III 06 Nov '17

06 Nov '17

I like to test every branch, and I have a class that calls open/read/close. It uses a hardcoded filename ("/dev/urandom"). It is a template in a detail namespace. What's the "boost way" when it comes to mocking these system calls? Should I make protected methods that normally call open/read/close, then subclass in a test and override them with different logic to force error paths? - Jim

3 2

[config] Rethinking feature macros?
by Peter Dimov 06 Nov '17

06 Nov '17

Now that there are standard feature-testing macros (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0096r5.html) that are being implemented by at least g++ and clang++, would it perhaps make sense for us to reevaluate our decision to provide negative macros in Boost.Config and start defining the standard feature macros instead on the compilers that don't support them? This would seem to require less maintenance, and the feature macro can be used without waiting for Boost.Config to add it. For a concrete example, let's take noexcept in function types. This is __cpp_noexcept_function_type, and is implemented by g++ 7, clang 4, clang 5 (in C++17 mode), and apparently in the latest VS2017 preview. noexcept function pointers break Boost.Bind, and to fix it, I need to add overloads for them, but only if they are implemented, otherwise the overloads would be an error. With the feature macro, I can just #ifdef __cpp_noexcept_function_type and it will immediately work on g++ and clang++ and all compilers that don't support noexcept function types will still work. Only msvc would need to be fixed in some way. With our traditional approach, I would need to request the addition of BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE, wait for it to be added and to be present on every compiler except the latest ones (which requires changes throughout Boost.Config), and only then be able to use #ifndef BOOST_NO_CXX17_NOEXCEPT_FUNCTION_TYPE. (Then wait for it to be merged to master before merging my changes to master.)

8 36

[optional] Regression in develop
by Andrzej Krzemienski 06 Nov '17

06 Nov '17

Hi Everyone, Over the weekend I added changes to Boost.Optional in develop which caused regression in Boost.Beast and maybe more libraries. I would like to ask for your input as to how to best approach this. The change was: for trivial `T` use a different specialization of `optional<T>` which is trivially-copyable. For this, I need the ability to declare defaulted functions, and to detect that a given type is trivial. Boost.TypeTraits do not have `is_trivial` trait, so I compose it form `has_trivial_move` and the like. But it seems there are compilers for which Boost.config and Boost.TypeTraits report support for deleted functions/triviality detection, but where this support is buggy. The following is a test case in type_traits by Vinnie Falco: https://github.com/boostorg/type_traits/pull/52/commits/9779157a787620d1633… In addition, the deadline for changes in release 1.66 is getting nigh. I can see a couple of ways to fix this: 1. Fix Boost.Config and/or Boost.TypeTraits so that they only report support for the features in question when it is supported without bugs. But I do not know if there is enough time for this given the deadline. 2. Disable my feature on the compilers with buggy support. But I would need a help from someone who knows all the compilers and their bugs in implementation of trivial type traits so that I can put the wight `#ifdef`s. 3. Just revert my changes to Optional, which is also an option, but would also be a loss. Any input from Boost experts would be appreciated. Regards, &rzej;

5 13

[msm] Unmerged changes in develop need review
by Peter Dimov 05 Nov '17

05 Nov '17

Boost.MSM has a number of long-unmerged changes in develop. If anyone who is familiar with MSM and cares about its state would like to review these changes and issue a recommendation on whether they, or which of them, need to be merged to master, now would be a good opportunity to do so.

1 0

[beast] Video Presentation: Designing an HTTP message container
by Vinnie Falco 05 Nov '17

05 Nov '17

Greetings! This is the video for my CppCon 2017 presentation. In this presentation I discuss designing a class for storing HTTP messages, defining some concepts along the way. The concepts are based on the ideas in Beast, but simplified for the presentation format. Anyone who is interested in learning some techniques, or getting a more advanced understanding of the Beast message container, may benefit from this video. Also, the video is entertaining on its own. Here it is: <https://www.youtube.com/watch?v=WsUnnYEKPnI> This page also contains the embedded video along with additional exposition not found in the talk: <http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/design_choic…> Thanks!

1 0

PGI
by Oliver Kowalke 05 Nov '17

05 Nov '17

Hi, does someone work on the boost-config for PGI? Running the unit-tests of boost.config fails but PGI 17.x should be C++11 compatible. Oliver

2 1

Mobile site
by Daniel James 04 Nov '17

04 Nov '17

Hi, I've been doing a little work on getting the website to work better on mobile phones. You can see it on the beta site: https://beta.boost.org There's still a lot to do, especially on the sidebar which is not really usable at the moment, so don't expect it to go live any time soon. Daniel

2 3

[parameter] RFE: perfect forwarding
by Cromwell Enage 02 Nov '17

02 Nov '17

Hi, everyone! I'm back from a long hiatus. Is anyone still interested in enhancing Boost.Parameter to handle perfect forwarding? If so, I have a patched version available at <http:/ github.com/CromwellEnage/boost-parameter-perfect_forwarding>. It includes existing header files and test source files that were modified, a few new header files and test programs, and corresponding changes to the .rst documentation files. Questions, concerns, and comments are welcome! Cromwell D. Enage

2 1

[poly_collection] Needs a 'develop' branch
by Edward Diener 02 Nov '17

02 Nov '17

The new library Boost poly_collection only has a 'master' branch. It needs to have a 'develop' branch also.

3 5

Building Quickbook docs from source code in HTML format
by Kolya Kosenko 31 Oct '17

31 Oct '17

Hello, I'm trying to build QuickBook HTML Boost library documentation from source code. I got *.docbook file, but there is no HTML files at all. For example I built stacktrace library docs: ./b2 -a libs/stacktrace/doc/ And I didn't get any HTML, only stacktrace.docbook: $ find . ./doc ./doc/gcc-5.4.0 ./doc/gcc-5.4.0/debug ./doc/gcc-5.4.0/debug/stacktrace.xml ./doc/gcc-5.4.0/debug/stacktrace.docbook ./doc/none ./doc/none/gcc-5.4.0 ./doc/none/gcc-5.4.0/debug ./doc/none/gcc-5.4.0/debug/autodoc-xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/classboost_1_1stacktrace_1_1basic__stacktrace.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/dir_3516969ce87a02a0560c741857e33749.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/dir_c8984f1860c11f62f47abb6761e46c1e.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/combine.xslt ./doc/none/gcc-5.4.0/debug/autodoc-xml/stacktrace_2stacktrace_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/classboost_1_1stacktrace_1_1frame.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/compound.xsd ./doc/none/gcc-5.4.0/debug/autodoc-xml/index.xsd ./doc/none/gcc-5.4.0/debug/autodoc-xml/stacktrace__fwd_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/index.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/stacktrace_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/namespaceboost_1_1stacktrace.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/namespaceboost_1_1stacktrace_1_1detail.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/namespaceboost.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/dir_72bdf9838375a891eaf35cbacea5f7be.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/frame__decl_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/frame_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml/safe__dump__to_8hpp.xml ./doc/none/gcc-5.4.0/debug/autodoc-xml.doxyfile ./doc/none/gcc-5.4.0/debug/autodoc-xml.xml-dir ./doc/none/gcc-5.4.0/debug/autodoc-xml.boostbook ./doc/none/gcc-5.4.0/debug/autodoc-xml.doxygen But I need something like this: http://www.boost.org/doc/libs/1_65_1/doc/html/stacktrace.html I have used quickbook install instructions for Ubuntu: http://www.boost.org/doc/libs/1_65_1/doc/html/quickbook/install.html#quickb… It looks like docbook to html conversion is required using some xsl file but I don't know how to do it and what files are used. There is some XSL files in boost/tools/boostbook/xsl folder but I don't know how to use it with b2 build. PS. I have installed xsltproc, docbook-xsl, docbook-xml packages. $ cat ~/user-config.jam using boostbook ; using xsltproc ; using boostbook : /usr/share/xml/docbook/stylesheet/nwalsh : /usr/share/xml/docbook/schema/dtd/4.2 ; using doxygen ; ----- Regards, Kolya.

2 4

[GitHelp] Getting boost stable release from GitHub after git clone
by Kostiantyn Ponomarenko 31 Oct '17

31 Oct '17

Hi, guys. I would appreciate little help in understanding what is the right way of switching to the latest stable boost release after git repository is cloned. My intention is to clone boost, because then, with new releases, I can easily update it with git and switch (checkout) to the next "current" release. PS: I like that boost uses git =). --- Kostia Kyiv, Ukraine

2 2

[contract] differentiate regressions with libc++
by Lorenzo Caminiti 31 Oct '17

31 Oct '17

Hello all, Another question on the regression tests. How am I supposed to differentiate GCC 6.0 between CrystaX-apilevel-19-armeabi-v7a-gnu-libstdc++ and CrystaX-apilevel-19-armeabi-v7a-hard-llvm-libc++? http://www.boost.org/development/tests/develop/developer/contract.html They both use the same toolset name "gcc-gnu-6", but when libc++ is used instead of libstdc++ Boost.Contract tests give these linker errors: ../boost/smart_ptr/detail/sp_counted_impl.hpp:146: error: undefined reference to 'operator delete(void*, unsigned int)' /home/cislave/.crystax/ci-boost/regression/android-19-armeabi-v7a-hard-llvm-develop/tmp/crystax-ndk-10.3.2/sources/cxx-stl/llvm-libc++/3.6/libcxx/include/sstream:189: error: undefined reference to 'operator delete(void*, unsigned int)' ../boost/iostreams/detail/streambuf/indirect_streambuf.hpp:50: error: undefined reference to 'operator delete(void*, unsigned int)' /home/cislave/.crystax/ci-boost/regression/android-19-armeabi-v7a-hard-llvm-develop/tmp/crystax-ndk-10.3.2/sources/cxx-stl/llvm-libc++/3.6/libcxx/include/sstream:740: error: undefined reference to 'operator delete(void*, unsigned int)' collect2: error: ld returned 1 exit status I wanted to mark the link errors for libc++ as expected failures while leaving libstdc++ unmarked (because there are no link errors for libstdc++). However, I don't know how to do that because the toolset name is the same "gcc-gnu-6" for both runs with libstdc++ (column 6) and with libc++ (column 10). Should the toolset names be unique instead? For example, should names like gcc-gnu-6~libstdc++ and gcc-gnu-6~libc++ have been used in this case instead of using just gcc-gnu-6 for both runs? Thank you. --Lorenzo

1 1

fuzzing boost at OSS-Fuzz
by Kostya Serebryany 31 Oct '17

31 Oct '17

Hi, I would like to invite boost developers to use OSS-Fuzz, a continuous automated fuzzing service. https://github.com/google/oss-fuzz https://opensource.googleblog.com/2017/05/oss-fuzz-five-months-later-and.ht… I've made the initial set up that fuzzes boost::regex and it found 8 bugs there, see https://svn.boost.org/trac10/ticket/12818#comment:7 3460 boost: Integer-overflow in boost::re_detail_NUMBER::basic_regex_parser... 3464 boost: Integer-overflow in boost::re_detail_NUMBER::perl_matcher... 3469 boost: ASSERT: jmp->type == syntax_element_jump 3471 boost: Stack-overflow in boost::re_detail_NUMBER::basic_regex_parser... 3472 boost: Stack-overflow in boost::re_detail_NUMBER::perl_matcher… 3478 boost: Stack-buffer-overflow in boost::re_detail_NUMBER::perl_matcher... 3479 boost: Null-dereference READ in boost::re_detail_NUMBER::basic_regex... Vinnie Falco pointed me to Jens Weller's blog post about fuzzing beast: https://www.meetingcpp.com/blog/items/fuzzing-beast.html . Jens used libFuzzer, which is one of the two fuzzing engines used by OSS-Fuzz. Adding a boost library to OSS-Fuzz will look very similar to this blog post. For those of you who are at CppCon this week: we can discuss this face to face. --kcc

1 1

property_map/compose_property_map get() return type
by Brook Milligan 31 Oct '17

31 Oct '17

I am trying to understand the logic behind the get() function for the Boost compose_property_map, which is defined in boost/property_map/compose_property_map.hpp. The document states the following: This property map is an adaptor that composes two property map. The new property map will of the same model as FPMap. I interpret these two sentences to mean that the category, value_type, and reference types of the composition will be the same as those for FPMap, while the key_type will be the same as for GPMap. Thus, I expect that get(composition,gkey) should return the same type that get(fpmap,fkey) would. However, the implement does not follow this expectation, which leaves me puzzled. The following is the relevant portion of the code: template <typename FPMap, typename GPMap> class compose_property_map { public: typedef typename boost::property_traits<FPMap>::reference reference; // return type of get(): // if (reference is not a ref) // value_type // else if (reference is const) // reference // else // const value_type& inline friend typename boost::mpl::if_< boost::mpl::not_< boost::is_reference<reference> >, value_type, typename boost::mpl::if_< boost::is_const<reference>, reference, const value_type& >::type >::type get(const compose_property_map &m, const key_type &k) { return get(m.f, get(m.g, k)); } Notice the comment and the selection of the return type. The result is always a value_type or _const_ reference, irrespective of the reference type of FPMap. Consequently, the information advertised as the reference type, which is the same as that of FPMap, is incorrect, and get() does not return a simple composition of the two property maps as described in the documentation. What is the rationale for this behavior? It seems that there must be a reason to go to the great lengths to second guess what FPMap is doing, rather than simply doing what the documentation says should occur, but I fail to see it. I look forward to any clarification. Thanks a lot. Cheers, Brook

1 0

[review] The review of Boost.DoubleEnded starts today: September 21 - September 30
by Thorsten Ottosen 31 Oct '17

31 Oct '17

Dear users and members of Boost, I'm proud to announce that the formal review of Benedek Thaler's Boost.DoubleEnded library starts today, September 21, and runs through September 30. This library is the result of Benedek's participation in Google Summer of Code 2015. The library may be downloaded from https://github.com/erenon/double_ended and the documentation may be found here: http://erenon.hu/double_ended/ Anyone is welcome to post a review and/or take part in subsequent discussions (see below for review guidelines). Introduction ------------ This is a container library that provides two containers: A. boost::devector B. boost::batch_deque Both containers provides efficient push_front and push_back operations, hence the name DoubleEnded. The boost::devector class can be seen as an extension of std::vector with efficient support for push_front (so boost::devector provides contiguous storage). In addition, it provides a customizable small buffer optimization like boost::small_vector(*). It furthermore allows for customization of the growth factor such that the user can decide if a reallocation should allocate 1.5 or 2 or whatever more memory. And finally it provides new functionality that does not exist in normal vector implementations -- this functionality allow the class to excel in performance in certain situations like serialization or transfer of data from sources that require a preallocated buffer. The boost::batch_deque is similar to std::deque, but with two important twists. Like std::deque, it provides reference stability when calling push_front/push_back. Reference stability is crucial for programs that uses intrusive containers e.g. using Boost.Intrusive (**). boost::batch_deque has the following main advantages: 1. It allows the user to specify the segment size 2. It allows for external iteration over the segments Taken together, they provide a very efficient and flexible basis for intrusive containers. Access to the segments also increases performance for tasks such as serialization. Finally, boost::batch_deque may be seen as an efficient alternative to std::vector if you want to replace a percent-wise memory overhead with a constant memory overhead and have no need for contiguous storage. Review guidelines ----------------- Please provide in your review whatever information you think is valuable to understand your final choice of ACCEPT or REJECT including Fit as a Boost library. Please be explicit about your decision. Some other questions you might want to consider answering: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With which compiler(s)? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? More information about the Boost Formal Review Process can be found here: http://www.boost.org/community/reviews.html Kind regards Thorsten, Review manager (*) boost::small_vector: https://tinyurl.com/ycslp4ot (**) http://www.boost.org/doc/libs/1_64_0/doc/html/intrusive.html

24 159

[boostbook] Building documentation with generate.consistent.ids
by Daniel James 30 Oct '17

30 Oct '17

Hi, This was originally sent to the boost-docs list, but it doesn't seem to be working, so I'm sending it here. Sorry if you receive it twice. A while ago Gregor Jasny suggested building with the generate.consistent.ids option to reduce the changes between snapshots (as many elements in the documentation had random id numbers). I've tried turning it on for the develop documentation build, and tweaked boostbook a little to take advantage of it as well. With this setting generated ids can change when the documentation is edited, but not on every build. If you have standalone documentation and you want to use this feature, you need to use '<xsl:param>generate.consistent.ids=1' in the boostbook rule in your jamfile. This mainly affects boostbook reference documentation, such as: http://www.boost.org/doc/libs/1_65_1/doc/html/boost/accumulators/as_feature… This page gets a new location in every build. With consistent ids it has the consistent, although admittedly uglier, URL: http://www.boost.org/doc/libs/develop/doc/html/boost/accumulators/as_featu_… The advantage is that this will only change when the accumulators documentation is changed (btw. the text part of that url is probably truncated more than it needs to be, I might try to fix that). Other documentation won't be affected so much, as sections usually have explicit ids (quickbook always generates them). An example where a section doesn't is: http://www.boost.org/doc/libs/1_65_1/doc/html/idp22435328-bb.html I suggest you should probably add an explicit id to something like that (I've done so in that case). Daniel

1 0

[review][DoubleEnded] Review Results
by Thorsten Ottosen 30 Oct '17

30 Oct '17

Dear users and members of Boost, I'm happy to to announce that Benedek Thaler's Boost.DoubleEnded is /conditionally/ accepted into Boost provided that it can be integrated smoothly with Boost.Container. There are several other conditions, some major and some minor which I will outline below. For now, I would like to thank everyone that participated with reviews and comments. We didn't have that many reviews, but the reviewers did spend a lot of time both on review and the following discussions. Special thanks also goes to Benedek for his hard work. It is not too often that a GSOC code ends with something of this quality. Two of the world's expert C++ container developers used phrases like "solid" and "everything looks clean and beautiful" about the implementation, "tests look very good, corner cases and all", "The reference section is very good". Congratulations, Benedek. ============== A path forward ============== Ion has most kindly accepted the idea of merging the library into Boost.Container. This consists of A. taking selected elements from batch_deque and adding them to boost::container::deque. B. putting devector into boost.container after changes have been applied to code and documentation C. back-porting the devector code to C++03 (C) does not need to happen immediately, that is, we can have a release where devector is available in a C++11 version. Ion has also most kindly agreed to help with this process. I will help write a new introduction that focuses on the main principles of devector. We also have a number of benchmarks which we can gather and use for a small section of on that topic. I'll leave it to you and Ion to work out the details. ========================== Detailed comments devector ========================== Apart from the merging with Boost.Container, the most heard complaint was about the "fat", the non-essential parts if the interface, that could be removed. This includes -- Remove the direct support for small buffer optimization form devector. When the time comes, provide small_devector similar to the way we have vector/small_vector (there is no requirement that small_devector is provided). -- remove all of the following: - all constructors that uses reserve_only_tag, - all constructors that uses unsafe_uninitialized_tag, - void unsafe_uninitialized_resize_front(size_type); - void unsafe_uninitialized_resize_back(size_type); - unsafe_push_front(...); - unsafe_push_back(...); -- add instead - constructors that uses default_init_t like boost.container - resize versions that uses default_init_t - T& unchecked_emplace_back(...) noexcept(...) - T& unchecked_emplace_front(...) noexcept(...) At some point, I hope we can upgrade default_init_t to mean no construction for all trivially copyable types. There was a wish for more symmetry in devector and so functions that break symmetry or can appear ambiguous should be removed. This means we should remove: -- capacity() There is no need for front_capacity() and back_capacity(). We could remove reserve(), but then we can't use devector with a flat_set. Reserve() should not be an alias for reserve_back() though, but controlled by the policy. We could remove resize(), but even deque has it where it means resize_back(). I totally agree it would be ideal to remove all of reserve(),resize(),capacity(),clear(), but I see no easy way we can use devector with flat containers if we remove the first and the last. Unless we start deprecating stuff in boost::deque/boost::vector and provide new consistent alternatives, we will never get a 100% satisfactory solution. At the end of the day, we need to be pragmatic, so if deprecation is not on the table, this seems the best we can do. Since we don't want two allocations implied by calling reserve_back() and reserve_front(), you can add a mechanism for doing that. That is, you can provide -- reserve( new_capacity ); -- reserve_front( new_front_capacity ) -- reserve_back( new_back_capacity ) -- reserve( new_front_capacity, new_back_capacity ) or, since reserve() is such a weird beast, simply provide -- reserve( new_capacity ); // for flat containers -- anticipate_front( new_front_elements ) -- anticipate_back( new_back_elements ) -- anticipate( new_front_elements, new_back_elements ) to get rid of the funky -- container.reserve_front( container.size() + new_front_elements ) dance. There were suggestions for shrink_back/front_to_fit, but since we are trying to remove fat, I suggest that we wait for a use-case. There were also suggestions that clear() should be amended. As the growth (or resizing policy) mandates what clear does, we need a way to escape. The minimal change that allows that is to provide -- clear( front_free_capacity ) which gives full power to the user. You may provide clear_back() as clear(0) and clear_front() as clear(c.size()+c.front_free_capacity()+c.back_free_capacity()). Ideally, clear() would have been removed entirely like capacity()/resize(), but like reserve(), it just seems like impossible when we start using it with flat containers. Other minor comments: - drop strong exception safety guarantees and do it like boost.container - prefer to make iterator a type (should be easy with reuse from boost::container::vector - allocator should not be inherted from - make clear O(1) amortized gurantees depend on growth policy - consider calling growth policy for resizing policy - make sure SFINAE works properly with constructors - make the default growth factor 2 (as we heard from Sean Parent: no factor below 2 is empirically good) - consider renaming front_free_capacity to free_front_capacity. Rationale: "front_capacity" is a concept, noun, and "free" is the adjective. Ditto for back_free_capacity. - remove size_type from growth policy and take it from the allocator - make the allocator template argument the 2nd argument - fix remaning TODO in code - documentation should not sell devector as drop-in replacement for vector, but rather stress it is not - the allocator supports needs to be improved. I guess doing it the Boost.Container way ensures that (ask Daniel James for help) - exception-safety issues pointed out by Ion - postconditions of insert/erase needs to specify behavior to front_free_capacity/back_free_capcity - use of local containers should be avoided - rotate should be avoided - delegate range move operations to those defined in Boost.Container - make sure all functions excepting non-overlapping range uses memcpy (not just memmove). This includes: - range constructor - copy-constructor - copy-assignment - range-assignment - range insert - destructor should used std::has_trivial_destructor to avoid loop in that case to make sure all compilers optimize it away (similar for erase). There is one final puzzle and that is the growth policy. I hope we can finalize that by testing Joaquin's and Ion's suggestions over the coming weeks. ============================= Detailed comments batch_deque ============================= For deque, the comments were similar, although there was far less to discuss than for devector. All agreed that one should be able to control the segment size. - stable_insert was not needed. - segment iteration was good, but should be usable with range-based for loop. The segment iterator should return a segment type if possible, and the segment should have begin(),end(),size() members. - since boost::deque already has a resize with default_init_t, that should be sufficient to provide fast serialization load for trivial types. No need for - resize_front - resize_back - unsafe_uninitialized_resize_front - unsafe_uninitialized_resize_back - reserve - shrink_to_fit() - capacity() The following are still needed for optimal code (or code that can be known not to reallocate, or for better locality in deserialization, avoiding double initialization) - free_front_capacity; - free_back_capacity; - reserve_front - reserve_back - unchecked_emplace_front - unchecked_emplace_back Boost.Container's unit-tests should be extended with those from batch_deque where it makes sense. Since segmented iteration was somewhat faster, it should be use internally where it makes sense. In particular - copy-constructor - copy-assignment - destructor As for devector, all constructor/functions that iterate over non-overlapping ranges should use memcpy. destructor should use is_trivially_destructible to ensure it is optimized away (similar for erase). ====================== Serialization comments ====================== I suggest that the default versions just do what Boost.Serialization does, perhaps just replacing resize with resize with default_init_t. That ensures it works correctly for all archive types. It also needs to use make_nvp() so the output is identical to std::vector. We will then talk to Robert about how we can take advantage of the binary archive in a correct fashion. ====================== kind regards Thorsten, review manager

8 12

PSA: Travis OS X bottleneck, <cxxstd> new Boost.Build feature
by Peter Dimov 30 Oct '17

30 Oct '17

Travis's OS X resources for open source projects seem to be insufficient, so OS X jobs are very slow and seem to be falling further and further behind. Therefore, library authors are encouraged to keep the OS X jobs to the minimum necessary. Spawning many OS X jobs takes hours (~25 minutes waiting time per job at a quick estimate). On a not entirely unrelated note, Rene Rivera has added a new feature <cxxstd> to Boost.Build that controls the C++ standard in use. So for instance, instead of the old b2 libs/mylib/test toolset=gcc cxxflags=-std=c++11 one can now use b2 libs/mylib/test toolset=gcc cxxstd=11 In addition to being more convenient, this also allows several invocations to be combined into one: b2 libs/mylib/test toolset=clang cxxstd=03,11,14,1z which can be leveraged to cut down on the number of jobs. An example of using cxxstd in .travis.yml can be seen here: https://github.com/boostorg/system/blob/develop/.travis.yml

7 13

Adapting boost::grid_graph vertex descriptors to Boost Geometry
by Brook Milligan 30 Oct '17

30 Oct '17

Generally Boost Graph vertex descriptors are opaque types with limited means of constructing them; they may be default constructed or constructed with the null_vertx() function, by dereferencing vertex iterators, calling source()/target() on an edge descriptor, or by calling the add_vertex() function. It is never expected that one will construct a vertex descriptor directly with a non-default constructor. The Boost grid_graph is similar, with the exception that vertex descriptors may additionally be constructed from a vertex index. However, a vertex descriptor for an n-dimensional grid_graph is quite naturally an n-dimensional point. Consequently, it should be possible, without breaking the abstraction, to construct one (and perhaps use one) as a point. Given that this use is not documented in any way, doing so breaks the abstraction. At least three solutions are possible: - #include <boost/geometry/geometries/adapted/boost_array.hpp> in grid_graph.hpp: boost::array<> is the implementation of the grid graph vertex descriptor, so this would immediately make vertex descriptors model Boost Geometry points. - Add a boost/graph/adapt_grid_graph_to_geometry.hpp (better name needed) file that includes the same file so that the selection is optional. - Add a boost/geometry/geometries/adapted/grid_graph.hpp file that includes the same file, again making the selection optional. Since the contents of boost/geometry/geometries/adapted generally refer to external libraries (e.g., Boost Array), the last option seems the most appropriate, although it suffers in case the vertex descriptor is changed but not the adaptor. That however applies to all the adaptors equally. Any of these solutions differs from using boost/geometry/geometries/adapted/boost_array.hpp directly in user code, because that requires unpacking the nature of the vertex descriptor and leaves open the potential for breaking changes in user code if the vertex descriptor changes. Because a vertex descriptor is opaque, breaking the abstraction seems inappropriate, even here. Thus, I suggest the following: - add boost/geometry/geometries/adapted/grid_graph.hpp which includes boost/geometry/geometries/adapted/boost_array.hpp. - add the new adaptor to the Boost Geometry documentation - add a note to the Boost Graph grid_graph documentation indicating that it is possible to adapt the vertex descriptor and use it as a point. Thoughts? Cheers, Brook

2 2

[contract] help marking regression test expected failures
by Lorenzo Caminiti 27 Oct '17

27 Oct '17

Hello all, I need some help with marking some Boost.Contract regression tests as expected failures. I don't understand why my explicit-failures-markup.xml: https://github.com/boostorg/boost/blob/develop/status/explicit-failures-mar… Doesn't math the expected failures I see on the regression report: http://www.boost.org/development/tests/develop/developer/contract.html For example, the following from explicit-failures-markup.xml (around line 887) should marked old-if_copyable test as an expected failure on msvc-11.0: ... <mark-expected-failures> <test name="old-if_copyable"/> <test name="old-if_copyable_macro"/> <toolset name="gcc-gnu-4.7.2"/> <toolset name="gcc-gnu-4.7~c++11"/> <toolset name="gcc-mngw-gnu-4.6c+"/> <toolset name="gcc-mngw-gnu-4.7c+"/> <toolset name="msvc-10.0"/> <toolset name="msvc-11.0"/> <note author="Lorenzo Caminiti"> Test fails because this complier version does not properly implement SFINAE causing incorrect errors on substituion failures for private and protected members (this seems to be fixed in GCC 4.8 and MSVC 12.0). </note> </mark-expected-failures> ... But the old-if_copyable test still shows up as a failure on the regression test report: http://www.boost.org/development/tests/develop/developer/output/teeks99-08-… Any idea what I am doing wrong? Thank you. --Lorenzo

5 19

path length too long for 64 bits builds
by Vicente J. Botet Escriba 27 Oct '17

27 Oct '17

Hi, we have an issue since we have added threadapi= . On 64 bits windows machines we are seen Austin Beer said in https://github.com/boostorg/thread/pull/188#issuecomment-339829423 "FYI, the 64-bit Windows builds are failing due the unit tests exceeding the 260 character filepath limit on Windows. Every filepath includes |\msvc-14.1\debug\address-model-64\threadapi-win32\threading-multi|. Do you know if there is an easy way to shorten this? On the 32-bit builds the filepaths don't have |\address-model-64| which is just enough to keep them under the 260 character limit so they don't fail." Is there a workaround to this issue without changing the specific part of the test files folder structure? Best, Vicente

3 3

Boost::iostreams dual-use seekable filter
by Jonathan Biggar 26 Oct '17

26 Oct '17

I see dual-use filters and seekable filters, but I can't find an example of a dual-use seekable filter. Any help digging me out of template error heck would be appreciated.

1 0

Seems like I need write-access to merge a PR
by Fernando Cacciola 25 Oct '17

25 Oct '17

Hi, It's been a lifetime since I last worked on Boost, and I'm lost as to the current procedures with the repository. I've been looking into this open ticket: https://svn.boost.org/trac10/ticket/12972 and noticed this open pull request: https://github.com/boostorg/numeric_conversion/pull/7 but even though I'm logged with my Github account, it appears I don't have write-access to merge this PR. I tried the wiki but seems to have way too much information. Can you simplify the steps needed, these days, to fix a bug on a library? specially if someone else already created a PR as in this case? TIA -- Fernando Cacciola SciSoft Consulting, Founder http://www.scisoft-consulting.com

7 17

Help wanted: Open pull request reminders
by Beman Dawes 25 Oct '17

25 Oct '17

As a library maintainer, I'd like to get periodic reminders of open pull requests for libraries I maintain and perhaps some other libraries I'm interested in. I'd like a email reminder, but others might prefer Slack or other forms of notification. A related need is for anyone to be able to find the total number of open pull requests for Boost as a whole, and perhaps get a sorted list of the per library counts. Or maybe we should just show today's count on the web site? Googling for "github open pull request reminders" shows that lots of others feel the same need. Would someone like to volunteer to review what others are doing to meet this need, and recommend an approach suitable for Boost? --Beman

9 12

Re: [boost] Boost.TR1 silently removed with 1.65?
by Guido Trentalancia 25 Oct '17

25 Oct '17

On the 9th of September 2017 19:38:43, Tim Rakowski <tim.rakowski_at_[hidden]> wrote: > Hi, > > I noticed that boost 1.65 does not contain the tr1 folder and found that > the documentation was updated accordingly: > http://www.boost.org/doc/libs/1_64_0/ contains > http://www.boost.org/doc/libs/1_64_0/libs/tr1/, while > http://www.boost.org/doc/libs/1_65_0/ has no > http://www.boost.org/doc/libs/1_65_0/libs/tr1/. > But http://www.boost.org/users/history/version_1_65_0.html > <http://www.boost.org/users/history/version_1_65_0.htmldoes> does not > mention this. > Even if it was deprecated, shouldn't this be mentioned somewhere? Googling > "site:https://lists.boost.org/Archives/boost/ 1.65 tr1" didn't yield > anything either :/ > Regards, > Tim Hello ! I am experiencing the same problem... Software packages using boost require the TR1 header files in order to build, but the TR1 header files are no longer available in version 1.65.1 ! What is going on ? Regards, Guido

5 5

[regression tests] feature request: UI integration of bjam requires clause
by Joaquin M López Muñoz 25 Oct '17

25 Oct '17

Hi, Boost regression tests as run by run.py can be explicitly disabled through two different mechanisms: 1. By marking the disabled toolsets with <mark-unusable> in status/explicit-failures-markup.xml. 2. By adding a requires clause in the corresponding Jamfile.v2 file. For instance, in Boost.PolyCollection C++11 is mandated through project : requirements [ requires cxx11_noexcept ] # used as a proxy for C++11 support ... (https://github.com/boostorg/poly_collection/blob/develop/test/Jamfile.v2 ), which results in non-C++11 toolsets being effectively disabled. The problem is that both mechanisms show very differently in the HTML report: http://www.boost.org/development/tests/develop/developer/poly_collection.ht… Toolsets disabled through markup appear grayed out wth a "n/a" legend and an (optional) link to an explanation of why the toolset doesn't work, whereas tests blocked by Jamfile's requires just show a blank column. Would it be possible to modify the regression test HTML reporting utility so that Jamfile-blocked toolsets show also as "n/a" in gray or something similar? The possibility of also adding a link to a custom explanation would be a boon, but I guess this is much harder. This would greatly increase the readability of the reports, particularly by non-savvy users who are likely to deem blank columns as just missing tests that might eventually be filled up. Many thanks, Joaquín M López Muñoz

2 2

Release Note responsibilites for maintainers
by James E. King, III 24 Oct '17

24 Oct '17

The upcoming release of 1.66.0 will be my first release in a maintainer role. How are the release notes generated and what are maintainer's responsibilities during each phase of the release cycle? Thanks, Jim

2 1

RFC.. Steering Committee Bylaws Proposal
by Rene Rivera 24 Oct '17

24 Oct '17

It has become clear to me, and some others, that the recent decisions of the Steering Committee have exposed various problems with how the Steering Committee operates. At CppCon I met with some of the Steering Committee and expressed the concerns with them. I also explained, from my experience in other organizations, how such issues are managed. The result of that is that I will be proposing the Steering Committee adopt operating Bylaws. But before formally presenting them to the Steering Committee I'd like get feedback on them <http://bit.ly/2hI22DN>[1]. The Bylaws hopefully address some key issues that I feel are at the core of the current problems: * Decisions can be made without input from interested parties. * Opaque selection of members. * No recourse by library authors to correct problems. This follows the original goals of the formation of the formation of Steering Committee of being transparent and responsive < http://bit.ly/2yoL5Ij>[2]. [1] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/Boost%20Steering%20Committee%20Bylaws.md> [2] <https://github.com/grafikrobot/other/blob/master/ bsc-bylaws-proposal/2011-05-20%20Boost%20governance%20annotated.pdf> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net

13 35

boost timer, warnings, backlog
by James E. King, III 24 Oct '17

24 Oct '17

I'm seeing a warning for use of "long long" in a lot of builds, originating in Boost.Timer. I like warning-free builds, so this is something I would like to see resolved. There's an issue in Boost Trac for it: https://svn.boost.org/trac10/ticket/12996 There's a pull request open since April for it (and 3 more going back a couple years): https://github.com/boostorg/timer/pull/4 Is this module still actively maintained? Thanks, Jim

5 6