- Boost - lists.preview.boost.org

C++17 detection
by Robert Ramey 14 Sep '17

14 Sep '17

How do I get ready for C++17? I have a piece of code which requires C++14. I want to use something from C++17 but I also want my code to work now. So I have #if C++14 being used namespace std { // implement C++ function } // std I've looked in the documentation for Boost.Config and can't find any hints there. What is the best way to do this? Robert Ramey

14 25

[review queue] we seem to have double allocated early September for review --- what to do?
by Thorsten Ottosen 12 Sep '17

12 Sep '17

Hi All, I was about to announce the start of the Boost.Double_ended review, running from today to 17th of September. This is what we agreed upon with John (Phillips). Now, when I look at http://www.boost.org/community/review_schedule.html it seems that there is also a review of the Fit library scheduled, greatly overlapping with Boost.Double_ended. Do we run two reviews simultaneously, or what? kind regards Thorsten

5 12

Re: [boost] Review Request: impl_ptr (pimpl)
by Vladimir Batov 11 Sep '17

11 Sep '17

On 2017-08-19 23:55, Mario Lang wrote: > Vladimir Batov via Boost <boost(a)lists.boost.org> writes: > ... > I got interested enough by this posting so that I ended up doing my own > mini-review just right now :-). And I just wanted to let you know (and > encourage you) that I like this one alot. Keeping the public interface > free of boilerplate is quite nice! Mario, Thank you for your input. Much appreciated... although somewhat early. :-) It was pointed out to me that Boost review procedures changed and a proposal has to be endorsed before it can move to the review stage. So far I do not see it happening... maybe because the list is quiet (overall), maybe because iml_ptr is not good enough to attract that support/endorsement, maybe giving "endorsement" puts too much pressure and people shy away from it. We'll see. > I think for a full boost review, you will probably need to work on: > * The documentation > While I gave it a read, I ended up skipping to your test case because > I wanted to see working example code. > While the current docs have quite some examples, they spend a lot > more > screen space with showing what impl_ptr tries to replace, without > showing a good motivating positive example of how it actually looks > when employed. It also feels like it is spending some time with > marketing speak, while not really showing what it is trying to sell: Yes, I hear you... and I (at least partially) agree with you. First, no code or documentation will ever be to everyone's liking... unless everyone writes their own. Secondly, the documentation reflects many discussions we've had on this list about pimpl. For ex., I had to explicitly add what you call "marketing speak" to plainly explain why IMO pimpl is important. I had to address numerous "why bother" dismissing comments. What you call "marketing speak" I call an architectural view of a project. IMO it's quite different from developer's view that you seem to favor. All views are important... and all of them IMO need to be mentioned to cater for and to convince different readers. Surely, you (as a developer) is free to skip the "marketing speak". Somebody else (an architect and code-reviewer) might decide to skip other bits. No drama. Does it make sense? > The separation between the public interface in a hpp and the template > specialization in a cpp. I think the motivating example should > clearly show what part of the code goes where. Isn't what I did in third and fourth chapters? That said, I'll never be able to write the way you (or somebody else) like it. So, if you feel really strongly about it, please feel free to re-write it as you feel proper and submit. I am more than happy to consider and take others help. Unfortunately, that'll reverse our positions as I (and potential reviewers) might be saying "nuh, not enough "marketing speak" and such. No pressure... but that's an option to shape it up to your liking. > * Namespace: > While the alias is good, I think the whole code should be moved to > boost::, and the detail to boost::detail::impl_ptr::. > I am sort of guessing this will come up in the review. > I might be interested to help with that and submit the renaming PR if > you are open to that. 1) I do agree that the "whole code should be moved to boost::"... when it is part of Boost. Currently it is not. Currently I am on the earliest stage of gathering interest and waiting for "endorsement" and the review manager. 2) As I think I mentioned before impl_ptr is not part of any namespace by design... because the way proxy and implementation are connected, the specialization of impl_ptr<>::implementation. As I also mentioned it is IMO only a "problem" for "purists" but not for "practitioners" as from outside it is all kosher and accessed via boost::impl_ptr. You might be interested in searching for "Pimpl Again?" thread on this list for prev. discussions. Still, it you know a way around it and willing to submit your suggestions, I am certainly open for and most welcome it. But just to state the obvious -- as you do not like every line of code/doc that I write -- that goes both ways.

5 14

[beast] Post-review follow up (RE: chunk-encoding) NEEDS YOU!
by Vinnie Falco 11 Sep '17

