- Boost-users - lists.preview.boost.org

Re: [Boost-users] problem of getting vertex_index_t property
by breadbread1984 24 Jul '15

24 Jul '15

Thx for your reply. But I use vecS to store vertices instead of setS. The setS is for storing edges. There should be something else going wrong. 在 2015年7月23日星期四 10:32:28，boost-users-request@lists.boost.org 写道： > Send Boost-users mailing list submissions to > boost-users(a)lists.boost.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.boost.org/mailman/listinfo.cgi/boost-users > or, via email, send a message with subject or body 'help' to > boost-users-request(a)lists.boost.org > > You can reach the person managing the list at > boost-users-owner(a)lists.boost.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Boost-users digest..." > > > Today's Topics: > > 1. Re: [interval] Errors using transc.hpp WAS: Power (Sensei) > 2. problem of getting vertex_index_t property with BGL > (breadbread1984) > 3. Re: problem of getting vertex_index_t property with BGL > (Jeremiah Willcock) > 4. Re: Boost.DateTime and leap year/leap seconds (Auer, Jens) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 23 Jul 2015 10:03:47 +0200 > From: Sensei <senseiwa(a)gmail.com> > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [interval] Errors using transc.hpp WAS: > Power > Message-ID: <55B09FE3.20108(a)gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Dear all, > > I've tried to move beyond simple exp/log functions, but this problem > > > /usr/local/include/boost/numeric/interval/transc.hpp:47:42: No member > > named 'log_down' in 'boost::numeric::interval_lib::rounded_math<double>' > > > > /usr/local/include/boost/numeric/interval/transc.hpp:34:16: No member > > named 'exp_down' in 'boost::numeric::interval_lib::rounded_math<double>' > > arises with *all* of the functions contained in transc.hpp, and I don't > know what I'm doing wrong here. > > Can anyone help me? > > > Thanks! > > > ------------------------------ > > Message: 2 > Date: Thu, 23 Jul 2015 18:25:39 +0800 > From: breadbread1984 <breadbread1984(a)163.com> > To: boost-users(a)lists.boost.org > Subject: [Boost-users] problem of getting vertex_index_t property with > BGL > Message-ID: <2807116.uu1eRmarTQ@xieyi-paf4> > Content-Type: text/plain; charset="utf-8" > > I am using boost graph library. I found there is a built in property > vertex_index_t corresponding to every vertex from the document > [here](http://www.boost.org/doc/libs/1_58_0/libs/graph/doc/adjacency_list.h > tml). But when I get the vertex_index_t property the compiler prompt the > following error: > > CooperativeGraph.h:59:36: required from here > /usr/include/boost/graph/detail/adjacency_list.hpp:2498:29: error: forming > reference to void typedef value_type& reference; > ^ > /usr/include/boost/graph/detail/adjacency_list.hpp:2499:35: error: forming > reference to void typedef const value_type& const_reference; > ^ > /usr/include/boost/graph/detail/adjacency_list.hpp:2502:47: error: forming > reference to void <Graph, value_type, reference, Tag> type; > ^ > /usr/include/boost/graph/detail/adjacency_list.hpp:2504:53: error: forming > reference to void <Graph, value_type, const_reference, Tag> const_type; > ^ > CooperativeGraph.cpp: In member function ?void > CooperativeGraph::getProperties()?: CooperativeGraph.cpp:384:35: error: no > matching function for call to ?get(boost::vertex_index_t, Graph&)? > vertex_index = get(vertex_index,g); > ^ > I defined the data structure as follows > > typedef property<vertex_BatteryLevel_t,int, > property<vertex_ObservationHistory_t,deque<Observation>, > property<vertex_name_t,uuid> > > > vertex_state; > > typedef property<edge_QFunction_t,QTable, > property<edge_Eligibility_t,Eligibility> > > > edge_qfunction; > > typedef adjacency_list< > vecS,setS,directedS, > vertex_state, > edge_qfunction > > > Graph; > > Does anyone know what I am doing wrong? Why can't I get the vertex_index_t > property. Thanks! > > > > ------------------------------ > > Message: 3 > Date: Thu, 23 Jul 2015 14:06:03 +0000 (UTC) > From: Jeremiah Willcock <jewillco(a)yahoo.com> > To: "boost-users(a)lists.boost.org" <boost-users(a)lists.boost.org> > Subject: Re: [Boost-users] problem of getting vertex_index_t property > with BGL > Message-ID: > <983493185.1183146.1437660363876.JavaMail.yahoo(a)mail.yahoo.com> > Content-Type: text/plain; charset=UTF-8 > > >________________________________ > > > > From: breadbread1984 <breadbread1984(a)163.com> > > > >To: boost-users(a)lists.boost.org > >Sent: Thursday, July 23, 2015 4:25 AM > >Subject: [Boost-users] problem of getting vertex_index_t property with BGL > > > > > >I am using boost graph library. I found there is a built in property > >vertex_index_t corresponding to every vertex from the document > >[here](http://www.boost.org/doc/libs/1_58_0/libs/graph/doc/adjacency_list. > >html). But when I get the vertex_index_t property the compiler prompt the > >following error: > > > >CooperativeGraph.h:59:36: required from here > >/usr/include/boost/graph/detail/adjacency_list.hpp:2498:29: error: forming > >reference to void> > > typedef value_type& reference; > > > > ^ > > > >/usr/include/boost/graph/detail/adjacency_list.hpp:2499:35: error: forming > >reference to void> > > typedef const value_type& const_reference; > > > > ^ > > > >/usr/include/boost/graph/detail/adjacency_list.hpp:2502:47: error: forming > >reference to void> > > <Graph, value_type, reference, Tag> type; > > > > ^ > > > >/usr/include/boost/graph/detail/adjacency_list.hpp:2504:53: error: forming > >reference to void> > > <Graph, value_type, const_reference, Tag> const_type; > > > > ^ > > > >CooperativeGraph.cpp: In member function ?void > >CooperativeGraph::getProperties()?: CooperativeGraph.cpp:384:35: error: no > >matching function for call to ?get(boost::vertex_index_t, Graph&)?> > > vertex_index = get(vertex_index,g); > > > > ^ > > > >I defined the data structure as follows > > > >typedef property<vertex_BatteryLevel_t,int, > > > > property<vertex_ObservationHistory_t,deque<Observation>, > > > > property<vertex_name_t,uuid> > >> > >> vertex_state; > > > >typedef property<edge_QFunction_t,QTable, > > > > property<edge_Eligibility_t,Eligibility> > >> > >> edge_qfunction; > > > >typedef adjacency_list< > > > > vecS,setS,directedS, > > vertex_state, > > edge_qfunction > >> > >> Graph; > > > >Does anyone know what I am doing wrong? Why can't I get the vertex_index_t > >property. Thanks! > Your graph type has setS as its vertex container. Try using vecS instead to > get the vertex_index property to be present. > > -- Jeremiah Willcock > > > ------------------------------ > > Message: 4 > Date: Thu, 23 Jul 2015 14:31:51 +0000 > From: "Auer, Jens" <jens.auer(a)cgi.com> > To: "boost-users(a)lists.boost.org" <boost-users(a)lists.boost.org> > Subject: Re: [Boost-users] Boost.DateTime and leap year/leap seconds > Message-ID: > <E47848702ADBE04EA7ECF45E05F60B6DF98E840C(a)SE-EX020.groupinfra.com> > Content-Type: text/plain; charset="utf-8" > > Hi Howard, > > Thank you very much. That basically made my day! > > We have no restrictions on the compiler, currently I'm using gcc 4.9 in > C++-14 mode. I think I can also justify using a time handling library, so > the chances are very good that we will use your library. > > Many thanks and best wishes, > Jens > > -- > Dr. Jens Auer | CGI | Software Engineer > CGI Deutschland Ltd. & Co. KG > Rheinstra?e 95 | 64295 Darmstadt | Germany > T: +49 6151 36860 154 > jens.auer(a)cgi.com > Unsere Pflichtangaben gem?? ? 35a GmbHG / ?? 161, 125a HGB finden Sie unter > de.cgi.com/pflichtangaben. > > CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to > CGI Group Inc. and its affiliates may be contained in this message. If you > are not a recipient indicated or intended in this message (or responsible > for delivery of this message to such person), or you think for any reason > that this message may have been addressed to you in error, you may not use > or copy or deliver this message to anyone else. In such case, you should > destroy this message and are asked to notify the sender by reply e-mail. > > -----Original Message----- > From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of > Howard Hinnant Sent: 22 July 2015 21:29 > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] Boost.DateTime and leap year/leap seconds > > I?ve been following this thread with interest. > > On Jul 22, 2015, at 8:59 AM, Auer, Jens <jens.auer(a)cgi.com> wrote: > > Reading the documentation I think that will not be correct when there were > > leap seconds. > Correct. As Jeff said earlier, leap second support is not in the current > library, but might be a feature in a future boost date-time 2.0. > > If you are using a C++11 or C++14 compiler, there is a library that will > handle this problem with leap seconds taken into account for you: > > http://howardhinnant.github.io/tz.html > > I doubt you can use this library as the space industry equates up-to-date > compilers with increased risk. However I mention it, as it is open source > and perhaps you can crib some of its ideas onto the current boost date-time > library. > > In a nutshell, this C++11/14 library handles leap seconds along the lines of > what Jeff suggested. Though in this case it creates a std::chrono - > compatible clock which is leap second aware: > > class utc_clock > { > public: > using duration = > std::chrono::system_clock::duration; using rep = > duration::rep; > using period = duration::period; > using time_point = > std::chrono::time_point<utc_clock>; static constexpr bool is_steady = true; > > static time_point now() noexcept; > > template <class Duration> > static > std::chrono::time_point<utc_clock, > typename std::common_type<Duration, > std::chrono::seconds>::type> > sys_to_utc(std::chrono::time_point<std::chrono::system_clock, Duration> t); > > template <class Duration> > static > std::chrono::time_point<std::chrono::system_clock, > typename std::common_type<Duration, > std::chrono::seconds>::type> utc_to_sys(std::chrono::time_point<utc_clock, > Duration> t); }; > > and includes conversions to and from std::chrono::system_clock::time_point > (which like boost date-time is based on Unix time). These conversions are > simply lookups into an ordered list of leap second transitions, resulting > in the addition or subtraction of the proper number of leap seconds. > > This could be used like so: > > struct CCSDS > { > std::uint16_t days; > std::uint32_t ms; > std::uint16_t us; > }; > > CCSDS > to_CCSDS(date::year y, std::chrono::microseconds us) > { > using namespace date; > using namespace std::chrono; > auto utc = utc_clock::sys_to_utc(day_point(y/jan/1)) + us; > auto sys = utc_clock::utc_to_sys(utc); > auto dp = floor<days>(sys); > auto d = dp - day_point(1958_y/jan/1); > us = utc - utc_clock::sys_to_utc(dp); > auto ms = duration_cast<milliseconds>(us); > us -= ms; > return {static_cast<std::uint16_t>(d.count()), > static_cast<std::uint32_t>(ms.count()), > static_cast<std::uint16_t>(us.count())}; > } > > The variable utc holds the ?year + us? as a time point with microseconds > precision. This time point counts microseconds, including leap seconds, > since 1970-01-01 00:00:00 UTC. > > The next step is find when the day started that is associated with utc. To > do this one must convert utc back to ?Unix time?, and then truncate that > time point to a precision of days, resulting in the variable dp. dp is a > count of days since 1970-01-01. Since your epoch is 1958-01-01, this is > taken into account in creating ?d?, the first value needed in your return > type. > > Now the number of microseconds since the start of the day needs to be > computed. The start of the day, dp, is converted back into the leap-second > aware system, and subtracted from the microsecond time point: utc. The > variable us is reused to hold ?microseconds since midnight?. Now it is a > simple computation to split this into milliseconds since midnight, and > microseconds since the last millisecond. > > This has all been tested with: > > void > test_to_CCSDS() > { > using namespace std::chrono; > using namespace date; > for (auto d = days{179}; d <= days{181}; ++d) > { > auto start = d + 86399s + 999999us + 0us; > for (auto us = start; us <= start + 3s; us += 1s) > { > auto t = to_CCSDS(2015_y, us); > std::cout << t.days << ' ' << t.ms << ' ' << t.us << '\n'; > } > std::cout << '\n'; > } > } > > which yields: > > 20998 86399999 999 > 20999 999 999 > 20999 1999 999 > 20999 2999 999 > > 20999 86399999 999 > 20999 86400999 999 > 21000 999 999 > 21000 1999 999 > > 21000 86398999 999 > 21000 86399999 999 > 21001 999 999 > 21001 1999 999 > > Interpretation: On 2015-06-29 23:59:59.999999 we are 1us away from the next > day. 1s later we are well into 2015-06-30. > > 24hrs later, we see a different pattern as the leap second is inserted. The > last microsecond of the day is 1s later at 2015-06030 23:59:60.999999. > > 24hrs later we are back to days with only 86400s. > > Assuming you have some conversion data to test against, this will hopefully > match up with those test cases. > > Howard > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users > > ------------------------------ > > End of Boost-users Digest, Vol 4202, Issue 3 > ********************************************

