November 2011 - Boost - lists.preview.boost.org

Proposed Boost.Algorithms Review Ends
by Dave Abrahams 28 Nov '11

28 Nov '11

The review of Marshall Clow's proposed Boost.Algorithms submission officially ended yesterday, but if you get your review in before the end of the weekend, as review manager I'll probably consider it. So far we've had five votes, which is reasonable for something of this scale. Thanks everybody for your time and interest. I'll be posting the review results next week. Regards, Dave -- Dave Abrahams BoostPro Computing http://www.boostpro.com

2 3

[msm] guard behavior if guard guards the transition MSM threats event as handled is that correct?
by Michael.Herchel＠rohde-schwarz.com 28 Nov '11

28 Nov '11

Hi Christophe, Regarding our compile-time problem in the past and therefore, the changes Richard made: Would it be also feasible to develop an additional backend that is derived from the MSM one, but only implements the process_event() method for each event and not in a generic template-based way? With this approach we could still use MSM out-of-box and not having the need for internal transition tables or having references from inner to outer state machines etc but still gain small compiler units. I understand that we will loose flexibility and creating new state machines becomes more work, but I think we could live with that. What is your opinion? Am I thinking too short? Thanks, Michael

2 1

Fwd: [msm] guard behavior if guard guards the transition MSM threats event as handled is that correct ?
by Richard Szabo 28 Nov '11

28 Nov '11

Hi Christophe the attached example I think shows 2 problems. 1st is that the deferral of event3 is not happening. 2nd is that the no_transition function is never called. the output of the run is : MS1 Entering State: Idle by: event1 MS1 Leaving State: Idle by: event1 MS1 Entering State: SubRunning by: event1 FwdGuard: returns:1, event: event2 Processing BaseEvent Instance(event2) Setting guard false FwdGuard: returns:0, event: event3 FwdGuard: returns:0, event: event4 FwdGuard: returns:0, event: event5 MS1 Leaving State: SubRunning by: event5 MS1 Entering State: AfterSub by: event5 I think it shall be : MS1 Entering State: Idle by: event1 MS1 Leaving State: Idle by: event1 MS1 Entering State: SubRunning by: event1 FwdGuard: returns:1, event: event2 Processing BaseEvent Instance(event2) Setting guard false FwdGuard: returns:0, event: event3 FwdGuard: returns:0, event: event4 MS1 no_transition event (event4) MS1 Leaving State: SubRunning by: event5 MS1 Entering State: AfterSub by: event5 MS1 no_transition event (event3) So in this example event3 and event4 are never triggered a transition ... the Row < SubRunning , baseEvent , none , ProcessBaseEvent , FwdGuard > was guarded by the FwdGuard for these events. Is my expected behavior wrong ? If guard is executed but the transition actually is triggered because it is guarded out why this event treated as handled event ?. This 2 problems breaks my current nested state machine implementation because I'm using no_transition to forward the event to the outer state machine. I'm confused :(. Cheers Richie

2 6

[spirit] missing boost/endian/integers.hpp
by Jürgen Hunold 28 Nov '11

28 Nov '11

Hi, after the version number bump to 1.49.0 my builds fail with src/devel/boost/boost/spirit/home/support/detail/endian.hpp:24:37: fatal error: boost/endian/integers.hpp: No such file or directory It seems that spirit want to use Boost.Endian from 1.49 which is not merged to trunk yet. Patch attached, ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

2 1

[preprocessor] Get last token
by Roman Perepelitsa 28 Nov '11

28 Nov '11

Is it possible to extract the last token from a list of space separated tokens? LAST_TOKEN(a b) // expands to b LAST_TOKEN(blah blah b) // expands to b LAST_TOKEN(* & b) // expands to b Roman Perepelitsa.

2 4

Re: [boost] [Boost-commit] svn:boost r75690 - trunk/tools/build/v2/tools
by Steven Watanabe 27 Nov '11

27 Nov '11

AMDG On 11/27/2011 04:50 AM, bdawes(a)acm.org wrote: > Author: bemandawes > Date: 2011-11-27 07:50:00 EST (Sun, 27 Nov 2011) > New Revision: 75690 > URL: http://svn.boost.org/trac/boost/changeset/75690 > > Log: > Change deprecated /Op option to its replacement, /fp:precise. This quiets a warning from the Intel compiler, which uses the msvc toolset. > Did you miss my reply on boost-build? Please revert this. It's wrong. > On 11/26/2011 06:03 AM, Beman Dawes wrote: >> > The patch below clears a warning from Intel 12.1, and works fine for >> > MSVC 8, 9, and 10. >> > >> > Unless someone objects, I'll apply it tomorrow. I'm posting advance >> > notice in case any of the math folks want to give it a try beforehand. >> > > I object. This branch is for msvc 6 and 7, which > only have /Op. /fp:precise is for msvc 8 and > up. The real problem is that intel-win is assuming > vc7.1 compatibility. > > Text files modified: > trunk/tools/build/v2/tools/msvc.jam | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > Modified: trunk/tools/build/v2/tools/msvc.jam > ============================================================================== > --- trunk/tools/build/v2/tools/msvc.jam (original) > +++ trunk/tools/build/v2/tools/msvc.jam 2011-11-27 07:50:00 EST (Sun, 27 Nov 2011) > @@ -240,7 +240,7 @@ > > # Improve floating-point accuracy. Otherwise, some of C++ Boost's "math" > # tests will fail. > - toolset.flags $(toolset).compile CFLAGS $(conditions) : /Op ; > + toolset.flags $(toolset).compile CFLAGS $(conditions) : /fp:precise ; > > # 7.1 and below have single-threaded static RTL. > toolset.flags $(toolset).compile CFLAGS $(conditions)/<runtime-debugging>off/<runtime-link>static/<threading>single : /ML ; > _______________________________________________ > Boost-commit mailing list > Boost-commit(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-commit >

2 1

[local] Any "active Boost library author" in favor of Boost.Local?
by Lorenzo Caminiti 26 Nov '11

26 Nov '11

Hello all, I will be honest: The fact that some of the people arguing for not including Boost.Local are "active Boost library authors" (Thomas, Joel, and Hartmut) seems to make their opinion weight more than the opinion of others that have also submitted a review for the library. Two questions: 1) Should reviews from "active Boost library authors" carry more weight? (This is /not/ a rhetoric question.) 2) Is there any "active Boost library author" out there that is in favor of including Boost.Local? (If so, please say so by replying to this thread.) Thanks a lot :) --Lorenzo