11 Sep '17

During the formal review for Beast, a valid point was raised that the facilities for interacting with the chunks which make up a chunk-encoded was insufficient for some use-cases. I added more interfaces to addresses the use-cases but I never got feedback from the stakeholders about the design. It is now September 10th, and the "pencils down" deadline for making changes to Beast ahead of the 1.66.0 scheduled release is October 25th. As I have not gotten any feedback, I am asking the community if there is anyone out there who would like to review the new chunk-encoding facilities. As of yet, no one in the wild has used them. Or if they have, I did not hear of it. This is the documentation for the chunking: <http://www.boost.org/doc/libs/master/libs/beast/doc/html/beast/using_http/c…> Repository: <https://github.com/boostorg/beast> Any feedback is appreciated. Thanks

1 0

Fit review - viboes
by Vicente J. Botet Escriba 10 Sep '17

10 Sep '17

Hi, here it is my review. I believe that Boost.Fit should be*accepted*. *Design* The design is sound and clean. I have some concerns respect the the ConstFunctionObjects that I believe should merit an explanation on a rationale section. Why the library support only Const function objects? Wondering if some parts should be moved to Boost.TypeTraits or reused from there (is_callable). I'm missing the std::invoke function. The_adaptor<> are not documented. The utility of those classes is not documented. If the user can use those classes the documentaion must document them. I guess they are useful to build other adaptors. It is not clear whether the defined functions would use SFINAE or just fail when used with types that don't respect the requirements. While I'm generally for SFINAE, I understand that it will not be the case in order to improve the compile time. It is not clear if the functions can be final function objects or not. *Implementation* Not seen in depth. It should use as much as possible Boost.Config and/or Boost.Predef Possible files contains details that could be shared in Boost or used from other Boost libraries https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/move.hpp - I believe Hana use something like this also to reduce the dependencies (compile footprint) https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/forward.… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/noexcept… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/and.hpp - I believe Hana use something like this also to reduce the dependencies (compile footprint) https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/compress… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/constexp… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/intrinsi… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/pp.hpp https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/remove_r… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/result_o… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/static_c… https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/detail/using.hpp It uses a lot of macros that make complex the understanding of what is behind. On the same file https://github.com/pfultz2/Fit/blob/boost/include/boost/fit/compose.hpp and only on 169 lines BOOST_FIT_INHERIT_CONSTRUCTOR, BOOST_FIT_RETURNS_CLASS, BOOST_FIT_SFINAE_RESULT, BOOST_FIT_MANGLE_CAST, BOOST_FIT_DECLARE_STATIC_VAR, BOOST_FIT_NOEXCEPT_CONSTRUCTIBLE, BOOST_FIT_ENABLE_IF_CONSTRUCTIBLE, BOOST_FIT_JOIN *Documentation* Quite good butthe description of the semantic of the provided functions would need some extra wording. Maybe a section that states that the semantic expression is part of the constraints on the types. It takes too much pages to see what the library proposes. For some functions we would need more information, examples. See below the detailed *Potential usefulness of the library* Very useful. *Did you try to use the library? With which compiler(s)? Did you have any problems?*** Not tried yet. *How much effort did you put into your evaluation? A glance? A quick reading? In-depth study?*** In-depth study of the documentation (about 5 h for this revision). *Are you knowledgeable about the problem domain?* In general, yes. *Were the concerns from the March 2016 review of Fit addressed?*** I believe ;-) Best, Vicente *Documentation:* In general: * Navigation only from the top of the page * Hyper links missing. * There is no link to real code from the examples. In particular: *http://pfultz2.github.io/Fit/doc/html/doc/src/gettingstarted.html* An explanation of the BOOST_FIT_LIFT limitations would be more than welcome. Typo: last right parenthesis in // Pipable sum BOOST_FIT_STATIC_LAMBDA_FUNCTION(sum) = pipable([](auto x, auto y) { return x + y; }); It is not clear if the following is correct in the body of a function autosum = pipable([](auto x, auto y) { return x + y; }; *http://pfultz2.github.io/Fit/doc/html/doc/src/example_print.html* I would suggest to use an heterogeneous tuple in the for_each_tupleexample. In addition use some kind of brackets to print the sequences and the tuples would help to identify what is been printed. *http://pfultz2.github.io/Fit/doc/html/doc/src/example_overloading.html* Typo: Before // Check that T has member function for operator* and ope After // Check that T has member function for operator* and opeerator-> I'm not sure the example is_derreferenceable is fair. *http://pfultz2.github.io/Fit/doc/html/doc/src/example_polymorphic_constructors.html* Maybe it is worth adding references to the proposals (P0318R0 and P0338R2) *http://pfultz2.github.io/Fit/doc/html/doc/src/more_examples.html* Extension Methods It is not clear what numbers, filter and transform are in the example. I believe that the range proposal woul include the pipe operator. My question is how both pipe operator overloads interact. http://pfultz2.github.io/Fit/doc/html/doc/src/point_free.html typo Before |b(f)(x, y)| |after| ||by(f)(x, y)|| *http://pfultz2.github.io/Fit/doc/html/doc/src/definitions.html* It woul dbe great to have an example associated to each definition Static Function Adaptor I would say "It has an additional requirement that the *class****function* is |DefaultConstructible|:" Decorator I would say "The *resulting* Function Adaptor <http://pfultz2.github.io/Fit/doc/html/doc/src/definitions.html#function-ada…> may be an unspecified or private type." Typo? Some parts of the documentation provides *http://pfultz2.github.io/Fit/doc/html/doc/src/concepts.html* ConstFunctionObject I would like to note that this concept is not representable using the Concept TS as it is quantifying universally on the Ts (args) parameters. The same applies to UnaryFunctionObject, BinaryFunctionObject Wondering if the documentation should use the term Concepts then. The use of expresion "Is an object with ..." is confusing. What are we qualifying the type or the instance? Maybe it is worth defining FunctionObject. EvaluatableFunctionObject It is not clear why this kind of FunctionObjects is useful Callable I believe we have moved to call this Invocable in the standard. But again, I believe that you want to quantify universally the arguments, isn't it? Does your definition of INVOKE differs from the one on the standard? If yes, the differences should be mentioned. If not, the definition on the standard should be referenced. You use type T twice with different meaning "The type |T| satisfies |Callable| if" "if |f| is a pointer to member function of class |T|:" I believe that here the T are not the same. Are final function objects Callable, ConstCallable? ConstCallable The brief description is the same as the one for Callable Is the definition of the second INVOKE different from the first one? UnaryCallable The name doesn't convey that it is *Const*Callable Metafunction and MetafunctionClass it is not clear what those are, there is no brief description. I guess that this applies to f. What do you mean by a type or a template? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/by.html* It is not clear to me what by(p)(xs...) == p(xs)... mean An example of `fit::by` without a function argument will be welcome. It is not clear how by_adaptor<Projection, F> and by_adaptor<Projection> can be used by the user? Shouldn't those be hidden? This is a genral remak, why F must be ConstCallable? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/compose.html *The requirements don't state clearly the constraints on the input parameters of f and the result of g, except by the semantic expression. This is a general remark. I suspect that you mean the semantic expression must be well formed. But, is this SFINAE friendly or is this a requirement? Can both function be final function objects? **** *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/conditional.html* It is not clear what king of parameters this function could have (in particular in comparison with P0051). Does it accept function/data members pointers, final classes, references_wrappers, ...? Typo "Proposal for C++ Proposal for" P0051 original proposal uses overload_linearly/overload (as Boost.Hana) instead of conditional/match. Wondering if those names aren't more clear. Why do we need to change the Boost.Hana names? There is also std::conditional :( Can more than 2 parameters be final function objects? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/flip.html** * IIUC, F must not be BinaryCallable, but Callable with at least two arguments. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/implicit.html* Is implicit a StaticFunctionAdaptor? Shouldn't StaticFunctionAdaptors have Functions as parameters? I named the `auto_cast` function `explicitly` to do a explicit conversion. Other uses of this pattern I've see are to create a buffer able to store a specific struct struct S; S* ptr = create_msg(); create_msg returns an class that is convertible to a T* and that allocates sizeof(T) bytes of memory. Why this pattern respect the DRY principle (we don't repeat S), I believe it abuses of implicit conversions. Anyway, I wanted just to share another use case for implicit. http://pfultz2.github.io/Fit/doc/html/include/boost/fit/indirect.html Wondering if it could be worth adding some preconditions as I guess that the function call indirect(f)(xs...) will be undefined if f is null *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/infix.html** * One of the asked infix operations is pow. However we would like to evaluate from right to left and have the higher precedence than * x pow ypow z===pow(x, pow(y,z)) x * ypow z===x * pow(y,z) x pow y* z===pow(x,y) * zWith the proposed infix notation this should be written x <pow> (y<pow> z)===x * pow(y,z) x * (y<pow> z)===x * pow(y,z) (x <pow> y)* z===pow(x,y) * z and the following would be surprising x <pow> y<pow> z===pow(pow(x, y, z) x * y<pow> z===pow(x * y, z) x <pow> y*z===pow(x, y * z) It would work better for swap or compare (proposed operator <=>) as these functions are not associative. I believe a note should prevent the users for such bad use cases, for which it is better to don't define the infix operator. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lazy.html* Note p0356r1. It would be good to have a comparison in order either to improve the proposal or your library. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/match.html* Same comments than for fit::conditional. What are ex typo "Proposal for C++ Proposal for" Can more than 2 parameters be final function objects? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/mutable.html *Example of bad usage would be welcome.**Why Fit uses always const? **Why not use a reference to the function object instead? Is there a safe way to use MutableFunctionObjects with Fit? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/partial.html* Are there any constraints on the type of xs. Shouldn't them be MoveConstructibles? http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pipable.html Are there any constraints on the type of x. Shouldn't it be MoveConstructible? http://pfultz2.github.io/Fit/doc/html/include/boost/fit/protect.html It is not clear to me what this useful for. Could you elaborate? Is there a typo here assert(lazy(f)(protect(lazy(g)(_1)))() == f(lazy(g)(_1))) ^ Shouldn't it be assert(lazy(f)(protect(lazy(g)),_1)() == f(lazy(g)(_1))) *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/result.html*** This adaptor converts explicitly the result of the call to the type. Have you considered `convert_to`? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html* as_failures, with_failures, .... /adaptors/ don't appear on the index. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reverse_fold.html* reverse_fold is not right fold, as right fold is right associative, isn't it? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/rotate.html*** Could you show a concrete use case? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/static.html*** What are the differences of this adaptor and the macro STATIC_FUNCTION? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack.html* Why name it unpack instead of apply like in C++17? Need to introduce the Sequence concept and how it is customized? unpack_sequence? How unpack_sequence is used by unpack? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/unpack_sequence.html*** Why unpack_sequence, and not the tuple-like traits? Is unpack_sequence defined if the class defines the tuple-like traits? Aside the example, it is not defined what the user must define. What the member function apply must return? How the unpack_sequence parameter and the Sequence parameter of member function apply are related? I don't understand template<class F, class Sequence> constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS ( s(std::forward<F>(f)) ); Is a Sequence a callable taking a Callable or there is a type here? Is there a missing return? I suspect it should be template<class F, class Sequence> constexpr static auto apply(F&& f, Sequence&& s) BOOST_FIT_RETURNS ( std::forward<F>(f)(s0, ,, sk); ); If this is correct, does it means that unpack just forwards to unpack_sequence? Does the default specialization make use of INVOKE? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/capture.html*** Please, could you show how it is more flexible than lambda captures in C++? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/if.html* What happens when the parameter is false_type? SFINAE? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/limit.html*** if a function object is overloaded with 2 and 3 parameters, would limit be useful or it is only useful when the number of parameters is fixed? I believe this is answered in http://pfultz2.github.io/Fit/doc/html/doc/src/partialfunctions.html, however I believe it merits a clarification here. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat.html* Add requirement on the function parameter that must be a Unary function such that f(f(x)) is well formed. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/repeat_while.html* The same here. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/arg.html*** What is the rational for the choice of been 1-based? Could you add a rationale in the doc? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/construct.html* Maybe add a reference to the factory proposal p03382. What happens when the parameter is not a T is not constructible from the params? SFINAE? What happens when the parameter is not a MetafunctionClass? SFINAE? I believe Boost.Hana uses make instead of construct. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/decay.html* Why not decay_copy? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/identity.html *is identity a function or a function object? do we need identity()(x)? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html*** Wondering if it is not better to locate them in a placeholders namespace, so that we can avoid possible collisions with other placeholders. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/placeholders.html#unamed-placeholder* The same here *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function_param_limit.html*** |function_param_limit is not a Metafunction. "|The|function_param_limit| metafunction ..." *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/is_callable.html*** F must be Callable can not be a requirement ;-) Add reference to C++17 trait is_invocable. Wondering if we should have it in type_traits, if not already there. *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/apply.html*** Confusion with std::apply. is this related to std::invoke? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/function.html* "By default, all functions defined with|BOOST_FIT_STATIC_FUNCTION| use thereveal <http://pfultz2.github.io/Fit/doc/html/include/boost/fit/reveal.html> adaptor to improve error messages." How to change this default? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/lift.html*** WhyBOOST_FIT_LIFT_CLASSdoesn't defines a instance as do BOOST_FIT_STATIC_FUNCTION? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/pack.html*** How this is related with fit::capture? *http://pfultz2.github.io/Fit/doc/html/include/boost/fit/tap.html* How this is related to the tee unix command? *http://pfultz2.github.io/Fit/doc/html/doc/src/configurations.html***Which ones?

