- Boost - lists.boost.org

[build] VC++ 2017 version number?
by Beman Dawes 24 Mar '17

24 Mar '17

Boost.build in develop is treating VC++2017 RTW (aka RTM) as msvc-14.1. Yet the Visual Studio 2017 RTW Help "About Microsoft Visual Studio" shows the version as "15.0.0-RTW+26228.4" Shouldn't boost.build follow Microsoft's numbering? Seems like calling 2017 RTW anything except 15.0 is a recipe for confusion. --Beman

12 15

Re: [boost] Constructing string_ref from rvalue string
by Mathias Gaunard 24 Mar '17

24 Mar '17

On 23 Mar 2017 7:02 am, "Jonathan Müller via Boost" <boost(a)lists.boost.org> wrote: I've just blogged about this topic: http://foonathan.net/blog/2017 /03/22/string_view-temporary.html (Planned that post before this thread) In my opinion I think `boost::string_ref` and `std::string_view` are two different things, They're not. They were always supposed to be the same thing. There is a lot of code out there that uses std::string_view and boost::string_ref interchangeably depending on which is available.

3 2

Re: [boost] [partly OT] Re: [review queue] What to do about the library review queue?
by Glen Fernandes 24 Mar '17

24 Mar '17

peterkochlarsen wrote: > Also an unmaintained library should be marked as such as should > libraries that are deprecated, replaced by standard C++ features > (shared_ptr comes to mind) shared_ptr (or Boost.SmartPointers in general) is not unmaintained, and is not deprecated. It actually has been evolving past the C++11 std::shared_ptr. For example, boost::shared_ptr supported array forms in 1.53 and this was eventually added to C++ in C++17. (Interesting aside: That functionality above was even, and still is used, in certain Microsoft projects, where boost::shared_ptr is used instead of std::shared_ptr). The same goes for other Boost libraries like Boost.Thread. They: - May have features not in the C++ standard library equivalent - May be evolving past the current C++ standard - Are in use by actual projects and shouldn't be removed Glen -- View this message in context: http://boost.2283326.n4.nabble.com/review-queue-What-to-do-about-the-librar… Sent from the Boost - Dev mailing list archive at Nabble.com.

15 51

Is there any interest in type-safe container of bool flags with noexcept guarantees?
by Роман Орлов 23 Mar '17

23 Mar '17

Hello Boost community, I'd like to determine interest in this kind of container. Motivation For managing sets of bool flags developers often use std::bitset or c-like manual bit manipulations. Each approach brings problems. Some disadvantages of using std::bitset: * unpredictable and greedy allocation of bit storage; * setters/getters can throw exceptions; * it operates in low-level terms like "a bit number"; * we can easily assign one instance of std::bitset to another with the same number of bits but semantically they may differ. Proposal Instead of managing bits via numbers let's manage them via types. So start by declaring some types class eats_meat; class eats_grass; class has_tail; Then bind these types to flag identifiers typedef typed_flags<eats_meat, eats_grass, has_tail> animal; Unlike std::bitset the 'animal' instance allocates a minimal possible storage (in this case sizeof(animal) == 1). Create flags from scratch animal wolf; wolf.set<eats_grass>(false); wolf.set<eats_meat, has_tail>(); wolf.set(flag<has_tail>{1}, flag<eats_meat>{1}); Create flags with a flexible human-readable constructor wolf = animal{flag<has_tail>{1}, flag<eats_meat>{1}, flag<eats_grass>{0}}; I have implemented a minimal working prototype in my github repo https://github.com/compmaniak/typed_flags If you're interested you can try it online here http://melpon.org/wandbox/permlink/55g1czUjwSFO8LS1 Expected benefits * delegating calculation of a bit position for a certain type to compiler gives us a strong type safety and prevents typos; * noexcept guarantee of setting and getting bit values; * we shouldn't take care of bits because we work in terms of typed properties; * great readability, taking a short glance on a type definition tells you what this type is about. Some people on reddit (https://redd.it/601upg) found this library useful. Any thoughts on the idea of the container would be much appreciated. -- Roman

8 13

[release] 1.64.0 please test master snapshot
by Rene Rivera 23 Mar '17

23 Mar '17

Looks like 14.1/141 won out the version hysterics. And I've merged in the PRs for that change. Please give the latest master snapshot archives a try. And report both failures and success: <https://dl.bintray.com/boostorg/master/> If nothing Earth shattering comes up this will become the beta on Wednesday 22 (before 24:00 CDT). -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

5 5

Re: [boost] [release] 1.64.0 please test master snapshot
by Rene Rivera 22 Mar '17

22 Mar '17

On Tue, Mar 21, 2017 at 12:36 PM, Tom Kent <lists(a)teeks99.com> wrote: > It looks like the boostorg/boost:master commit this snapshot was based off > doesn't have the latest boostorg/config:master submodule commit. I think > updating this is a manual process at this point in the release cycle? (Thus > the autolink file is still looking for vc150). > Grr.. Forgot to do that for config. I did it for build though :-) It's done now.. Just need to wait again for the new archives. > As an aside, I had a difficult time figuring out what the snapshot I > downloaded referred to. I was able to use the boost_1_64_0_snapshot.tar.bz2.json > file to determine that I had the correct boost_1_64_0_snapshot.tar.bz2, but > bintray doesn't make it super clear what git commit this snapshot download > refers to. > > Would it be possible to add a file to snapshots/releases that contains the > git commit hash? > Can't promise I'll do it right this second... But I'll add the commit hash to the json data for the archives. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