2 1

question about vertex_index_t property of graph
by breadbread1984 24 Jul '15

24 Jul '15

I am using boost graph library. I want to know whether the value of vertex_index_t property is assigned and updated automatically? If I serialize a graph to a file and deserialize it, will the value of vertex_index_t property remain?

2 1

Boost.DateTime and leap year/leap seconds
by Auer, Jens 23 Jul '15

23 Jul '15

Hi, I am considering using Boost.DateTime in one of my projects, and there have been some concerns about handling leap seconds on the customers side. The documentation says that other libraries do not handle leap seconds correctly, but it does not state that Boost.DateTime does. I found only one mail from 2009 on the mailing list asking about leap seconds, but this does not give an answer. Does anybody have some information on this? The computations I intend to do are actually rather limited. I will be given a year and a number microseconds, and have to compute the day in the year that this describes from the start of the year, together with microseconds and milliseconds in the day. So what I want to implement is a function tuple<days, milliseconds, microsends> convertTime(year, microseconds). Best wishes, Jens -- Dr. Jens Auer | CGI | Software Engineer CGI Deutschland Ltd. & Co. KG Rheinstraße 95 | 64295 Darmstadt | Germany T: +49 6151 36860 154 jens.auer(a)cgi.com<mailto:jens.auer@cgi.com> Unsere Pflichtangaben gemäß § 35a GmbHG / §§ 161, 125a HGB finden Sie unter de.cgi.com/pflichtangaben<http://de.cgi.com/pflichtangaben>. CONFIDENTIALITY NOTICE: Proprietary/Confidential information belonging to CGI Group Inc. and its affiliates may be contained in this message. If you are not a recipient indicated or intended in this message (or responsible for delivery of this message to such person), or you think for any reason that this message may have been addressed to you in error, you may not use or copy or deliver this message to anyone else. In such case, you should destroy this message and are asked to notify the sender by reply e-mail.