2 3

How to deal with unused variable with a BOOST_ASSERT check?
by James E. King, III 10 Sep '17

10 Sep '17

In serialization (boost/archive/iterators/mb_from_wchar.hpp) there is some code that generates a warning on release builds. We're always striving for warning-free code in all cases. Here's the snippet: std::codecvt_base::result r = m_codecvt_facet.out( m_mbs, & value, & value + 1, wend, m_buffer, m_buffer + sizeof(m_buffer), bend ); BOOST_ASSERT(std::codecvt_base::ok == r); Normally I'd say one should always check the result and throw an exception instead of relying on an assert. I'm sure consumers would like that more. That said, is there another macro that would allow me to change the code to do something like this? BOOST_ASSERT_ASSIGN_OR_IGNORE(std::codecvt_base::result r) m_codecvt_facet.out( m_mbs, & value, & value + 1, wend, m_buffer, m_buffer + sizeof(m_buffer), bend ); BOOST_ASSERT(std::codecvt_base::ok == r); where BOOST_ASSERT_ASSIGN_OR_IGNORE would expand to, assuming BOOST_ASSERT_ACTIVE is an indicator whether assert code is compiled in: #if BOOST_ASSERT_ACTIVE std::codecvt_base::result r = #else (void) #endif This would allow me to eliminate the warning without submitting a PR that changes the behavior of the code. If something like this does not exist, would it be useful for me to add it to boostorg/assert, or would folks recommend against encouraging this behavior and instead change it to use exceptions? Thanks, Jim