7 14

Boost MSM parallel behavior with delayed self-transitions?
by Christophe Henry 22 Mar '17

22 Mar '17

Hi Danylo, >Hi community, > > I am using Boost MSM (basic and functor front-ends) and am trying to >implement the following state machine (https://i.stack.imgur.com/K79qk.png ): Ok, State1 is itself a state machine (also called composite). See: http://www.boost.org/doc/libs/1_63_0/libs/msm/doc/HTML/ch02s02.html#d0e151 and: http://www.boost.org/doc/libs/1_63_0/libs/msm/doc/HTML/ch03s02.html#d0e529 Then you have 2 active states, which are called orthogonal regions. See: http://www.boost.org/doc/libs/1_63_0/libs/msm/doc/HTML/ch03s02.html#d0e577 >I am using Boost MSM (basic and functor front-ends) and am trying to >implement the following state machine: enter image description here > >In words: < snip > > >I would like to know the way to create this state machine in Boost MSM. The above link has an example. >There are two tricks here which I cannot figure out how to do: > > - Execution in parallel (i.e. running action_A does not stop running >action_B at the same time) It depends what you mean with "in parallel". Having 2 active states means that the actions execute only logically at the same time, meaning within the same process_event call. But as you have just one thread, they will execute after each other. If you mean in different threads, then no, the library does not support this. But my next library, Asynchronous does ( https://github.com/henry-ch/asynchronous) I have examples with state machines, timer, etc. >- Delayed transition (i.e. the transitions which happen after 2 >seconds for state A and after 5 seconds for state B). Neither delay >should be blocking! The transitions should just "fire" after this time. Sorry, this is out of scope of the library as it would involve threads. You can do one of the following: - use your own timer (Boost.Asio offers one) and handle thread safety yourself. - have a look at Asynchronous. Sorry if it looks like advertising, but the library was written for this kind of things. >Thank you very much for helping, > >Danylo. HTH, Christophe

3 4

Re: [boost] [gsoc17] Project1: Static map: Can I implement the competency test in g++-7?
by Vic Luo 22 Mar '17

22 Mar '17

Hi, In the last few days I finished a toy implementation with continuous integration at https://github.com/htfy96/gsoc-static-map, which has been tested on g++5/6 and clang++3.8/3.9. Current test failure is as expected due to g++-5's incomplete constexpr optimization. Besides, my proposal draft has been submitted which includes a very tiny benchmark with boost::hana on compile-time lookup performance on map<int, int> structure. Any kind of suggestion is welcomed at https://gist.github.com/htfy96/0bd9b3200d9a0e67f449edc40bfa43b5*. * Thanks,* * -- --------------------------------- Vic Luo Shanghai Jiaotong University Key fingerprint 0x98809ca08bf5662a

1 0

Re: [boost] [release] 1.64.0 please test master snapshot
by Olaf van der Spek 22 Mar '17

22 Mar '17

On Wed, Mar 22, 2017 at 12:45 PM, Andrey Semashev <andrey.semashev(a)gmail.com> wrote: >> Right, boostorg doesn't have tickets enabled though.. where should I >> open a ticket? > > > Probably, in Trac: I hate Trac. > https://svn.boost.org/trac/boost/newticket?component=algorithm;version=Boos… > > Although since it's fixed in develop and there is a PR for merge to master, > I'm not sure there's much point in a ticket. I meant in general. -- Olaf

1 0

Re: [boost] [release] 1.64.0 please test master snapshot
by Andrey Semashev 22 Mar '17

22 Mar '17

And once again, this went to Olaf directly instead of the list. Re-sending. On 03/22/17 14:45, Andrey Semashev wrote: > On 03/22/17 13:45, Olaf van der Spek wrote: >> On Wed, Mar 22, 2017 at 11:05 AM, Andrey Semashev via Boost >> <boost(a)lists.boost.org> wrote: >>> On 03/22/17 11:59, Olaf van der Spek via Boost wrote: >>>> >>>> VC2015 /std:c++latest: >>>> >>>> struct to_lowerF : public std::unary_function<CharT, CharT> >>>> >>>> boost\algorithm\string\detail\case_conv.hpp(33): error C2143: syntax >>>> error: missing ',' before '<' >>> >>> >>> This seems to be fixed in develop but not merged to master. I've >>> created a >>> PR to do the merge: >>> >>> https://github.com/boostorg/algorithm/pull/34 >>> >>>> https://github.com/mclow/String-Algo/issues/7 >>> >>> >>> That ticket is for a fork, not the boostorg repo. >> >> Right, boostorg doesn't have tickets enabled though.. where should I >> open a ticket? > > Probably, in Trac: > > https://svn.boost.org/trac/boost/newticket?component=algorithm;version=Boos… > > > Although since it's fixed in develop and there is a PR for merge to > master, I'm not sure there's much point in a ticket. >

1 0