8 18

Re: [boost] New libraries implementing C++11 features in C++03
by Brent Spillner 25 Nov '11

25 Nov '11

On 24 Nov 2011 20:19:17 Joel de Guzman wrote: >The funny thing is that the new feature came from Spirit, not >Phoenix. Phoenix API has been stable for many years now. Triple >sheesh for ya! :-) Then why did V3 require a review earlier this year? Phoenix is great if you want things that are easy in a functional programming language to seem easy in C++, but it does have a learning curve. Local requires a little more typing for short snippets, but is probably far less intimidating, and has far fewer potential "gotchas", for the typical user. I don't think the two are competing with each other at all--- Phoenix provides a far richer set of building blocks for those who want them, and Local offers a stable interface, trivial execution model, and straightforward error messages for those who simply want to use a local function here and there. For a non-guru who just wants to reduce code duplication or port something from Delphi, Local is in many cases the more appealing choice.

2 2

Re: [boost] [local] Any "active Boost library author" in favor of Boost.Local?
by Andrzej Krzemienski 25 Nov '11

25 Nov '11

> Hello all, > I will be honest: The fact that some of the people arguing for not > including Boost.Local are "active Boost library authors" (Thomas, > Joel, and Hartmut) seems to make their opinion weight more than the > opinion of others that have also submitted a review for the library. > Two questions: > 1) Should reviews from "active Boost library authors" carry more > weight? (This is /not/ a rhetoric question.) Hi Lorenzo. I am /not/ an active Boost library author or maintainer. I will only address the first question. I was asking myself the same question recently, and my answer to it is that their opinions should weigh more than others'. Well, "others" is an ambiguous term; I meant someone like me, who is just a Boost user, and says "I want to have this, and this, and that one". My argument is that Boost as an organization has its goals or status, or spirit (no pun intended). I tried to look for something like "what is our goal" on the Boost site, but I did not find a satisfactory answer. The only thing that I found useful is a section in Scott Meyers's "Effective STL". I am not sure if Boost developers will agree, but he says that Boost was founded in part by people who submitted proposals for Standard Library to the C++ committee that were rejected. Boost was supposed to be the place where these libraries were still to be developed, maintained and widely used, which would give them the grater chance to succeed in the next round of standardization. On the other hand, some existing Boost libraries do not appear (at least in my limited view) to meet this criterion (as well as other criteria mentioned recently). I am thinking about the unit testing framework. Do not get me wrong I am not trying to imply that it shouldn't be there, and in fact this is my preferred unit testing framework for many valid reasons. But I was trying to apply the recently risen acceptance criteria to all Boost libraries that I know, and this example appeared the most interesting. Even though it provides a non-macro alternative it encourages using macros for nearly everything in the "automated version": tests, checks, suites, modules. Even thought there are other free libraries for C++ that are known to provide almost the same functionality without a single macro: http://tut-framework.sourceforge.net/. It does not look like a potential candidate for the inclusion into the standard; there are many unit-testing frameworks out there that do not appear to be any worse. It does not appear to encourage some good coding style (apart from the fact that having good unit tests is a good development style).... Given this lack of clear criteria, active Boost library authors and maintainers should be in the better position to assess if the tacit criteria for library admission are met. Some of them have been with boost since its inception (almost 15 years now). If we think otherwise, we are risking the situation where Boost users that just want some library "in the Boost package" will outnumber the few library developers that have a broader goal in mind, and may not even have time to submit a review because they are busy maintaining their libraries or submitting proposals to ISO Committee. I guess that in case of Boost.Local review, this argument would be stronger if the "active Boost library author" reviewers were not the authors of libraries that /somehow/ overlap with Boost.Local. Thus I believe you are bringing the valid point in trying to engage other Boost library authors, and it would be beneficial, also to the entire Boost community, if someone responded to your question. Regards, &rzej

1 0

Formal Review Schedule Queue
by Ben Robinson 25 Nov '11

25 Nov '11

Currently, there are eight library submissions in the queue, none of which have a review manager or a scheduled review period. What is the process to assign review managers? I realize that the Boost.Local review is still in progress (and quite a lively discussion). :) Ben Robinson, Ph.D.

2 1