5 4

range/concepts.hpp broken on master
by Peter Dimov 09 Sep '17

09 Sep '17

Trying to, f.ex., build quickbook on master fails with an error like ./boost/range/concepts.hpp: In destructor 'boost::range_detail::SinglePassIteratorConcept<Iterator>::~SinglePassIteratorConcept()': ./boost/range/concepts.hpp:167:55: error: 'iterator_traits' in namespace 'boost::detail' does not name a type That's because boost/iterator/iterator_concepts.hpp used to include boost/detail/iterator.hpp, and no longer does since this commit: https://github.com/boostorg/iterator/commit/0107df44ab3ab41c46b616c9c37c30f… This apparently works on develop, which means that it's probably fixed in Range's develop branch, but the changes aren't in master.

1 2

[build] using nvcc as toolset target?
by Oliver Kowalke 09 Sep '17

09 Sep '17

Hello, a grep over the boost.config showed some code related to nvcc - but I could not figure out how to use nvcc together with b2. What is the toolset target for nvcc ('b2 toolset=nvcc' doesn't work)? Oliver

2 2

Why is the boost documentation so bad?
by Florian Lindner 08 Sep '17

08 Sep '17

Hello, I really love to use boost libraries in my project, but I always wonder, for such an accomplished project, why is the documentation so bad? A few examples: I want to get familiar with http://www.boost.org/doc/libs/1_65_1/libs/ptr_container/. What do I need to include? Neiter the tutorial, the reference or the usage guidelines mention a #include line. This is something which stroke me quite often at various boost libs. Also with the ptr_container lib, I want to find the refrence for the ptr_vector::insert function. I got to scan the reference pages of all members of it's class hierarchy to find the insert() function (it's in ptr_sequence_adapter). References and example code often have no syntax highlightning and no linking and it's extremely hard to find documentation for a specific symbol, or from there, to jump to the source code. I would really like to have a more uniform and a documentation that not feels like a annotated source code dump. I use doxygen for my own projects and I know it can generate nicely looking, with syntax highlightning and linked documentation. Please, don't take this offensive, it's just some feedback I wanted to give a long time. Best, Florian

12 13

[release] 1.66.0 open for merging
by Daniel James 08 Sep '17

08 Sep '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

Re: [boost] (no subject)
by degski 08 Sep '17

08 Sep '17

On 7 September 2017 at 17:37, Pranam Lashkari <plashkari628(a)gmail.com> wrote: > Hello, > > I recently joined boost community. I am an engineering student from India. > I don't have much experience with contributing in open source. > > Can you please help me getting started with it? > > From where I can/should start contributing this community..? > > Thank you. > Hi Pranam, You have to write to the boost mailing list: boost(a)lists.boost.org (and ask there) See also http://www.boost.org/community/groups.html for some "rules and regulations" and the need for "subscription". You can find the archives (old posts) here: https://lists.boost.org/ Archives/boost/ In the archive you'll see that your question has been asked (many times) before, answers where to start are also given in the follow-up to those questions. Personally, I would like to see Boost.Pool being brought up to the current C++ standard (C++17). That would be a nice little project. I believe Edward Diener is the current curator of that particular library. See you on the list and have a good day (and don't forget to subscribe), degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

1 0

[gsoc] Change in Google Summer of Code admin
by Niall Douglas 07 Sep '17

07 Sep '17

Dear all, Google Summer of Code 2017 has ended with another successful summer of student coding with probably the highest calibre year we've ever seen. After four years as lead admin for Boost Summer of Code, my time has come to an end. I'll be making way for David Bellot, long time mentor at Boost GSoC and maintainer of Boost.uBLAS. Please join me in welcoming David as new lead admin. I'll be staying on as backup admin next summer to help David settle in. My time as Boost Summer of Code admin has certainly been eventful with lots of surprises, ups and downs. The fact these surprises did not turn into crises is due in large part to a few people in particular who went far beyond the call of duty: * Jon Kalb, who went to bat for the students repeatedly in multiple venues and finding tens of thousands of dollars when it was needed. * Boris Schäling, whom I replaced as lead admin and who acted as backup admin for some years, who also managed to arrange tens of thousands of dollars of sponsorship when it was needed most. * Bryce Adelstein Lelbach, for acting as backup admin these past few years. * Andrew Sutton, the lead GSoC admin before Boris, who gave such detailed and useful early advice and materials on how to best navigate the treacherous waters of Google Summer of Code! And finally to all the mentors who so generously volunteered their time, and to the students every single one of whom successfully finished their projects in my time as admin despite problems with sickness, deaths in close family etc. Some of those students have gone on to become mainstays of the C++ conference circuit, famous names in their own right. I'm sure they would have been so without Google Summer of Code, but I'd like to think that it helped bring them to Boost rather than them getting into C++ via elsewhere. Thank you students! Regards, Niall

5 5

master and develop branches
by James E. King, III 07 Sep '17

07 Sep '17

Could someone point me to documentation on management of the master and develop branches for committers? boostorg/uuid master ends at Jan 11. boostorg/develop has a bunch of stuff in it starting on August 3, 2017. Who is responsible for merging develop into master and when should that happen? Some of the issues are already marked resolved with a milestone of 1.66.0 but they are not in master, only develop. Should pull requests on github go directly into master? I find it confusing to have both and would prefer if there was only one possible destination for pull requests on github. If there are two, someone has to keep one of them updated and that isn't very efficient. Thanks, Jim

4 3

Libraries maintained by CMT?
by James E. King, III 07 Sep '17

07 Sep '17

Hello, I was wondering if there's a page/location that lists the libraries currently being maintained by the community maintainer team? I recently assumed responsibility for maintaining boost::uuid and I was wondering if there was a list that needs to be modified. Thanks, - Jim

4 5

[release] Boost 1.65.1
by Daniel James 07 Sep '17

07 Sep '17

Release 1.65.1 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 bug fixes for existing libraries. For details, including download links, see <http://www.boost.org/users/history/version_1_65_1.html> You can also download directly from: <https://dl.bintray.com/boostorg/release/1.65.1/> 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 Rene Rivera Marshall Clow Eric Niebler Daniel James Beman Dawes

1 0

Appveyor and Travis CI for pull requests
by James E. King, III 07 Sep '17

07 Sep '17

Some of the repositories have Appveyor and Travis CI build configuration files in them. I don't see this translating into automatic builds on top of each pull request. I'd like to get the uuid library to the point where a pull request builds on Appveyor and on Travis, so that it is easier to validate the code changes are okay. Could someone let me know if this is possible and if so, how? Thanks, Jim

3 2

[pool] variadically templated object_pool.construct()
by degski 07 Sep '17

07 Sep '17

I would like to request to bring object_pool.hpp up-to-date (all the way to 2011) and include a member function with this signature: template<typename ... Args> element_type * construct( Args && ... args_ ); degski -- "*Ihre sogenannte Religion wirkt bloß wie ein Opiat reizend, betäubend, Schmerzen aus Schwäche stillend.*" - Novalis 1798

2 2

[1.65.1] Release tomorrow
by Daniel James 06 Sep '17

06 Sep '17

Hi, I'm planning on releasing tomorrow. I've written up some release notes: http://www.boost.org/users/history/in_progress.html Let me know if you want any changes to them. Daniel

2 2

[stacktrace] Not working on Cygwin
by Phil Bouchard 06 Sep '17

06 Sep '17

Hi, I tried stacktrace on Cygwin and after tweaking some local and system headers I was able to compile libboost_stacktrace_windbg.a and libboost_stacktrace_addr2line.a but when I run my application calls to boost::stacktrace::stacktrace(1, 1) doesn't output anything. It works fine under Linux using libboost_stacktrace_backtrace.a. Thanks in advance for your help, -Phil

2 2

Upcoming Boost.Fit Review (September 8th-17th)
by Matt Calabrese 05 Sep '17

05 Sep '17

Hi everyone, This coming Friday, September 8th, marks the start of review of the Fit library by Paul Fultz II. Source: https://github.com/pfultz2/Fit Docs: http://fit.readthedocs.org/ This is the second time that the library will go through the review process, with the previous time being in March of 2016. The result of the initial review can be found here: https://lists.boost.org/Archives/boost/2016/04/228770.php In this second review, those who choose to participate should be as rigorous as they'd be in any other review, but are also encouraged to voice whether or not the concerns from March of 2016 were addressed. The following is a brief description of the library from its author: ========== Fit is a header-only C++11/C++14 library that provides utilities for functions and function objects, which can solve many problems with much simpler constructs than whats traditionally been done with metaprogramming. Fit is: - Modern: Fit takes advantages of modern C++11/C++14 features. It support both constexpr initialization and constexpr evaluation of functions. It takes advantage of type deduction, varidiac templates, and perfect forwarding to provide a simple and modern interface. - Relevant: Fit provides utilities for functions and does not try to implement a functional language in C++. As such, Fit solves many problems relevant to C++ programmers, including initialization of function objects and lambdas, overloading with ordering, improved return type deduction, and much more. - Lightweight: Fit builds simple lightweight abstraction on top of function objects. It does not require subscribing to an entire framework. Just use the parts you need. Fit is divided into three components: - Function Adaptors and Decorators: These enhance functions with additional capability. - Functions: These return functions that achieve a specific purpose. - Utilities: These are general utilities that are useful when defining or using functions. ========== Requirements¶ <http://fit.readthedocs.io/en/latest/doc/src/index.html#requirements> This requires a C++11 compiler. There are no third-party dependencies. This has been tested on clang 3.5-3.8, gcc 4.6-6.2, and Visual Studio 2015. Gcc 5.1 is not supported at all, however, gcc 5.4 is supported. Contexpr support¶ <http://fit.readthedocs.io/en/latest/doc/src/index.html#contexpr-support> Both MSVC and gcc 4.6 have limited constexpr support due to many bugs in the implementation of constexpr. However, constexpr initialization of functions is supported when using the FIT_STATIC_FUNCTION <http://fit.readthedocs.io/en/latest/doc/src/FIT_STATIC_FUNCTION> and FIT_STATIC_LAMBDA_FUNCTION <http://fit.readthedocs.io/en/latest/doc/src/FIT_STATIC_LAMBDA_FUNCTION> constructs. Noexcept support¶ <http://fit.readthedocs.io/en/latest/doc/src/index.html#noexcept-support> On older compilers such as gcc 4.6 and gcc 4.7, noexcept is not used due to many bugs in the implementation. Also, most compilers don’t support deducing noexcept with member function pointers. Only newer versions of gcc(4.9 and later) support this. ========== Please take this time to become familiar with the Fit library before the review takes place and feel free to respond in this thread with any additional questions related to the library or its review. Thanks! -- -Matt Calabrese

1 0

Boost.TR1 silently removed with 1.65?
by Tim Rakowski 04 Sep '17

04 Sep '17

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

1 0

[contract] Ready to release
by Lorenzo Caminiti 04 Sep '17

04 Sep '17

Hello all, I *finally* got around finishing Boost.Contract after the library was reviewed and accepted by Boost about 5 years ago?! (review results: https://groups.google.com/forum/?fromgroups=#!topic/boost-list/jQ7OjAmos_Y) Documentation: https://lcaminiti.github.io/boost-contract/doc/html/index.html Source: https://github.com/lcaminiti/boost-contract * All Contract Programming features (a.k.a., Design By Contract, DBC) are supported: subcontracting, class invariants, postconditions (with old and return values), preconditions, customizable actions on assertion failure (terminate, throw, etc.), optional compilation of assertions, disable assertions while already checking other assertions (to avoid infinite recursion), etc. * Leveraging the convenience of C++11 lambdas, this revision of the library no longer requires "crazy" macros that alter C++ declaration syntax. That makes the library much easier to use, faster to compile, and generates readable compiler errors on misuse. I was thinking to add Boost.Contract to the next, or next next, Boost release... Thanks, -- --Lorenzo

2 2

Boost 1.65.2 Release Candidate 2
by Daniel James 04 Sep '17

04 Sep '17

The second release candidates for the 1.65.1 release are now available at: <https://dl.bintray.com/boostorg/release/1.65.1/> The SHA256 checksums are as follows: df7bea4ce58076bd8e9cd63966562d8cf969b431e1c587969e6aa408e51de606 boost_1_65_1_rc2.7z 9807a5d16566c57fd74fb522764e0b134a8bbe6b6e8967b83afefd30dcd3be81 boost_1_65_1_rc2.tar.bz2 a13de2c8fbad635e6ba9c8f8714a0e6b4264b60a29b964b940a22554705b6b60 boost_1_65_1_rc2.tar.gz d1775aef807bd6a14077b450cce2950d8eacd86aaf51015f79e712917f8cc3c2 boost_1_65_1_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.

3 3

To start contributing to boost
by Yaghyavardhan Singh Khangarot 03 Sep '17

03 Sep '17

Hello boost community, My name is Yaghyavardhan Singh, a 3rd year CS undergrad at IIIT, Hyderabad. I have been using Boost C++ Library for quite some time now and I would like to contribute to it. I have sound knowledge of C++(along with STL) and Advanced data structures and algorithms. As I am new to open source, I need some help to get started. I would be interested to add any new algorithms which might not be part of any specific module yet(say some optimized convex hull algorithm in boost.geometry). I am also open to optimization problems. Thank you, Your's Sincerely, Yaghyavardhan Singh

3 3

[build][wave][thread][date-time] 1.65.0 clang on Windows build failures
by Konstantin Ivlev 02 Sep '17

02 Sep '17

Hi, I am trying to compile boost 1.65.0 on Windows via clang 4.0.1 with the following user-config.jam: using clang : 4.0 : "C:/Program Files/LLVM/bin/clang.exe" : <compileflags>-fmsc-version=1910 <ranlib>"C:/Program Files/LLVM/bin/llvm-ranlib.exe" <archiver>"C:/Program Files/LLVM/bin/llvm-ar.exe" <linkflags>-fuse-ld=lld ; and there are few issues. 1. clang.jam ignores ranlib/archiver settings. currently there is the PR https://github.com/boostorg/build/pull/232 against clang-darwin.jam, and I suppose the same should be applied to the clang-linux.jam. 2. there are numerous errors in boost wave: .\boost/wave/grammars/cpp_expression_grammar.hpp:829:18: error: case value evaluates to -804257404, which cannot be narrowed to type 'unsigned int' [-Wc++11-narrowing] case T_CPPCOMMENT: // contains newline (about 100 errors of such kind for various enumerations) 3. WinAPI-related errors in boost::date_time & boost::thread, e.g. In file included from libs\coroutine\src\windows\stack_traits.cpp:23: In file included from .\boost/thread.hpp:13: In file included from .\boost/thread/thread.hpp:12: In file included from .\boost/thread/thread_only.hpp:15: In file included from .\boost/thread/win32/thread_data.hpp:10: In file included from .\boost/thread/thread_time.hpp:10: In file included from .\boost/date_time/microsec_time_clock.hpp:23: .\boost/date_time/filetime_functions.hpp:57:46: error: conflicting types for 'GetSystemTimeAsFileTime' __declspec(dllimport) void __stdcall GetSystemTimeAsFileTime(FILETIME* lpFileTime); ^ C:\Program Files (x86)\Windows Kits\10\include\10.0.15063.0\um\sysinfoapi.h:159:1: note: previous declaration is here GetSystemTimeAsFileTime( ^ seems like stack_traits.cpp unconditionally includes windows.h, while BOOST_USE_WINDOWS_H is not defined in case of clang build, so filetime_functions.hpp defines its own WinAPI prototypes. probably shall be somehow fixed in boost config? any advice on how to proceed with these issues?

3 4