3 6

problem of getting vertex_index_t property with BGL
by breadbread1984 23 Jul '15

23 Jul '15

I am using boost graph library. I found there is a built in property vertex_index_t corresponding to every vertex from the document [here](http://www.boost.org/doc/libs/1_58_0/libs/graph/doc/adjacency_list.ht…. But when I get the vertex_index_t property the compiler prompt the following error: CooperativeGraph.h:59:36: required from here /usr/include/boost/graph/detail/adjacency_list.hpp:2498:29: error: forming reference to void typedef value_type& reference; ^ /usr/include/boost/graph/detail/adjacency_list.hpp:2499:35: error: forming reference to void typedef const value_type& const_reference; ^ /usr/include/boost/graph/detail/adjacency_list.hpp:2502:47: error: forming reference to void <Graph, value_type, reference, Tag> type; ^ /usr/include/boost/graph/detail/adjacency_list.hpp:2504:53: error: forming reference to void <Graph, value_type, const_reference, Tag> const_type; ^ CooperativeGraph.cpp: In member function ‘void CooperativeGraph::getProperties()’: CooperativeGraph.cpp:384:35: error: no matching function for call to ‘get(boost::vertex_index_t, Graph&)’ vertex_index = get(vertex_index,g); ^ I defined the data structure as follows typedef property<vertex_BatteryLevel_t,int, property<vertex_ObservationHistory_t,deque<Observation>, property<vertex_name_t,uuid> > > vertex_state; typedef property<edge_QFunction_t,QTable, property<edge_Eligibility_t,Eligibility> > edge_qfunction; typedef adjacency_list< vecS,setS,directedS, vertex_state, edge_qfunction > Graph; Does anyone know what I am doing wrong? Why can't I get the vertex_index_t property. Thanks!

2 1

[interval] Power
by Sensei 23 Jul '15

23 Jul '15

Dear all, I am defining a "scalar" type for a project, and this scalar I'd like to be an interval. Among the operations, already provided by boost interval, I need pow(interval, interval). Since there is no pow() function, but log() and exp() are defined, I mistakenly defined power as the obvious: typedef boost::numeric::interval<double> scalar; scalar p(1.0, 1.0), q(4, 100); log << "^ " << boost::numeric::exp(p * boost::numeric::log(q)) << std::endl; Unfortunately, it won't work, and it gives me this error: /usr/local/include/boost/numeric/interval/transc.hpp:47:42: No member named 'log_down' in 'boost::numeric::interval_lib::rounded_math<double>' /usr/local/include/boost/numeric/interval/transc.hpp:34:16: No member named 'exp_down' in 'boost::numeric::interval_lib::rounded_math<double>' Is there any "correct" pow() function I can implement? Is something wrong with the definition of scalar? Thank you!

2 3

Re: [Boost-users] Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel these memory_orders?
by class7class＠163.com 23 Jul '15

23 Jul '15

Your explanation is very detailedand useful, I think I understood. Thank you very much! class7class(a)163.com From: boost-users-request Date: 2015-07-23 09:04 To: boost-users Subject: Boost-users Digest, Vol 4201, Issue 4 Send Boost-users mailing list submissions to boost-users(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost-users or, via email, send a message with subject or body 'help' to boost-users-request(a)lists.boost.org You can reach the person managing the list at boost-users-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost-users digest..." Today's Topics: 1. Re: Boost release 1.59.0 beta 1 is now available from SourceForge (Ben Pope) 2. Re: Boost release 1.59.0 beta 1 is now available from SourceForge (Vicky Vergara) 3. Re: Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel these memory_orders? (Gavin Lambert) 4. [filesystem] problem: is_regular_file and deduplified files (reparse+sparse) (Paul Harris) 5. Re: Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel (Isaac To) ---------------------------------------------------------------------- Message: 1 Date: Thu, 23 Jul 2015 05:20:39 +0800 From: Ben Pope <benpope81(a)gmail.com> To: boost-users(a)lists.boost.org Cc: boost(a)lists.boost.org Subject: Re: [Boost-users] Boost release 1.59.0 beta 1 is now available from SourceForge Message-ID: <mop1f7$6dg$1(a)ger.gmane.org> Content-Type: text/plain; charset=windows-1252; format=flowed On Thursday, July 23, 2015 02:23 AM, Marshall Clow wrote: > On Thu, Jul 16, 2015 at 6:16 AM, Marshall Clow <mclow.lists(a)gmail.com > <mailto:mclow.lists@gmail.com>> wrote: > > > Boost release 1.59.0 beta 1 is now available from SourceForge > See http://sourceforge.net/projects/boost/files/boost/1.59.0.beta.1/ > For details of what's in the release, see > http://www.boost.org/users/history/version_1_59_0.html. > Note that the links to files on this web page are for the final > release - use the SourceForge link above to get the beta files. > Please download the beta, give it a try, and report any problems you > encounter. > > > Has anyone tried the beta release with new compilers? > > Specifically, I'm thinking about: > * GCC 5.2 > * VS2015 > * Clang 3.7rc1 For clang 3.7 rc1, the tests for master are up on the ftp, but they won't be published because I haven't submitted a pull request for them to be published on the test site, since I don't run them regularly. The dev results should be up on the test matrix at some point soon, but the entire run of dev and release takes a couple of days (which feels slow) and is still in progress. I intend to publish the results of asan, msan, tsan runs at some point but I haven't got round to figuring out the right way to present them yet, if you want the raw xml results and don't have access to the ftp, contact me. I'll probably run for gcc 5.2 when it arrives on Ubuntu's launchpad. Ben ------------------------------ Message: 2 Date: Wed, 22 Jul 2015 17:53:17 -0500 From: Vicky Vergara <vicky_vergara(a)hotmail.com> To: "boost-users(a)lists.boost.org" <boost-users(a)lists.boost.org> Subject: Re: [Boost-users] Boost release 1.59.0 beta 1 is now available from SourceForge Message-ID: <BAY177-W30049CC41A57EE28144AA18A830(a)phx.gbl> Content-Type: text/plain; charset="iso-8859-1" We re working on the release of pgRouting. We use Boost.Graph. My Question is: Waht changes I have to do in Github travis to check that pgRouting is compatible with this beta release? Here is our travis file: https://github.com/pgRouting/pgrouting/blob/develop_2_1_0/.travis.yml Right now it runs with boost 1.46.1 https://travis-ci.org/pgRouting/pgrouting/jobs/72064827#L1834 Thanks > To: boost-users(a)lists.boost.org > From: benpope81(a)gmail.com > Date: Thu, 23 Jul 2015 05:20:39 +0800 > CC: boost(a)lists.boost.org > Subject: Re: [Boost-users] Boost release 1.59.0 beta 1 is now available from SourceForge > > On Thursday, July 23, 2015 02:23 AM, Marshall Clow wrote: > > On Thu, Jul 16, 2015 at 6:16 AM, Marshall Clow <mclow.lists(a)gmail.com > > <mailto:mclow.lists@gmail.com>> wrote: > > > > > > Boost release 1.59.0 beta 1 is now available from SourceForge > > See http://sourceforge.net/projects/boost/files/boost/1.59.0.beta.1/ > > For details of what's in the release, see > > http://www.boost.org/users/history/version_1_59_0.html. > > Note that the links to files on this web page are for the final > > release - use the SourceForge link above to get the beta files. > > Please download the beta, give it a try, and report any problems you > > encounter. > > > > > > Has anyone tried the beta release with new compilers? > > > > Specifically, I'm thinking about: > > * GCC 5.2 > > * VS2015 > > * Clang 3.7rc1 > > For clang 3.7 rc1, the tests for master are up on the ftp, but they > won't be published because I haven't submitted a pull request for them > to be published on the test site, since I don't run them regularly. > > The dev results should be up on the test matrix at some point soon, but > the entire run of dev and release takes a couple of days (which feels > slow) and is still in progress. > > I intend to publish the results of asan, msan, tsan runs at some point > but I haven't got round to figuring out the right way to present them > yet, if you want the raw xml results and don't have access to the ftp, > contact me. > > I'll probably run for gcc 5.2 when it arrives on Ubuntu's launchpad. > > Ben > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users -------------- next part -------------- HTML attachment scrubbed and removed ------------------------------ Message: 3 Date: Thu, 23 Jul 2015 12:20:28 +1200 From: Gavin Lambert <gavinl(a)compacsort.com> To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel these memory_orders? Message-ID: <mopc0e$6ph$1(a)ger.gmane.org> Content-Type: text/plain; charset=windows-1252; format=flowed On 22/07/2015 14:43, class7class(a)163.com wrote: > I am a SE and I program based on boost library, I have one question to > ask as below: > > When I use the atomic library included boost , I coded as following: > atomic<bool> flag; //declare the var > flag.store(true,boost::memory_order_acq_rel); // use > store method to change the value of flag > > but BOOST_ASSERT failed,and I read the code of base_atomic<> template > class,I found the the store() method can not support several > memory_orders metioned in the subject , and the other methods can not > support all memory_orders,such as: > 1.the load method can not support memory_order_release and > memory_order_acq_rel > 2. the compare_exchange_strong method can not support > memory_order_release and memory_order_acq_rel > 3. the compare_exchange_weak method can not support > memory_order_release and memory_order_acq_rel > > I really want to know the reason that why the methods of atomic can not > support all memory_orders. Because this is mandated by the standard, and because doing otherwise doesn't really make sense. Loads can't release, and stores can't acquire. Therefore those memory orders are nonsensical. memory_order_acq_rel exists for RMW operations such as compare_exchange. The "acq" applies to the load and the "rel" to the store. It's not sensible for a store alone. > If I need the methods of the atomic<> support all memory_orders,how > can i do? You can re-read the standard memory model and discover why that doesn't make sense. Memory ordering can be tricky to get your head around at first -- it's a good idea to run any atomic algorithm you implement through a sanity checker such as RRD or ThreadSanitizer to help catch subtle bugs. If in doubt, stick with seq_cst memory ordering (the default). On x86/x64 there is very little performance difference between seq_cst and the weaker orders -- cacheline sharing tends to be more problematic. ------------------------------ Message: 4 Date: Thu, 23 Jul 2015 08:56:21 +0800 From: Paul Harris <harris.pc(a)gmail.com> To: boost-users <boost-users(a)lists.boost.org> Subject: [Boost-users] [filesystem] problem: is_regular_file and deduplified files (reparse+sparse) Message-ID: <CAMSUDdZL95bnn3Ec=3pKGkKRdtMk2i7=PL6e7aK6u4J9GBVpZg(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi guys, I'm seeing a lot of failures all of a sudden, its a serious problem. I imagine some of you may start seeing the same failures too very soon. I'm seeing it with boost 1.58.0. There is a related bug already entered here: https://svn.boost.org/trac/boost/ticket/11057 I can't seem to log on and update this ticket. But the problem extends further than that ticket. Windows Server 2003 support has been dropped by Microsoft, and a lot of IT depts around the world are switching over to the latest Windows Server. With this server comes the new "dedup" feature, that can automatically deduplify files. This happens on a schedule, eg 2am saturday. So suddenly we are getting messages of failures of software from all over the place, due to fs::is_regular_file() Deduped files have the REPARSE and SPARSE flag set. On the command line, you can run FSUTIL REPARSEPOINT QUERY and the "Reparse Tag Value" is 0x80000013 Which is a relatively new flag known as IO_REPARSE_TAG_DEDUP https://msdn.microsoft.com/en-us/library/windows/desktop/aa365740%28v=vs.85… These files act as normal files, you can fopen and fread them, so I assume they should be treated almost like symlink by boost... perhaps not quite a symlink because I assume the "lstat" link properties are identical to the file's stat properties. Typically, I iterate over directories and only process files if fs::is_regular_file(filename) is true. I wrote some code to check what the properties were on these files, and its not any of the possible enums detected by file_status::type(). ideas? Best regards, Paul -------------- next part -------------- HTML attachment scrubbed and removed ------------------------------ Message: 5 Date: Thu, 23 Jul 2015 09:04:57 +0800 From: Isaac To <isaac.to(a)gmail.com> To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel Message-ID: <CAOArY3UmCXoCcWPntHo2GufdmAy1mSNceFGUwdoZt4_Kd5D2EA(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" On Thu, Jul 23, 2015 at 12:00 AM, "class7class(a)163.com" <class7class(a)163.com > wrote: > I found the the store() method can not support several memory_orders > metioned in the subject , and the other methods can not support all > memory_orders,such as: > 1.the load method can not support memory_order_release and > memory_order_acq_rel > 2. the compare_exchange_strong method can not support > memory_order_release and memory_order_acq_rel > 3. the compare_exchange_weak method can not support memory_order_release > and memory_order_acq_rel > > I really want to know the reason that why the methods of atomic can not > support all memory_orders. > > If I need the methods of the atomic<> support all memory_orders,how can i > do? > You are asking into the area of C++ where the fewest people in the world understand, namely relaxed atomics. Before I tell my limited understanding of the issue, I have an advice: - Use mutexes like boost::mutex to ensure all your accesses to variables shared among threads are not accessed concurrently, and you'll be fine. If your circumstance forces you to ignore the above advice (like me, e.g., when you cannot afford the scheduling overheads of mutexes), here is yet another advice which may save your life: - Make all your variables that can be accessed concurrently from multiple threads (with at least one thread writing) atomic. (This makes your program "data race free".) - Always use the default memory_order_seq_cst memory ordering for accesses to your atomics, never use anything else. If your circumstance forces you to ignore the above advices (unlike me, I just learn them because I haven't heard about the second advice before; you'll have to be writing for old ARM (i.e., ones without the LDA and STL instructions) or POWER for you to have a real reason to use relaxed atomics, I write for neither), here is what I have learnt. tl;dr The boost atomic doesn't support all memory ordering because the C++11 standard doesn't support all of them. The C++ standard doesn't support all memory ordering because not all make sense in the "memory model" supported by C++. It is not likely to change in the near future, i.e., unless some genius devises some novel memory model which changes the status quo. Here "memory model" means what "loads" from memory is allowed to return. Because of compiler and hardware optimization, writes (including atomic writes) to memory locations may be reordered, so the load doesn't always return "the last value stored". Special hardware instructions are necessary to ensure a particular ordering that the programmer needs. The easiest way to understand a program is that "All memory operations by all threads looks as if they are done one after another, interleaving among threads". But it proves to be too tricky for hardware to provide any reasonable performance for this model. The C++ memory model without relaxed atomics is essentially "All *atomic* memory operations by all threads looks as if they are done one after another, interleaving among threads. All other memory operations of each thread looks as if they are completely done between adjacent atomic memory operations. But the programmer guarantees not to write a data race. The compiler uses this assumption in all its work, and your program can break in all mysterious ways if you break this rule." This is essentially the illusion provided by sequential consistency. Everybody should want it. Except some don't, because in some architectures it is essentially impossible to provide sequential consistency efficiently. To do sequential consistency, one has to ensure that (1) the compiler doesn't reorder the statements written by the programmer, which is controllable by compiler writer; and (2) the hardware doesn't reorder the instructions generated by the compiler, which is damn hard. It usually means the compiler must insert memory fences before and after memory accesses (i.e., tell the CPU "don't return to me until everything I do up to this point are visible by all other CPUs" or "don't return to me until everything other CPUs do up to this point are visible by me"), which is very slow. It is particularly bad because for these architectures, fences must be inserted not just for atomic stores, but for the supposedly fast atomic loads as well. (Recent architectures do better because they link the requirement into the accesses of the particular memory location: the "particular memory location" here limits the scope where the "fences" have to do, and this makes a big difference in performance.) That's why relaxed atomics (i.e., memory_order_acq, etc) exists in the standard. They allow those architectures to perform better than using full sequential consistency in some common cases. Because different architectures require different sort of fences, it doesn't make sense for these to mean "insert a fence after the load". Instead, the C++ standard uses a more programmer centric view when defining relaxed memory ordering: - If a thread X stores a value with release semantics into an atomic variable, and another thread Y loads this value with acquire semantics from that same atomic variable, then everything done by thread X before this releasing store are guaranteed to be visible to thread Y after this acquiring load. There is no other semantics attached to the acquire and release. This is why acquiring stores and releasing loads are meaningless: they are not assigned any semantics. But the deeper reason for the lack is that the computer industry cannot find a way to give additional guarantee without incurring hefty performance overheads. And at the same time, sequentially consistent atomics are not so expensive in the new architectures. As for what to do if you want more than the above release-acquire guarantee: Simple, just use sequentially consistent atomic operations. Regards, Isaac -------------- next part -------------- HTML attachment scrubbed and removed ------------------------------ Subject: Digest Footer _______________________________________________ Boost-users mailing list Boost-users(a)lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users ------------------------------ End of Boost-users Digest, Vol 4201, Issue 4 ********************************************

1 0

Can Boot MultiIndex help me?
by Paolo Bolzoni 23 Jul '15

23 Jul '15

Dear list, I needed a data structure such that: - a list of POD structs (with an Id and other fields) stays in contiguous memory. This is required because I need to pass this block of memory to a C function. - the order of this POD structs is irrelevant. - I need to access to each element from the Id quickly. So I implemented a class using std::map and std::vector; the vector contains the structs and the map associate between the ids and the vector position. The vector ensures C memory layout and the map gives the elements from the Id quickly. To delete an element I copy the last element in its position, update the map, and pop the vector back (of course there are some special cases, like deleting the last element... but you got the point) To add an element I push it back to the vector and update the map. It works fine, but a colleague mentioned that boost multiindex can do a similar job. I checked the documentation, but I am not sure I can build an index on a vector. Is that possible? Thanks. Your faithfully, Paolo

3 2

Re: [Boost-users] Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel
by Isaac To 23 Jul '15

23 Jul '15

On Thu, Jul 23, 2015 at 12:00 AM, "class7class(a)163.com" <class7class(a)163.com > wrote: > I found the the store() method can not support several memory_orders > metioned in the subject , and the other methods can not support all > memory_orders,such as: > 1.the load method can not support memory_order_release and > memory_order_acq_rel > 2. the compare_exchange_strong method can not support > memory_order_release and memory_order_acq_rel > 3. the compare_exchange_weak method can not support memory_order_release > and memory_order_acq_rel > > I really want to know the reason that why the methods of atomic can not > support all memory_orders. > > If I need the methods of the atomic<> support all memory_orders,how can i > do? > You are asking into the area of C++ where the fewest people in the world understand, namely relaxed atomics. Before I tell my limited understanding of the issue, I have an advice: - Use mutexes like boost::mutex to ensure all your accesses to variables shared among threads are not accessed concurrently, and you'll be fine. If your circumstance forces you to ignore the above advice (like me, e.g., when you cannot afford the scheduling overheads of mutexes), here is yet another advice which may save your life: - Make all your variables that can be accessed concurrently from multiple threads (with at least one thread writing) atomic. (This makes your program "data race free".) - Always use the default memory_order_seq_cst memory ordering for accesses to your atomics, never use anything else. If your circumstance forces you to ignore the above advices (unlike me, I just learn them because I haven't heard about the second advice before; you'll have to be writing for old ARM (i.e., ones without the LDA and STL instructions) or POWER for you to have a real reason to use relaxed atomics, I write for neither), here is what I have learnt. tl;dr The boost atomic doesn't support all memory ordering because the C++11 standard doesn't support all of them. The C++ standard doesn't support all memory ordering because not all make sense in the "memory model" supported by C++. It is not likely to change in the near future, i.e., unless some genius devises some novel memory model which changes the status quo. Here "memory model" means what "loads" from memory is allowed to return. Because of compiler and hardware optimization, writes (including atomic writes) to memory locations may be reordered, so the load doesn't always return "the last value stored". Special hardware instructions are necessary to ensure a particular ordering that the programmer needs. The easiest way to understand a program is that "All memory operations by all threads looks as if they are done one after another, interleaving among threads". But it proves to be too tricky for hardware to provide any reasonable performance for this model. The C++ memory model without relaxed atomics is essentially "All *atomic* memory operations by all threads looks as if they are done one after another, interleaving among threads. All other memory operations of each thread looks as if they are completely done between adjacent atomic memory operations. But the programmer guarantees not to write a data race. The compiler uses this assumption in all its work, and your program can break in all mysterious ways if you break this rule." This is essentially the illusion provided by sequential consistency. Everybody should want it. Except some don't, because in some architectures it is essentially impossible to provide sequential consistency efficiently. To do sequential consistency, one has to ensure that (1) the compiler doesn't reorder the statements written by the programmer, which is controllable by compiler writer; and (2) the hardware doesn't reorder the instructions generated by the compiler, which is damn hard. It usually means the compiler must insert memory fences before and after memory accesses (i.e., tell the CPU "don't return to me until everything I do up to this point are visible by all other CPUs" or "don't return to me until everything other CPUs do up to this point are visible by me"), which is very slow. It is particularly bad because for these architectures, fences must be inserted not just for atomic stores, but for the supposedly fast atomic loads as well. (Recent architectures do better because they link the requirement into the accesses of the particular memory location: the "particular memory location" here limits the scope where the "fences" have to do, and this makes a big difference in performance.) That's why relaxed atomics (i.e., memory_order_acq, etc) exists in the standard. They allow those architectures to perform better than using full sequential consistency in some common cases. Because different architectures require different sort of fences, it doesn't make sense for these to mean "insert a fence after the load". Instead, the C++ standard uses a more programmer centric view when defining relaxed memory ordering: - If a thread X stores a value with release semantics into an atomic variable, and another thread Y loads this value with acquire semantics from that same atomic variable, then everything done by thread X before this releasing store are guaranteed to be visible to thread Y after this acquiring load. There is no other semantics attached to the acquire and release. This is why acquiring stores and releasing loads are meaningless: they are not assigned any semantics. But the deeper reason for the lack is that the computer industry cannot find a way to give additional guarantee without incurring hefty performance overheads. And at the same time, sequentially consistent atomics are not so expensive in the new architectures. As for what to do if you want more than the above release-acquire guarantee: Simple, just use sequentially consistent atomic operations. Regards, Isaac

1 0

Subject:[atomic] why atomic<>::store method can not support memory_order_consum memory_order_acquire and memory_order_acq_rel these memory_orders?
by class7class＠163.com 23 Jul '15

23 Jul '15

Hello ! I am a SE and I program based on boost library, I have one question to ask as below: When I use the atomic library included boost , I coded as following: atomic<bool> flag; //declare the var flag.store(true,boost::memory_order_acq_rel); // use store method to change the value of flag but BOOST_ASSERT failed,and I read the code of base_atomic<> template class,I found the the store() method can not support several memory_orders metioned in the subject , and the other methods can not support all memory_orders,such as: 1.the load method can not support memory_order_release and memory_order_acq_rel 2. the compare_exchange_strong method can not support memory_order_release and memory_order_acq_rel 3. the compare_exchange_weak method can not support memory_order_release and memory_order_acq_rel I really want to know the reason that why the methods of atomic can not support all memory_orders. If I need the methods of the atomic<> support all memory_orders,how can i do? thank you very much! class7class(a)163.com

2 1

[Graph] Warning with boost 1.54, but not with 1.46.1 or 1.55
by Vicky Vergara 22 Jul '15

22 Jul '15

I have, with this code: 100: graph_traits<graph_t>::edge_iterator ei, eend; 101: for (tie(ei, eend) = boost::edges(graph); ei != eend; ei++) { I know this is not a major problem, as for the final release I will remove the -Wall flag from the compilation But then my question is why is the difference? Using boost 1.54 under Ubuntu 14.04 this warning shows on line 100 about variable ei /home/woodbri/work/pgrouting/src/apsp_johnson/src/apsp_johnson_boost_wrapper.cpp:100:40: warning: '*((void*)(& ei)+32).__gnu_cxx::__normal_iterator<boost::detail::stored_edge_property<long unsigned int, Edge>*, std::vector<boost::detail::stored_edge_property<long unsigned int, Edge>, std::allocator<boost::detail::stored_edge_property<long unsigned int, Edge> > > >:: _M_current' may be used uninitialized in this function [-Wmaybe-uninitialized] graph_traits<graph_t>::edge_iterator ei, eend; the complete code can be found : https://github.com/pgRouting/pgrouting/blob/develop/src/apsp_johnson/src/ap… in the cmake the compiler flags are set like this: set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fPIC -O2 -g -Wall -std=c++0x -frounding-math -Wno-deprecated") Complete setup can be found: https://github.com/pgRouting/pgrouting/blob/develop_2_1_0/CMakeLists.txt#L2… This is a test that has boost 1.46.1, no warning shows I also don't get a warning with boost 1.55 https://travis-ci.org/pgRouting/pgrouting/jobs/72064827#L1834 The complete conversation of the problem can be found here: https://github.com/pgRouting/pgrouting/issues/373#issuecomment-123749888

1 0