- Boost - lists.preview.boost.org

[msm] history pseudo states
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, >>"To be frank, History is not a completely satisfying concept. First >>of all, there can be just one history pseudostate and only one >>transition may originate from it." >I'll not contend with the views of history yet. They can be a very >powerful concept. What I'm unclear about is the statement that >there can be just one. According to the UML specification there >can be just one per composite state. That of course makes perfect >sense. MSM has SubmachineStates instead of composite states; however, >the same "rule" applies to both. >Does MSM obey this definition or is there a further constraint? >My confusion might be partially attributed to not having finished >reading all of the docs. Sorry for the confusion which I created. Let me try to correct it. Yes of course, I meant one per composite state. And no it doesn't make perfect sense (at least for me) so there'll be a small constraint: History is not a pseudo state for MSM. I find the concept in UML highly dissatisfying. It simply doesn't fit well with orthogonal regions. What if I want to "remember" more than one region? With UML, you're out of luck: one history per composite, one transition originating from it. Want more? Sorry we can't help you. And with deep history, it is even worse. You don't even see for what region of the subcomposite it applies. And I don't see how adding a "*" is supposed to help. So MSM replaced this unfinished and unsatisfying concept with a policy. This allows you much better history configuration and easy deep history. I hope I managed to correct the created confusion. Christophe

2 1

Two FSM libraries, one interface
by Christophe Henry 07 Dec '09

07 Dec '09

Hi David, >Anyway, I just got tired of being a grumpy old passive man, so decided to put some of my money >(or time) where my mouth is. I will write more about this side effect of my analysis in a blog post later I find it great and worth of respect that you spent time making a useful contribution to the discussion by going the extra mile (or even 2-3) to present your point. While I am by no mean a friend of the preprocessor, I find your solution interesting and encourage you to push it a bit further by supporting at least guards. If you allow a few comments: - I suggest you to give the action a name because you won't always manage to name an action actState1EventState2, for example with 2 transitions with the same source and target. - this would also remove the need for direct code writing, which could break the preprocessor - What about adding some entry/exit? I'm sure you manage to pack this one too. Otherwise I find the idea surprising but fun and think that it could gain being pushed a bit further. If you do, you could even tempt me to reuse it in an eUML front-end ;-) Christophe

2 1

[msm] internal/external conflicting transitions
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, Looks like you are thoroughly testing MSM and I find it great :) >The docs have a section on "Conflicting Transitions". It has >two conflicts described: > >1. an event enables multiple transitions because > multiple guards test valid, > >2. an internal and external transition are both enabled > >I see a clear definition for the behavior of #1 in the >discussion; however, it is not clear that #2 will follow >the same rule. I was maybe unclear with "internal" so let's see if we can converge. With internal, I mean internal to a composite. Suppose we have a fsm named Top containing a state State and a composite Sub. Top has a transition on Event from Sub to State. Sub has 2 states, SubState1 and SubState2 and a transition on Event from SubState2 to SubState1. If the fsm is in the state Sub::SubState2 and Event is detected, we now have a conflict between Sub->State and SubState2->SubState1. UML defines this as a conflict and orders that SubState2->SubState1 wins. It also surprised me a bit until I implemented exit points, which are in themselves a conflict (they are defined as a connection between a transition inside a composite and one outside, triggered by the same event). So, if SubState1 were an exit point, it would still work. >It was actually a little surprising to me that the order <of the transition definitions affected #2. (Well, maybe >not surprising ... but not what I wanted). I used >the SimpleTutorial to test the behavior with: > > a_row < Stopped , play , Stopped , &p::test_conflict >, > a_row < Stopped , play , Playing , &p::start_playback >, > a_row < Stopped , open_close , Open , &p::open_drawer >, > >and > > a_row < Stopped , play , Playing , &p::start_playback >, > a_row < Stopped , play , Stopped , &p::test_conflict >, > a_row < Stopped , open_close , Open , &p::open_drawer >, > > >The last transition defined "wins" in a conflict. This is were I'm unsure if I follow you. SimpleTutorial has no composite, so no internal transition so we must be talking about different things. I can, however, still answer about the order of evaluation. UML orders that conflicts be solved by guards which are mutually exclusive, so your machine is currently ill-formed (no guards) and UML says the behavior is undefined and I, as implementer, am allowed to punish you like I wish ;-) Seriously, if you have guards and they are mutually exclusive, your machine is correct and all will work as expected, no matter the order of evaluation. If you still want to know how it works, with pleasure (this is where normal users could stop reading ;-) ). First, for every event used inside a composite, MSM adds a forwarding row at the end of your table (at the end, so they have no influence on the state index calculation system). Then, for a given event, MSM iterates at compile-time through the STT, from back to front and replaces the conflicts by a new row containing all of the conflicts (this is were your compiler suffers). Thus, transitions internal to a composite are given higher priority in the evaluation. This also means that for "normal" conflicts, the last transition wins. I was already asked if I would change it. It is implementation-specific so you should not rely on it, but it is very unlikely that I will ever want to change it. I hope I brought enough elements to bring clarity. If not, please let me know. Christophe

2 1

Re: [boost] Meta State Machine (MSM) review
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Robert, >I wonder if the library can provide a debugging mode that would provide a helpful default implementation >of no_transition that could help identify the unknown transition rather than requiring the user to write something? >Such a function might access internal details, perhaps only provided in the said debugging mode, >that would be clearer about the source state and event for which no transition was provided than would user-level code. Right now you only get an assert in debug mode. I also wonder if more would be possible. About the event, sure, it is already done, about the source state, I can't promise anything, but I will have a look at it. If I understand correctly, you would be satisfied with an assert or error message bringing a bit more debug information? Christophe

2 1

Interprocess regexes
by Mike Spertus 07 Dec '09

07 Dec '09

I would like to store regexes in shared memory, but it seems like Boost regex falls just barely short of supporting this. In the basic_regex documentation, it says "The definition of basic_regex... is based very closely on class basic_string and fulfils the requirements for a constant-container of charT." This may be technically correct, however basic_string and other containers take an allocator template argument, while basic_regex does not. If basic_regex had an allocator it would reap all the same benefits that other string and container types do. In particular, it would be possible to use boost::interprocess to place them in shared memory. Since the allocator would be defaulted to allocator<charT>, I think it would IMO be compatible with the vast majority of existing code (not quite all because template<class charT, class traits> void f(basic_regex<charT, traits>) wouldn't work). Does this make sense? Do others agree that it would make regexes more like other strings and containers as advertised? Thanks, Mike

7 16

Re: [boost] [msm] Review
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Franz, > SC 19.63630 s > Rhapsody 4.95109 s > MSM 0.90754 s Thanks for the review and for the very interesting comparison with Rhapsody, which I found impressive for several reasons: - Rhapsody is, I think, a pretty costly tool (I heard 15k€) so I expected some cool fsm framework and instead the event dispatching really is just a simple switch on states of if/else on event ids, so a pretty basic implementation (though it would be interesting to see how more complicated machines are generated). Of course, as it is made for embedded development, this is understandable. - although this is such basic C-like implementation, Msm is 5 times faster. This is fascinating, the rootState_processEvent is so simple, one can wonder how it is possible to be faster. I find this a good example of the power of metaprogramming. I love C++ :) Thanks, Christophe

17 47

[msm] choice (point) pseudo state
by Christophe Henry 07 Dec '09

07 Dec '09

Hi Michael, >I do not see the concept of a choice point. Did >I miss it? It looks like it can be modeled with >a state having only anonymous transitions and >appropriate guards. Correct, there is currently no choice point as it can be easily emulated and I'm still scratching my head about what to do with it. I'm actually unsure whether and how it should be implemented. It'd be a normal state with an incoming anonymous transition (as you mentioned) and several guards. Even the "else" is optional. So I admit I'm a bit confused if I should simply provide a typedef or if something makes it different from a state. That's the reason why it's not implemented yet. If you or anybody else sees a good use for it and why it's more than a normal state, I'd be quite thankful and could implement it. Christophe

1 0

GGL review (JTF)
by Jonathan Franklin 07 Dec '09

07 Dec '09

=== What is your evaluation of the design? === The design seems to adequately capture important geometric concepts, such as dimensionality and coordinate systems, as well as numerical precision, etc. The 4-type overload for assign (center + radius for a sphere) deviates from the semantics of the 2-/3-arg versions, which I dislike. I have not reviewed any of the extensions, so perhaps there is a good reason doing this... Other than the fact that more people will probably use center+radius than 4-d polygons. Then again, assign is parameterized by the geometry type, so this is probably just an omission. Issues w/ units continue to nag at the back of my mind. However, specifying units for specific geometries (e.g. radians), and requiring consistency of units within a given geometry seems appropriate. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. I *think* we are okay here, but have not put sufficient effort to make that call (because I don't need it). === What is your evaluation of the implementation? === I didn't have time to review the implementation, other than general poking-around in the code. I was happy to note that some of the functionality already works for k-dimensional euclidean geometries, even though it is technically not supported at the moment. And by k-dimensional, I mean k=4. :-) I didn't have time to push the limits. === What is your evaluation of the documentation? === In a nutshell, the documentation is inadequate, and IMO must be completed prior to release. I'm not sure whether it is best to require a mini-review, or some other process. A few anecdotes that illustrate the problem: The example code on the main page didn't compile, which isn't a problem in and of itself. However, it took an inspection of random code in the separate Examples section, and inductive reasoning to determine that I needed some additional includes beyond ggl.hpp to make the snippets work. I suggest a direct link to a working example program anywhere example code snippets are provided. I also had a bit of difficulty getting several algorithms to work, like union/intersection. The concepts were decently documented, however, translating the concepts to working code took some leg-work. The doxygen documentation seems incomplete. I expected a tab for functions, like union_inserter, but was only able to drill down to the functions by looking at the header docs. An algorithms page seems apropos. However, I couldn't find a page listing the available algorithms. I arrived at the union_inserter page via the doxygen-generated union.hpp header page. Average and worst case performance, as well as any known/suspected numerical issues or other bugs (such as the non-minimal result returned by union_inserter) IMO *must* be listed in the docs for each algorithm. This is the trade-off for not providing a 100% robustness guarantee. Even then, the pre/post conditions for algorithms must be specified, which seemed to be lacking from the docs. A note (personal opinion) regarding Doxygen documentation: Doxygen is best suited for a reference manual. For a User's/Programmer's guide, not so much. === What is your evaluation of the potential usefulness of the library? === This is a generally useful library across *many* domains. In particular, I am excited to make use of this library at work in our graphics/visualization infrastructure code, as well as our actual GIS features. In my academic research, I plan to make use of this library in statistical machine learning/data mining algorithms. However, it is a shame that the library lacks a first-class spatial index capability in it's present state (e.g. what is up for review). Even a relatively naive reference implementation using an R-tree would be useful to me. === Did you try to use the library? === Yup. * With what compiler? g++ (Ubuntu 4.4.1-4ubuntu8) 4.4.1 * Did you have any problems? The internal headers #include <ggl/blah.hpp>, which requires a -I<BOOST_ROOT>/boost directive, in addition to the usual -I required to find the boost headers. This needs to be fixed prior to release, such that only -I<BOOST_ROOT> is required. I am assuming that this is broken for the same reason that Barends chose not to put ggl in the boost namespace. Other than having to use the 'find' command to locate the appropriate headers for inclusion, and other documentation-related issues listed elsewhere in this review, I didn't experience much difficulty using the library. === How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? === On average, a couple hours a day, over the course of a week. Admittedly, I squandered too many hours justifying my own use case on the ML, which may have been better spent reviewing the implementation, and/or writing useful test cases. === Are you knowledgeable about the problem domain? === I have been a casual user (and occasional developer) of Computational Geometry and GIS algorithms at my current job for ~ 4 years. I have also taken a few (recent) graduate-level C.G. and numerical analysis courses. === Miscellany === The existing GGL mailing list(s) should probably be moved to boost/boost-users, and/or a boost-ggl list. Unless there is a compelling reason to maintain an external list (i.e. paid support, etc) , this will best serve the GGL users/developers. === Do you think the library should be accepted as a Boost library? === Yes, contingent on meeting a minimum level of documentation, as determined by the review manager and/or community. Thanks for putting so much work into this library! Jon

5 7

[Review] GGL review starts today, November 5th
by Hartmut Kaiser 07 Dec '09

07 Dec '09

Hi all, The formal review of the Generic Geometry Library (GGL) starts today, November 5, 2009 and will finish November 15, 2009. GGL is being developed by Barend Gehrels, Bruno Lalande and Mateusz Loskot, with substantial input from this Boost mailing list. ------------------------------------------------ About the library: GGL defines concepts for geometries and implements some algorithms on such geometries. GGL is header-only, and can be applied in all software where geometry plays a small or a larger role. Users of the library can use just only one function, such as distance: int a[2] = {1,1}; int b[2] = {2,3}; double d = ggl::distance(a, b); Library users can also use the library in combination with std::vector, boost::tuple's and boost::ranges, such as: std::vector<boost::tuple<double, double, double> > line; line.push_back(boost::make_tuple(1, 2, 3)); line.push_back(boost::make_tuple(4, 5, 6)); line.push_back(boost::make_tuple(7, 8, 9)); double length = ggl::length(line); GGL can also be used in combination with custom or legacy geometries, adapting them to the library specializing traits classes or using registration macro's. Formally, GGL contains a dimension-agnostic, coordinate-system-agnostic and scalable kernel, based on concepts, meta-functions and tag-dispatching. On top of that kernel, algorithms are built: area, length, perimeter, centroid, convex hull, intersection (clipping), within (point in polygon), distance, envelope (bounding box), simplify, transform, convert, and more. The library is also designed to support high precision arithmetic numbers, such as GMP. The GGL might be used in all domains where geometry plays a role: mapping and GIS, gaming, computer graphics and widgets, robotics, astronomy... The core is designed to be as generic as possible and support those domains. However, for now the development has been mostly GIS-oriented. The GGL team proposes an extension model, very similar to what is used by GIL. The proposal as it is in the Boost Sandbox included three extensions: - SVG because it is used in the samples and to generate the documentation - WKT because it is used in the tests - The geographic coordinate system because it is used in some of the examples, also showing how other coordinate systems can be implemented There are more extensions, not included now, a.o.: - Spatial index - Map projections The proposed GGL has seen four previews, many discussions and many changes in design and implementation, based on those discussions. Previews were published on this list January '08, March'08, October'08 and February'09. GGL can be found in the sandbox https://svn.boost.org/svn/boost/sandbox/ggl/formal_review, including source code, examples, unit tests and documentation. Documentation can also be found online: http://geometrylibrary.geodan.nl/formal_review ------------------------------------------------------- Everybody on this list is invited to participate in this formal review. I hope to see your review of this library, including your vote, and I welcome your participation in the discussions on the Boost mailing list. Please always state in your review, whether you think the library should be accepted as a Boost library. Additionally, please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager ------------------- Meet me at BoostCon http://boostcon.com

20 78

[msm] internal/external conflicting transitions
by Michael Caisse 07 Dec '09

07 Dec '09

Christophe - The docs have a section on "Conflicting Transitions". It has two conflicts described: 1. an event enables multiple transitions because multiple guards test valid, 2. an internal and external transition are both enabled I see a clear definition for the behavior of #1 in the discussion; however, it is not clear that #2 will follow the same rule. It was actually a little surprising to me that the order of the transition definitions affected #2. (Well, maybe not surprising ... but not what I wanted). I used the SimpleTutorial to test the behavior with: a_row < Stopped , play , Stopped , &p::test_conflict >, a_row < Stopped , play , Playing , &p::start_playback >, a_row < Stopped , open_close , Open , &p::open_drawer >, and a_row < Stopped , play , Playing , &p::start_playback >, a_row < Stopped , play , Stopped , &p::test_conflict >, a_row < Stopped , open_close , Open , &p::open_drawer >, The last transition defined "wins" in a conflict. I believe that there is strong historical precedent that internal transitions are always considered before external transitions. I suspect that if this is the behavior that I desire then I can order the transitions so that internals are listed last. Perhaps some additional clarification for case #2 in the docs would be helpful. Thanks - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[msm] choice (point) pseudo state
by Michael Caisse 07 Dec '09

07 Dec '09

Christophe - I am modifying my code generator to target MSM so that I can evaluate some larger machines and run existing test suites that I use. I do not see the concept of a choice point. Did I miss it? It looks like it can be modeled with a state having only anonymous transitions and appropriate guards. michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[msm] history pseudo states
by Michael Caisse 07 Dec '09

07 Dec '09

Hello Christophe - I am trying to understand your implementation of history. In the MSM documentation it states: "As explained in the BoostCon09 paper <cid:part1.00040908.05020506@objectmodelingdesigns.com>, Histories are weird. First, there can be just one." In the boostcon09 paper it also states [page 5]: "To be frank, History is not a completely satisfying concept. First of all, there can be just one history pseudostate and only one transition may originate from it." I'll not contend with the views of history yet. They can be a very powerful concept. What I'm unclear about is the statement that there can be just one. According to the UML specification there can be just one per composite state. That of course makes perfect sense. MSM has SubmachineStates instead of composite states; however, the same "rule" applies to both. Does MSM obey this definition or is there a further constraint? My confusion might be partially attributed to not having finished reading all of the docs. Thanks - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

[msm] eUML guard/action location
by Michael Caisse 07 Dec '09

07 Dec '09

Christophe - Just a quick question about eUML syntax. I think the concept is great. The placement of the guard and actions doesn't strike me as natural. CurrentState() + cool_event() = DestState() [Guard()]/(action()) There are a couple of reasons for this. One is the conceptual ordering of how the UML machine works. 1. In CurrentState 2. Receive cool_event 3. Check for transitions matching cool_event 4. Found match 5. Verify guards 6. Guards pass 7. Handle CurrentState exit action 8. Take transition and handle transition action 9. Handle DestState entry action 10. Reside in DestState Another reason that I find it unnatural is that the event/guard/action is associated (in my mind) first with the transition leaving the CurrentState. The transition obviously is associated with the DestState but the event/guard portions "occur" while in the CurrentState. UML already (via its notation) pulls together the event and action. What do you think about this instead? CurrentState() + cool_event()[Guard()]/(action()) = DestState() I think it more closely matches the UML syntax. Best regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

1 0

Two FSM libraries, one interface
by David Bergman 07 Dec '09

07 Dec '09

NO, this is not yet another attempt of mine to irritate people by claiming that the interfaces of Statechart and MSM are similar ;-) When evaluating MSM, both from an interface and performance (read "abuse" ;-)) point of view, I decided to create a common wrapper for both libraries, since I host this awkward notion that the mapping from such a (much more abstract and less verbose) wrapper to the underlying libraries should not vary that much. Be that due to the interfacial commonalities between the two libraries or my great mapping skills :-) Anyway, I just got tired of being a grumpy old passive man, so decided to put some of my money (or time) where my mouth is. I will write more about this side effect of my analysis in a blog post later, as well as provide access to the actual header file. I just want to gauge the interest for such an abstraction layer *for non-complex FSM needs*. I do not claim any commutation, but at least we have a decent sub diagram with arrows from my abstract interface to each one of Statechart and MSM for non-complex cases. I currently imaginatively call this common interface "abstract_fsm.h". It preprocesses a common description to either Statechart or MSM, decided by setting either "USE_SC" or "USE_MSM". It is currently limited to non-nested machines without guards, and only handles the specification, not execution. But, the end result is pretty cool. So, hold on to you LISP hats (there will be parentheses...) and see for yourself. This is a simple FSM app using that abstraction: #include <iostream> #include "abstract_fsm.h" FSM_DEF(Machine, // The type of the FSM (Play)(Stop), // the events // The transitions (including the states) ((Stopped, ((Play, Playing, { std::cout << "starting to play" << std::endl; })) ((Stop, Stopped, { std::cout << "stopping" << std::endl; })))) ((Playing, ((Stop, Stopped, { std::cout << "staying in Stopped" << std::endl; })))) ) int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } Everything is contained in that FSM_DEF construct, including events and transitions (including the source states). One cool thing is that the actions are right there. I have no clue as to the general usability of this abstract layer, but it serves the immediate purpose of testing runtime performance of the two libraries by merely using USE_SC or USE_MSM. This application is preprocessed to this Statechart app (by using -E -DUSE_SC...): #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/transition.hpp> struct Play : boost::statechart::event<Play> {}; struct Stop : boost::statechart::event<Stop> {}; struct Stopped; struct Playing; struct Machine : boost::statechart::state_machine<Machine, Stopped> { void actStoppedPlayPlaying(const Play& evt) { std::cout << "starting to play" << std::endl; } void actStoppedStopStopped(const Stop& evt) { std::cout << "stopping" << std::endl; } void actPlayingStopStopped(const Stop& evt) { std::cout << "staying in Stopped" << std::endl; } }; struct Stopped : boost::statechart::simple_state<Stopped, Machine> { typedef boost::mpl::list< boost::statechart::transition<Play, Playing, Machine, &Machine::actStoppedPlayPlaying> , boost::statechart::transition<Stop, Stopped, Machine, &Machine::actStoppedStopStopped> > reactions; }; struct Playing : boost::statechart::simple_state<Playing, Machine> { typedef boost::mpl::list< boost::statechart::transition<Stop, Stopped, Machine, &Machine::actPlayingStopStopped> > reactions; }; int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } And when preprocessing to an MSM app (by using -E -DUSE_MSM...): #include <boost/msm/back/state_machine.hpp> #include <boost/msm/front/state_machine_def.hpp> struct Play {}; struct Stop {}; struct Stopped : boost::msm::front::state<> {}; struct Playing : boost::msm::front::state<> {}; struct Machine_ : boost::msm::front::state_machine_def<Machine_> { typedef Stopped initial_state; void actStoppedPlayPlaying(const Play& evt) { std::cout << "starting to play" << std::endl; } void actStoppedStopStopped(const Stop& evt) { std::cout << "stopping" << std::endl; } void actPlayingStopStopped(const Stop& evt) { std::cout << "staying in Stopped" << std::endl; } typedef boost::mpl::vector< a_row<Stopped, Play, Playing, &Machine_::actStoppedPlayPlaying> , a_row<Stopped, Stop, Stopped, &Machine_::actStoppedStopStopped> , a_row<Playing, Stop, Stopped, &Machine_::actPlayingStopStopped> > transition_table; void initiate() {} }; typedef boost::msm::back::state_machine<Machine_> Machine; int main(int argc, const char* argv[]) { Machine mach; mach.initiate(); mach.process_event(Stop()); mach.process_event(Play()); mach.process_event(Stop()); } It is worth noting that once I had wrestled with Boost.Preprocessor and created a mapping to Statechart, the MSM mapping took 14 minutes, and a lot of meta functions were common between the two cases. /David

1 0

Does anyone know what happens to all we write at home?
by Vladimir Batov 07 Dec '09

07 Dec '09

Does anyone know what happens to all we write at home? We habitually put the 'boost' license on such work. However, can your employer claim that *anything* you do belongs to "him" and to slap you with a violation of Confidentiality Agreement or Intellectual Property Agreement? V.

3 2

[rdb, fusion, profile_templates] 0.2.03 - compilation speedup
by Jean-Louis Leroy 06 Dec '09

06 Dec '09

I have uploaded version 0.2.03 to the vault. No new features this time but improvements in compilation speed. The test_odbc project took more than 4.5 minutes to build in debug mode (msvc9, ThinkPad x200s, Intel L9400 with 2 cores @ 1.86 Ghz, 4 Gb RAM) and...17 minutes on a 2Gb RAM computer ! This was becoming unbearable. After a run through profile_templates - thanks to Steven Watanabe for creating this tool ! - I replaced the fusion::maps that were used to gather clause information in sql statement templates with a simpler, less flexible, less orthogonal and less capable version of my own. The result was a 41% speedup (calculated as (old-new)/old) on the 4 Gb computer and 85% on the 2Gb one. The number of template instantiations, as reported by profile_templates, dropped from 86330 to 62771. If someone is interested I can post the complete profiling reports. I plan to focus on datetime support now... Jean-Louis

2 2

Re: [boost] [msm] Review
by Christophe Henry 06 Dec '09

06 Dec '09

Hi David, >>> 2. In Statechart, the definition of a state is coupled to the machine in which it resides >>> while in MSM the state can be defined totally in isolation of the machine, and, thus, reused in other machines >>> 3. In Statechart, the transitions are coupled to the from-state, and defined therein, >>> whereas in MSM, the transitions are coupled to the machine itself; this makes it a bit tricky to reuse a state in Statechart >> >> This is an important interface difference, isn't it? > Yes, which is why I brought it up; see (*) below. Thanks for doing it, I see this as an important point. >* - Yes and no... As I explained in my note to Dave, I did not mean API when I wrote that dreaded sentence about the interface similarity, >I meant it in a more abstract sense. BUT, for simple cases, where we do not deal with transition guards or nested machines, >there actually is a quite close similarity even at a syntactical level. Agreed. But isn't the interface similarity mainly due to the very tightly specified problem domain and to the fact that we all use the excellent MPL tool? Of course, simple state machines using MPL will all look slightly the same, as will do those based on OO-principles with each other. When a new implementation (even based on the same tools) brings important advantages, shouldn't it be considered for inclusion? >They treat guards differently. Yes. I'll come back to it in a minute. >> Let's now add a conflicting transition, which means another possible >> transition on the same event and the same source state, with guards >> deciding which (if any) transition will be taken. >We are now arguably leaving theoretical FSM's and entering pragmatic machines :-) Sure. Theoretical FSM's are anyway about the same for all. My point is to show that differences between MSM and Statechart are subtle but play an important role. >> With MSM you'd have, for example: >> typedef mpl::vector< >> row<State1, Event, State2, &Machine_::action, &Machine_::some_condition>, >> row<State1, Event, State3, &Machine_::action, >> &Machine_::some_other_condition> >> > transition_table; >> >> Could you now write the Statechart version for us? > No ;-) Then, I'm not an expert with Statechart but allow me to try to help ;-) I think (please correct me if I'm wrong) it'd look about like: sc::result react(const Event& evt) { if (some_other_condition(evt)) { action(evt); return transit<State3>();} else if (some_condition(evt) { action(evt); return transit<State2>();} } And this is one important difference, not just a syntactic one. With SC, the structure of the state machine is hidden in the code, which will make your conversion tool harder to write on the direction SC->MSM as the tool will not just be able to parse the code but also understand it. Add a few more actions or other piece of code and I wish your tool luck ;-) OTOH you get more flexibility. So, my point is, there are more differences that syntactic ones, as long as you make more complicated machines. I still agree with you on the point that interfaces are not "widly different" but I put this on the account of a clearly specified problem domain and the fact that most of Boost uses the same MPL tool (due its huge power. Thanks Dave, thanks Aleksey ;-) ). >Yes, there are syntactical differences and decouplings of state vs machine which makes MSM a nicer tool; >and, didi I mention that MSM is in my simple test cases six times faster? You did and I thank you for adding your own tests to the review. As an extra note, if you are ready to give up some state features and need just an enum for the states, you might want to take the FSM in the MPL book. It would probably even be possible to make from it a backend which could at some point partly support the different MSM front-ends. MSM does not yet support this solution in order to deliver a back-end supporting the state features specified by UML (again the restricted problem domain) but it is one of the backends I consider for addition. Do we agree to leave the dreaded sentence behind us and replace it with one saying that both libraries solve the same problem using a wildly different implementation with similarities in the syntax? Christophe

2 1

[chrono] type_traits/common_type and integer/ratio
by Vicente Botet Escriba 06 Dec '09

06 Dec '09

Hi, I'm looking on how to continue with the Boost.Chrono library and I would like to know if * Boost.TypeTraits could take care of the common_type class template. * Boost.Integer could take care of the ratio class template. In this way Boost.Chrono will contain only the time related facilities, duration, time_point and Clocks. In order to minimize the task and been able to purpose as soon as possible the library for review I would like to concentrate on the implementation of the standard proposal and let for a future release the facilities Beman added as * Class template timer, with typedefs: * `system_timer` * `monotonic_timer` * `high_resolution_timer` * Process clocks and timers: * `process_clock`, capturing real, user-CPU, and system-CPU times. * `process_timer`, capturing elapsed real, user-CPU, and system-CPU times. * `run_timer`, convenient reporting of process_timer results. What do you think about this approach? Best, Vicente -- View this message in context: http://old.nabble.com/-chrono--type_traits-common_type-and-integer-ratio-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 19

Re: [boost] [msm] Review
by Christophe Henry 06 Dec '09

06 Dec '09

>> Repeating: the MSM/Statechart overlap in features and interface is quite >> unique to Boost. > > > They definitely overlap in features and also in intent, but my understanding > is that the interfaces are vastly different, and that's an important > distinguishing feature. Am I missing something? No you aren't. At first look, they seem similar, but as soon as you concretely start writing a state machine with both libraries, like Juraj could tell you (he did it), you'll start seeing that the differences are there. Of course, both use states, events and transitions but that's about all. MSM bases itself on the transition table, while with Statechart, the user writes his decisions in the react function. Composites are full state machines with MSM, a simple state with Statechart. MSM uses more metaprogramming, Statechart follows a solution with multiple translation units. Etc. etc. The point is, the interfaces differ, the normal usage even more and the "correct" way to use each (in the authors' eyes) much more as both follow a completely different philosophy, as many heated discussions showed. Christophe

4 4

arithmetic meta functions and traits
by Zachary Turner 06 Dec '09

06 Dec '09

Is there any use for something like this? Following compiles on MSVC 9.0. Despite the simplicity of the final template, it was *NOT* easy to get this working given that there's about 10 ways you should be able to do this according to the standard, but poor SFINAE support makes it next to impossible to get your compiler to accept anything. Since it doesn't do anything highly fancy, I would wager it works on GCC and other compilers as well, although it needs to be tested. struct no_type { }; #define MAKE_BINOP_METAFUNCTIONS(op, binop, traits) \ template<typename T, typename U> no_type operator op (T, U); \ template<typename T, typename U> \ struct traits \ { \ typedef BOOST_TYPEOF(T() op U()) type; \ }; \ template<typename T, typename U> \ struct binop \ { \ private: \ typedef typename traits<T,U>::type result_type; \ public: \ static const bool value = !boost::is_same<result_type,no_type>::value; \ }; MAKE_BINOP_METAFUNCTIONS(+, is_addable, addition_traits); MAKE_BINOP_METAFUNCTIONS(-, is_subtractable, subtraction_traits); MAKE_BINOP_METAFUNCTIONS(/, is_dividable, division_traits); MAKE_BINOP_METAFUNCTIONS(*, is_multipliable, multiplication_traits); Obviously you can define other operators similarly, as well as unary operators. Zach

2 4

Re: [boost] [explore] Library Proposal: Container Streaming
by Brian Wood 06 Dec '09

06 Dec '09

Jeff Flinn writes: > Regardless of the approach taken, I think this would be a useful > facility. I've created a similar, albeit much simplified facility for > two separate projects in the last 5 years. There've been several more > projects that could have used the more general facilities that this lib > offers. I think an on line approach is helpful and we have a service that writes Print functions based on user input -- http://webebenezer.net/cgi-bin/enrobo.cgi. This input: (list<int>) results in this output: void Print(std::ostream& so, const list<int>& abt1) { int indentation = 0; so.fill(' '); so << "\nabt1: "; so << "list has " << abt1.size() << "\n"; indentation += 2; list<int >::const_iterator mediator1 = abt1.begin(); list<int >::const_iterator omega1 = abt1.end(); for (; mediator1 != omega1; ++mediator1) { so.width(indentation); so << " "; so << (*mediator1); so << "\n"; } indentation -= 2; so << std::flush; } Brian Wood http://www.webEbenezer.net <http://www.webebenezer.net/> "The Kingdom of Heaven is like a treasure hidden in the field, which a man found and hid again; and from joy over it he goes and sells all that he has and buys that field."

1 0

MSM Review period extended to Dec 13th
by David Abrahams 06 Dec '09

06 Dec '09

Hi All, We thought this might happen because of the Thanksgiving holiday, and it did: we are extending the review period for the Meta State Machine library until Dec 13th. However, please don't let that delay your review; we'd like to see them all as soon as possible. Msm was written by Christophe Henry, inspired in part by the example in the book "C++ Template Metaprogramming" (http://boostpro.com/mplbook) About the library: Msm (Meta State Machine) is a library allowing the user to easily define high-performance, straightforward and readable UML2 finite state machines, while respecting the principles of efficiency and declarativeness of the original example. To that end, Msm offers several Domain-Specific Embedded Languages that strive to closely emulate a standard UML diagram. Msm supports a broad range of UML features: - state entry/exit - transition actions/guards - composite states - history - orthogonal regions - terminate states - deferred events - explicit entry/fork - entry/exit pseudostates - anonymous transitions - transition conflicts And several non-standard features to make the developer's life easier (interrupt states, query about the current state(s)). Msm (in its current version, 2.0) can be found: * in the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) * or in the vault: (http://www.boostpro.com/vault/index.php?directory=Msm) Everybody on this list is invited to participate in this formal review. I hope to see your review of Msm, including your vote on acceptance, and I welcome your participation in the ensuing discussions on the Boost developers' mailing list. Please always include in your review a vote as to whether the library should be accepted into Boost. Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? - With what compiler? - Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? -- David Abrahams BoostPro Computing http://boostpro.com

2 1

Regex allocator support
by Fred Sundvik 06 Dec '09

06 Dec '09

Hi, We recently had to use the regular expression library in conditions where there was no available physical memory, for reporting resource consumption when our console game runs out of memory. This wasn't possible however due to the fact that the basic_regex does some dynamic allocations and doesn't provide any allocator specialization, allthough match_results for example does. So we modified the boost code a little bit and added a new template paramter for the allocator, and made constructors that takes allocators as parameters. This was quite straightforward to do, the allocators just had to be passed forward to the all internal classes it uses. The shared_ptr's had to be changed to use the three parameter constructor, that takes a a deleter and allocator, to prevent them from allocating. The mem_block_cache system was a bit more complicated. Initially we disabled it completely, but that obviously wasn't the best solution. So we figured out, that we can use a custom allocator as default, instead of std::allocator. That custom allocator then had to be specialized for the mem_block_nodes, and the funcion calls to get_mem_block replaced by allocator calls. Our implementation isn't ideal, though as we used mem_block_node as the specialization, and to pass the correct size to the allocator, we allocate BOOST_REGEX_BLOCKSIZE / sizeof(mem_block_node) of them, this way it works for allocators that don't specialize for mem_block_node(but only if the size is dividable by sizeof(mem_block_node) ). Better would probably be to make a new type that is BOOST_REGEX_BLOCKSIZE big. We also found another problem with allocation, the match_result::format functions only takes string_type, that isn't specialized by any allocator as they input. This made it impossible to call them with strings using different allocators. So we added specializations of those functions for different allocators and traits. There are probably more functions like that, but since our code doesn't use them there was no need to change anything. So my question is, what are the chances that theese kinds of modificiations gets implemented in the actual library, and possibly in the next c++ standard library as well? I consider it a quite big design flaw to not have any control of the internal allocations, so for me this a quite big thing. Obviously we are doing well with the modifications we made here internally, but there are other applications too that would benefit, many embedded applications for example. Would our code changes be of any use? The changes are only the minimal needed to make it work in our case, and there's many compiler and option permutations not taken care of, so obviously a lot of work would still be needed. Also there's no additional unit tests made. Fred Sundvik Bugbear Entertainment Ltd.

5 7

Notice: Boost.Atomic (atomic operations library)
by Helge Bahmann 05 Dec '09

05 Dec '09

Hello, as promised I have started extracting an atomic operations library. Current state is available at: http://www.chaoticmind.net/~hcb/projcets/boost.atomic It implements boost::atomic<TYPE> which faithfully mimics std::atomic<TYPE> as specified in the C++0x draft standard. As allowed by the standard, operations transparently fall back to locking when the underlying architecture does not support the requested operation, so the library already contains a "fallback" implementation that works an all platforms (using mutex from boost::thread). It currently natively supports gcc/x86, gcc/powerpc and gcc/alpha (I can vouch for the correctness of the implementations on these targets). It contains some entirely untested support for building implementations from CAS operations on other systems (e.g. _InterlockedCompareExchange on win), so I would greatly appreciate any feedback if it works/doesn't on any particular platform. There is some preliminary documentation, but not in boostdoc format -- after unsuccessfully struggling with bjam/boostbook & friends for a few hours I simply gave up and reverted to trusty old doxygen :( Is there any step-by-step guide on how to create, build and document a new library? I could really use that as the boost build and documentation system is pretty alien to an autotools-accustomed guy like me. Best regards Helge

10 33

Re: [boost] [msm] Review
by Christophe Henry 05 Dec '09

05 Dec '09

Hi David, > It is sad that my comments are construed as criticism of MSM, since they merely point out the (I thought obvious...) >similarities with another library already in Boost. >After having tried MSM for a few days, most of it rocks, and I will provide a review later today. Oh I didn't take it as a criticism of MSM at all, merely of a valid issue which will have to be solved in Boost at some point because, as Boost grows, it is bound to happen again. I'll look at your review with great interest and thank you for taking the time to write it. To the core of your point, which is actually a valid concern. I agree that MSM and Statechart are solving the same problem. To explain what I (and probably Andreas) mean, let's look at the problem from a different angle. Let's suppose we'd build a Statechart 2.0. How would it look like? Would it go for the MSM way, putting as much as possible on the compiler, at the risk of breaking it, or the Statechart way, less metaprogramming and easier on compilers but slowlier and with a less descriptive interface (in my opinion)? Would it go for a transition table way or a state::react way? What kind of state storage would it take? And so on and so on. What is likely is that we'd probably not even manage to agree on the goals, much less on the design or the implementation. MSM comes from my frustration with not managing to make Satechart do what I needed. This shows that the philosophy of both authors is quite different and likely incompatible. Christophe

1 0

Fixed bug in filesystem library ?
by Luca Severini 05 Dec '09

05 Dec '09

Hello everyone, I'm a newbie to boost libraries but I have some good experience in software development on Mac OS. Today I use downloaded and used boost for the first time. I use a MacBook Pro with Snow Leopard 10.6.2. The IDE is Xcode 3.2.1 Writing some very basic code to learn how to use the filesystem library I got assertions (below) simply iterating recursilvely through a local directory to list its content. /Developer/Test/TestFolder Boost_Test(57690) malloc: *** error for object 0xe518: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug Investigating in the code I've found the assertions were triggered by two uninitialized std::string variables with same name passed to the functions detail::dir_itr_first() and detail::dir_itr_increment(). Initializing both to the simple content ".", directly in the constructor, seems to have fixed the problem (no assertions anymore). Here are the two functions I've changed in the file operations.hpp. The code I added is in green. Nothing has been deleted. I was thinking to follow the instructions to submit the fix but, please excuse me, I've found easier to send an email to the list. Hopefully someone with better knowledge of boost than me will submit gthe fix if it's the case o will find a better solution. Best regards, Luac Severini template<class Path> system::error_code basic_directory_iterator<Path>::m_init(const Path & dir_path) { if ( dir_path.empty() ) { m_imp.reset(); return detail::not_found_error(); } typename Path::external_string_type name("."); // String initialized to avoid assertion file_status fs, symlink_fs; system::error_code ec( detail::dir_itr_first( m_imp->m_handle, #if defined(BOOST_POSIX_API) m_imp->m_buffer, #endif dir_path.external_directory_string(), name, fs, symlink_fs ) ); if ( ec ) { m_imp.reset(); return ec; } if ( m_imp->m_handle == 0 ) m_imp.reset(); // eof, so make end iterator else // not eof { m_imp->m_directory_entry.assign( dir_path / Path::traits_type::to_internal( name ), fs, symlink_fs ); if ( name[0] == dot<Path>::value // dot or dot-dot && (name.size() == 1 || (name[1] == dot<Path>::value && name.size() == 2)) ) { increment(); } } return boost::system::error_code(); } template<class Path> void basic_directory_iterator<Path>::increment() { BOOST_ASSERT( m_imp.get() && "attempt to increment end iterator" ); BOOST_ASSERT( m_imp->m_handle != 0 && "internal program error" ); typename Path::external_string_type name("."); // String initialized to avoid assertion file_status fs, symlink_fs; system::error_code ec; for (;;) { ec = detail::dir_itr_increment( m_imp->m_handle, #if defined(BOOST_POSIX_API) m_imp->m_buffer, #endif name, fs, symlink_fs ); if ( ec ) { boost::throw_exception( basic_filesystem_error<Path>( "boost::filesystem::basic_directory_iterator increment", m_imp->m_directory_entry.path().parent_path(), ec ) ); } if ( m_imp->m_handle == 0 ) { m_imp.reset(); return; } // eof, make end if ( !(name[0] == dot<Path>::value // !(dot or dot-dot) && (name.size() == 1 || (name[1] == dot<Path>::value && name.size() == 2))) ) { m_imp->m_directory_entry.replace_filename( Path::traits_type::to_internal( name ), fs, symlink_fs ); return; } } }

2 1

[iostreams] 1.41 gzip filter regression
by Alexander Arhipenko 05 Dec '09

05 Dec '09

Hi guys, In 1.41 we are experiencing regression in boost::iostreams::gzip_decompressor. Almost 50% percents of our test *.gz files failed to decompress. Following code snippet usually throws gzip error: std::ifstream f(n, std::ios_base::in | std::ios_base::binary); if(!f) { std::cerr<<"cant' open "<<n<<'\n'; } namespace io = boost::iostreams; io::filtering_istream in; in.push(io::gzip_decompressor() ); in.push(f); std::istreambuf_iterator<char> b(in); std::istreambuf_iterator<char> e; std::cout<<n<<'\n'; std::copy(b, e, std::ostream_iterator<char>(std::cout) ); Maybe that is caused by incorrect api usage. In this case, sorry for the noise in advance. I've attached minimal example that reproduces the issue. Build showfile executable and run ./showfile myfile.odt.bz2.gz > result. You should have 'error: gzip error' on stderr. Regards

4 8

svn mergeinfo broken at the root.
by Steven Watanabe 05 Dec '09

05 Dec '09

AMDG Beman, I'm not quire sure what you did, but svn:mergeinfo doesn't work for me anymore. https://svn.boost.org/trac/boost/changeset/57638 destroyed the svn:mergeinfo for all the revisions that I had already merged (I have been doing all merges at the root). In Christ, Steven Watanabe

1 0

symbolic links while building boost
by Zachary Turner 04 Dec '09

04 Dec '09

I use Windows primarily, and typically after building boost, there are two copies of each library. One with the version extension such as -1_41, and the other without. My understanding is that the one without the version number is supposed to be a symlink to the one with the version number on platforms such as linux, but that on Windows it is just a copy of the file due to poor support for symlinks in windows. My question is whether there has been any talk of changing this. Windows has supported first class symlinks since Vista, so it would seem possible to have Vista and beyond actually use this functionality and create real symlinks. Thoughts? Zach

3 3

Re: [boost] Meta State Machine library review / MSM, question
by Christophe Henry 04 Dec '09

04 Dec '09

Hi Barend, >All my states are structs. Why is the state an integer here? How can I >(humanly or with MSM) translate that state to one of the states defined? >It works, I get a message, but still don't know which transition was not >provided... Unfortunately, no_transition is one of the few cases, where because of implementation details, MSM already crossed the compile-time / run-time boundary and all it has is the state id. Annex A shows the order in which the (usually hidden) state index is calculated. It's simply the order of appearance in the transition table. First are source states checked, then target states. Regards, Christophe

1 0

Re: [boost] [msm] Review
by Christophe Henry 04 Dec '09

04 Dec '09

Hi all, Looks like there was a fair bit of discussion ;-) I'll try to give my take on the many discussed points. Jeffrey Bosboom wrote: >But I think this concern can be addressed if there is a documentation >page that compares the libraries that is included in (or linked from) >both libraries' documentation. This would make it much easier for a >user to choose one or the other without having to read the full >documentation for each. This sounds like a good idea to me. Not everybody followed the review. Andrew Venikov wrote: >I think an even better example would be map and hash_map. >They serve almost identical purpose but using totally different >techniques. The user of stl is expected to understand the differences >and chose the appropriate container. >Why not do the same with SC and MSM? Yes, we should really write a page explaining the trade-offs. David Bergman wrote: > I would even have welcomed some macros that introduce the state declarations for simplistic states, > from that transition table expression. There is something like this in eUML (on compilers with native typeof). Is this ok for you? typedef BOOST_TYPEOF(build_state( )) Paused; I can of course also add a macro for other compilers. David Bergman wrote: >Well, well, I seem to be the only one caring about this, and MSM sure is a fine library, >so I say 'welcome metamagical states!'. > NOTE: no, this was not a formal review ;-) I would welcome a formal review though. It'd help the review manager make a decision ;-) Jeffrey Bosboom wrote: >Decide whether MSM should be included or not on its own merits. If so, >then MSM makes Boost better; we shouldn't be so concerned with being >perfect that we lose the opportunity to be better. I agree. We should always decide on a library's merit and then see how to handle it. It'd be sad to lose an opprtunity to make boost more valuable on organisatory grounds. This doesn't apply only to MSM. David Bergman wrote: >You have a good point there. Although I would rather have seen the MSM guys collaborate with the Statechart guys >on making Statechart easier to use (especially the expression of the transition table) and/or more performant, though. >If that would have led to a combined Statechart 2.0 (analogous to Spirit 2.0) in a year, I would wait. Merging would be quite hard. While both libraries seem to have almost the same interface, scratching the surface will show many differences. The reason is that both libraries follow a pretty different philosophy and use different techniques. The best which might be achieveable would be a new front-end in MSM trying to match as much as possible SC's front-end. It would probably work for simple state machines. It might even work for composites. I'm not expert enough in Statechart to tell if more is possible. And the question is if someone would ever need this. You would still get the compiler limitations (and maybe add some more due to the added metaprogramming) and not all of SC's features. Why to use it then? However, if someone is willing to take this task on, I'd be ready to help. Ideally we would have to do the same in Statechart for one of MSM's front-ends. Sounds like a lot of work. Christophe

1 0

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 04 Dec '09

04 Dec '09

Hi Barend, > First I thought (intuitively) that the eUML was meant for output, but > apparently that is not the case, it is an embedded language for defining > state machines, right Right. It is at the same time syntactic sugar and a way to concentrate more information in the transition table. For designers, it is sometimes helpful to be able to see the whole transition at the same time and in the same place. > Is is somehow possible to export an MSM to a Boost.Graph, either within > the library, or in an example or separate utility headerfile? Yes it is. A transition table is relatively easy to parse and thus it should be possible to generate a diagram from a transition table. As shown at the last BoostCon, I'm working on a tool doing just this, but a graph export might be a nice and useful addition. Regards, Christophe

2 1

[iostreams] input_sequence() questions
by Rob Riggs 04 Dec '09

04 Dec '09

I am attempting to adapt a windowed mmap reader, one which manages its mapping window using iterators, to a boost::iostreams direct source. I wrote this for reading large files via mmap on 32-bit platforms. The documentation shows that input_sequence() returns a pair of char pointers, not iterators. Is that really true or am I misreading the docs? http://www.boost.org/doc/libs/1_41_0/libs/iostreams/doc/concepts/source.html And it also shows that the input_sequence pointers are non-const. Why is that required for sources? Thanks, Rob

1 0

[explore] Extending namespace std
by Jeffrey Faust 04 Dec '09

04 Dec '09

The various threads of discussion have died down. These include the name of the library, whether it's useful or not, if it is useful can it be satisfied by an existing library, whether it should it be part of another library or be a library on its own, and gcc compiler switches. All of these are important and we'll have to address them at some point (except perhaps the compiler switches). One item that was brought up and dismissed is that the implementation relies on extending namespace std. I'd like to visit this item more thoroughly. In my opinion the ideal interface is the most natural, simplest, and the most familiar to C++ developers: 'cout << c;' where c is a container of type C. Going beyond this nominal usage employs stream manipulators, again something that is known. Other forms such as 'print(c);' or 'wrapper(cout) << c;' are inferior interfaces. The former is clumsy and the latter does not extend in a natural way. Whether or not you agree, for the sake of argument, let's start with the statement that 'cout << c;' is the ideal interface for this library. Let's discuss how we can make this work. The only way I know how to make 'cout << c;' work for all cases is to put operator<<(C) in the same namespace as C. For example, variant<C, ...> will not stream if C is in std and operator<<(C) is not. The only way operator<<(variant) can see operator<<(C) is through ADL. If anybody can think of a mechanism where this will work without extending namespace std, please speak up. In regards to extending namespace std, I understand what the standard says and I think I understand the reasons behind it. I could add something to namespace std that conflicts with an existing item, changing the behavior. This is certainly undefined behavior, and the standard is right in restricting it. I don't believe this problem exist for the explore library. If we know that on all supported compilers that extending namespace std in this way behaves correctly, what is the concrete problem of doing so? Thanks for reading, -- Jeff Faust

1 0

FunctionTypes broken in trunk
by Tor Brede Vekterli 03 Dec '09

03 Dec '09

Hi This is just a notice that the FunctionTypes library appears to have been broken since revision 56305, where several of the arity preprocessor files have become corrupted (more specifically, arbitrarily cut off) for some reason or another. The following extremely small test-case should fail to compile: #include <boost/function_types/function_pointer.hpp> int main() {} Best regards, Tor Brede Vekterli

3 2

[msm] Comments
by Nelson, Erik - 2 03 Dec '09

03 Dec '09

I erroneously posted this on boost-users yesterday... Reposting it here today. I'm not competent to present a full review of the Boost MSM library, but I've been following it with interest since I discovered it at BoostCon. I've read very many mailing list exchanges between Christophe and users during this time. The MSM review hasn't generated a ton of traffic, and I'd like to contribute my comments for whatever they're worth. >What is your evaluation of the design? The Boost MSM library seems to be a well-designed implementation of state machine logic that is faithful to the UML standard in most areas and thoughtfully deviates from (or extends) it in a few places. >What is your evaluation of the implementation? I feel like the implementation is a clean example of modern C++ and abstracts state machine concepts quite well. The transition table in particular is implemented elegantly. >What is your evaluation of the documentation? Adequate >What is your evaluation of the potential usefulness of the library? Very useful... I expect to need this library for my work within the next 3-6 months >Did you try to use the library? I have not used the library. >How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Something more than a quick reading, yet well short of an in-depth study. >Are you knowledgeable about the problem domain? Not particularly.. I've handwritten small state machines for GUI programming in the past As an additional comment, I believe Christophe himself typifies the best things about Boost. He has tirelessly worked on MSM and has been very supportive of users, incorporating many suggestions for improvement. MSM should definitely be included in Boost. Thanks Erik

1 0

[explore] Library Proposal: Container Streaming
by Jeffrey Faust 03 Dec '09

03 Dec '09

Jared McIntyre, Danny Havenith, and myself, with support from Jeff Garland have developed a library to stream standard containers to output streams. We would like to submit this for review. The requirements for this library were gathered at the BoostCon 2007 Library in a Week sessions. An initial review was held and further requirements were gathered at BoostCon 2008. Everything can be found in the boost vault <http://www.boostpro.com/vault/> . Here is a direct link to explore.zip <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ex plore.zip&directory=&> . Some quick examples: #include <boost/explore.hpp> # include ... // simple vector example std::vector<int> vi; vi.push_back(1); vi.push_back(2); vi.push_back(3); std::cout << vi; // prints [1, 2, 3] // lets do some containers in containers std::vector<std::vector<int> > vvi; vvi.push_back(vi); vvi.push_back(vi); std::cout << vvi; // prints [[1, 2, 3], [1, 2, 3]] // associative containers std::map<std::string, int> si_map; si_map["hello"] = 1; si_map["world"] = 2; std::cout << si_map; // prints [hello:1, world:2] // containers of complex types std::list<date> dl; // date from boost::gregorian dl.push_back(date(2007, Jan, 1)); dl.push_back(date(2007, Jan, 3)); std::cout << dl; // prints [2007-Jan-1, 2007-Jan-3] // how about some boost container types: boost::array<std::string, 2> sa2; sa2[0] = "one"; sa2[1] = "two"; std::cout << sa2; // prints [one, two] Jeffrey Faust

27 56

[serialization] polymorphic archives runtime failure (was: polymorphic archives ... generates linker errors)
by Christoph Heindl 03 Dec '09

03 Dec '09

Hi, thanks to Roberts help I managed to get the polymorphic archives issue, discussed earlier at http://article.gmane.org/gmane.comp.lib.boost.devel/196984) resolved. However there remains a runtime issue I can't resolve: Based on demo_polymorphic.cpp I've re-created minimal test example, which I think is correct, that fails with the runtime assertion it != m_map.end(), file libs\serialization\src\basic_serializer_map.cpp, line 72 on load. The demo consists of 5 files that create the following scenario: class B inherits from polymorphic base class A. An object of B is allocated on the heap and serialized through a base pointer A using a polymorphic xml archive. Saving runs without problems. Next, B is loaded from the stream through a base pointer to A. This fails with the mentioned assertion. What makes me wonder is that changing the from polymorphic_xml_iarchive to xml_iarchive and from polymorphic_xml_oarchive to xml_oarchive will not produce the named assertion. As mentioned in my previous post, I tested this with boost 1.40.0 and msvc 9.0. I would be really, really, grateful if you could give the demo a try. I've prepared everything so that it is just a matter of copying the files to libs/serialization/example and adding [ demo_bsl_run demo_polymorphic_cheind : cheind_a cheind_b ] The files can be found attached to my lost post at http://article.gmane.org/gmane.comp.lib.boost.devel/197061 Best regards, Christoph

2 4

Re: [boost] Regex allocator support
by Fred Sundvik 03 Dec '09

03 Dec '09

Sorry for the previous message. Somehow I managed to send the message without a reply. A proper reply will follow soon. "Fred Sundvik" <fred.sundvik(a)bugbear.fi> wrote in message news:14525.2590220936$1259836768@news.gmane.org... >>> We recently had to use the regular expression library in conditions >>> where there was no available physical memory, for reporting resource >>> consumption when our console game runs out of memory. This wasn't >>> possible however due to the fact that the basic_regex does some > dynamic >>> allocations and doesn't provide any allocator specialization, > allthough >>> match_results for example does. So we modified the boost code a > little >>> bit and added a new template paramter for the allocator, and made >>> constructors that takes allocators as parameters. >>> >> <snip> >>> >>> So my question is, what are the chances that theese kinds of >>> modificiations gets implemented in the actual library, and possibly > in >>> the next c++ standard library as well? I consider it a quite big > design >>> flaw to not have any control of the internal allocations, so for me > this >>> a quite big thing. >> >> +1; I agree with the OP's sentiments, though I wouldn't say it's >> necessarily a "big" design flaw. However, I've never used the >> Boost.Regex library, and I don't know if the next standard specifies >> allocator parameters. I gather it doesn't? > > Sigh... no. > > The original regex++ library upon which the Boost version is derived > *did* > have allocators for everything. But during review folks felt quite > strongly > that: > > a) It was overkill. > b) Regex should be free to manage it's own memory - it's not a container > - > it's needs are much more complex than that - so it should be free to > optimize memory allocation and caching as it sees fit. > > As a result this facility was removed. Rightly or wrongly, no one on > the > stds committee questioned that design decision. > > Some specific comments on the other issues: > >>The mem_block_cache system was a bit more complicated. Initially we >>disabled >>it completely, but that obviously wasn't the best solution. So we > figured >>out, that we can use a custom allocator as default, instead of >>std::allocator. That custom allocator then had to be specialized for > the >>mem_block_nodes, and the funcion calls to get_mem_block replaced by >>allocator calls. Our implementation isn't ideal, though as we used >>mem_block_node as the specialization, and to pass the correct size to > the >>allocator, we allocate BOOST_REGEX_BLOCKSIZE / sizeof(mem_block_node) > of >>them, this way it works for allocators that don't specialize for >>mem_block_node(but only if the size is dividable by >>sizeof(mem_block_node) ). Better would probably be to make a new type > that >>is BOOST_REGEX_BLOCKSIZE big. > > Can you not just define BOOST_REGEX_RECURSIVE and use the stack based > implementation that does away with that altogether? > >>We also found another problem with allocation, the match_result::format >>functions only takes string_type, that isn't specialized by any > allocator >>as >>they input. This made it impossible to call them with strings using >>different allocators. So we added specializations of those functions > for >>different allocators and traits. There are probably more functions like >>that, but since our code doesn't use them there was no need to change >>anything. > > The current Trunk allows any string, container or character type, plus > function objects to be used as arguments to regex_format/regex_replace > etc, > which should avoid that problem. > >>We recently had to use the regular expression library in conditions > where >>there was no available physical memory, for reporting resource > consumption >>when our console game runs out of memory. > > I'm not sure I understand the issue here, that operator new doesn't > report > out of memory conditions? What does your allocator do that's different > to > operator new, and why not replace global new and delete with calls to > your > custom allocator? Just trying to get a handle on the issue... > >>So my question is, what are the chances that these kinds of > modifications >>gets implemented in the actual library, and possibly in the next c++ >>standard library as well? > > As noted above, I was asked to remove this feature during review, so I'm > not > *that* keen to put it back in! As far as the standard is concerned it's > > basically a done deal at this stage in the process - too late for such a > big > change. WRT Boost I'd really like to get a handle on the issue better > before making judgment - you seem to be one of very few people actually > using custom allocators ;-) > > Regards, John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost >

1 0

Re: [boost] Regex allocator support
by Fred Sundvik 03 Dec '09

03 Dec '09

>> We recently had to use the regular expression library in conditions >> where there was no available physical memory, for reporting resource >> consumption when our console game runs out of memory. This wasn't >> possible however due to the fact that the basic_regex does some dynamic >> allocations and doesn't provide any allocator specialization, allthough >> match_results for example does. So we modified the boost code a little >> bit and added a new template paramter for the allocator, and made >> constructors that takes allocators as parameters. >> > <snip> >> >> So my question is, what are the chances that theese kinds of >> modificiations gets implemented in the actual library, and possibly in >> the next c++ standard library as well? I consider it a quite big design >> flaw to not have any control of the internal allocations, so for me this >> a quite big thing. > > +1; I agree with the OP's sentiments, though I wouldn't say it's > necessarily a "big" design flaw. However, I've never used the > Boost.Regex library, and I don't know if the next standard specifies > allocator parameters. I gather it doesn't? Sigh... no. The original regex++ library upon which the Boost version is derived *did* have allocators for everything. But during review folks felt quite strongly that: a) It was overkill. b) Regex should be free to manage it's own memory - it's not a container - it's needs are much more complex than that - so it should be free to optimize memory allocation and caching as it sees fit. As a result this facility was removed. Rightly or wrongly, no one on the stds committee questioned that design decision. Some specific comments on the other issues: >The mem_block_cache system was a bit more complicated. Initially we >disabled >it completely, but that obviously wasn't the best solution. So we figured >out, that we can use a custom allocator as default, instead of >std::allocator. That custom allocator then had to be specialized for the >mem_block_nodes, and the funcion calls to get_mem_block replaced by >allocator calls. Our implementation isn't ideal, though as we used >mem_block_node as the specialization, and to pass the correct size to the >allocator, we allocate BOOST_REGEX_BLOCKSIZE / sizeof(mem_block_node) of >them, this way it works for allocators that don't specialize for >mem_block_node(but only if the size is dividable by >sizeof(mem_block_node) ). Better would probably be to make a new type that >is BOOST_REGEX_BLOCKSIZE big. Can you not just define BOOST_REGEX_RECURSIVE and use the stack based implementation that does away with that altogether? >We also found another problem with allocation, the match_result::format >functions only takes string_type, that isn't specialized by any allocator >as >they input. This made it impossible to call them with strings using >different allocators. So we added specializations of those functions for >different allocators and traits. There are probably more functions like >that, but since our code doesn't use them there was no need to change >anything. The current Trunk allows any string, container or character type, plus function objects to be used as arguments to regex_format/regex_replace etc, which should avoid that problem. >We recently had to use the regular expression library in conditions where >there was no available physical memory, for reporting resource consumption >when our console game runs out of memory. I'm not sure I understand the issue here, that operator new doesn't report out of memory conditions? What does your allocator do that's different to operator new, and why not replace global new and delete with calls to your custom allocator? Just trying to get a handle on the issue... >So my question is, what are the chances that these kinds of modifications >gets implemented in the actual library, and possibly in the next c++ >standard library as well? As noted above, I was asked to remove this feature during review, so I'm not *that* keen to put it back in! As far as the standard is concerned it's basically a done deal at this stage in the process - too late for such a big change. WRT Boost I'd really like to get a handle on the issue better before making judgment - you seem to be one of very few people actually using custom allocators ;-) Regards, John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] [msm] Review
by Christophe Henry 02 Dec '09

02 Dec '09

Hi Andreas, > It doesn't, but this seems to be beside the point anyway. You wrote (in an > unquoted part) that Msms behavior with respect to storage in states is hard > to emulate with SC. Simon only showed that it isn't (unless Simon and I are > missing something). But (as you wrote yourself in this excellent rationale) if you have to move the data from state to fsm you lose part of the benefit of state-storage, right? OTOH you get the advantage of automatic destruction. Even better would be to allow both possibilities through a policy. For every design decision taken in Msm, you will probably find a case where SC will offer a better solution in some cases and vice versa. At first glance, it seems that state storage is the same in both libraries, but as it turns out, there are subtle differences. > That's good to hear. BTW, is there only a limit on the number of > transitions, or is the number of states limited in some way to? Does the > number or orthogonal regions have an influence? I never managed to break a compiler purely on the number of states (I tried up to 80). The orthogonal regions have very little influence as their metaprogramming needs are very small. Regards, Christophe

2 1

Wireshark Dissector for Boost
by Rick Bywater 02 Dec '09

02 Dec '09

Hello all, I am part of a project that is using Boost for serialization over a UDP interface. In concert with that effort, I am writing a Wireshark dissector to decode these packets as they transit the network. So, my question is, has someone already written a C dissector to handle these packets? If not, does anyone have any advice on how to proceed with writing one? -- Best Regards, Rick Bywater Lead Member of Technical Staff Tecore Networks Phone: +1 321 953 6794 Fax: +1 321 676-9914 email: rbywater(a)tecore.com

1 0

[multiarray] please review patch for ticket #1045; adds member swap
by Rhys Ulerich 02 Dec '09

02 Dec '09

Any MultiArray maintainers out there? I've prepared a patch to add swap for multi_array_ref and multi_array. This is a longstanding feature request (https://svn.boost.org/trac/boost/ticket/1045) The patch is attached to the ticket. If possible, I'd like to get the patch reviewed, revised as necessary, and included in 1.42. Thank you for your time, Rhys

1 0

[msm] Review
by Franz Alt 02 Dec '09

02 Dec '09

Hello Boost! This is my review for the MSM library: * What is your evaluation of the design? I've used MSM quite a while. I've already used MSM 1.x and also the new 2.0 since a few weeks. In this time I've written some own state machines, played with the samples contained with MSM 1.x/2.0 and also made some comparisons with the Boost.Statechart library. I've run the state machines I've build on standard desktop PCs as well as on embedded systems (MIPS with ~300 MHz and ARM with ~50 MHz). On all platforms MSM made a good picture and always worked as expected. I'm not a guru in UML state charts but I've tried to use as much features of MSM as I could. * What is your evaluation of the implementation? I've looked into the main parts of the source code of MSM 1.x and a little bit of MSM 2.0. I've welcome the front- and back-end at 2.0 and the omission of the CRTP pattern (CRTP = The Curiously Recurring Template Pattern). My experience in template metaprogramming is quite limited but as I've tortured myself with CRTP a long time I knew that it's handling is quite hard sometimes. The font- and back-end at 2.0 improved the readability of MSM very much. Or should I say it improves the readability of some parts of the MSMs source code!? Because the source code of MSM 2.0 is very hard to read and understand at some places. But it's wonderful to see that metaprogramming stuff working ;-) * What is your evaluation of the documentation? I think that the documentation could be better than it is at the moment. For my taste "one" big documentation isn't nice to read. In Boost there are existing more nicely documentations like Boost.Proto or Boost.Spirit. It's a matter of taste but I think it could be an improvemet for Boost if all libraries documentations has (nearly) the same visual style. But this shouldn't be discussed here at this review. * What is your evaluation of the potential usefulness of the library? I think MSM is very useful for every professional C++ developer. Especially for state machines on embedded systems MSM could be a real improvement with it's O(1) complexity. I've made a comparison of MSM against Boost.Statechart and a state machine generated with IBM's Rational Rhapsody tool. The state machine for this comparison was the simple CD player example delivered with MSM. The results of this comparison and the source code - expected the libraries to build the Rhapsody example - I've attached to this mail. The conclusion at this test was that MSM is about 5 times faster than a state machine generated with IBMs Rational Rhapsody and a state machine with Rhapsody is 4 times faster than a state machine generated with Boost.Statechart. This was very surprisingly for my because I've thought that Boost.Statechart is much faster than the generated state machine with Rhapsody. In contrast to Boost.Statechart, MSM was approximately 20 times faster. Like I've said before I'v used the simple CD player example. A more complex state machine could lead to more interesting results of MSM, Boost.Statechart and Rhapsody. But this need some extra time that I don't have at moment. Another very important fact is that MSM uses very much compiler ressources. The problem here is that state machines with too much states and/or transitions could lead to the situation that the compiler runs out of memory and the state machine couldn't be build. I think this is only a problem of time. Further compiler versions could be more cooperative with MSM than today compilers. I think MSM is perfectly for small and medium static state machines and Boost.Statechart is good for dynamic and very big state machines. But this is only a thesis from myself and I think this should be evaluated in more detail. But this shouldn't be part of this review. A very big improvement for me is the eUML "language" at MSM 2.0. It's takes getting used to use it but I think it's such a cool think that I don't know how I've written state machines before without eUML :-) Ok, a little bit hamed but I think writing state machines with eUML could be such a big improvement for every application. * Did you try to use the library? With what compiler? Did you have any problems? I've used the library for several tests. I've used MSVC 9 and GCC 4.3/4.4. I've detected no problems with MSM. The only "problem" was that mistypes could lead to compiler errors with pages of (useless) informations. But this isn't a problem of MSM. This is more a problem of template metaprogramming. * How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've used MSM 1.x quite a long time. For this review I tried to use the new 2.0 and some of the new features (like eUML). I've already tried to use MSM on embedded systems like on MIPS and ARM platform. I've already tried to make a in-depth study but the MSM source code is very hard to understand. * Are you knowledgeable about the problem domain? I'm not a guru in UML state machines but I know the basics and used state machines quite a long time. * Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Yes. I think MSM is an enrichment for Boost. MSM beates IBMs Rational Rhapsody! And the best, it's free, it's metaprogramming and it's Boost :-) Writing state machines make so much fun with MSM and the knowledge that it's O(1) is the best a software developer could wish. Best regards Franz // MsmSimple.cpp : Defines the entry point for the console application. // #include <boost/msm/back/state_machine.hpp> #include <boost/msm/front/state_machine_def.hpp> namespace msm = boost::msm; namespace mpl = boost::mpl; #include <iostream> #ifdef WIN32 #include "windows.h" #else #include <sys/time.h> #endif namespace test_fsm // Concrete FSM implementation { // events struct play {}; struct end_pause {}; struct stop {}; struct pause {}; struct open_close {}; struct cd_detected{}; // Concrete FSM implementation struct player_ : public msm::front::state_machine_def<player_> { // no need for exception handling or message queue typedef int no_exception_thrown; typedef int no_message_queue; // The list of FSM states struct Empty : public msm::front::state<> { // optional entry/exit methods template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Empty" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Empty" << std::endl;*/} }; struct Open : public msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Open" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Open" << std::endl;*/} }; struct Stopped : public msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Stopped" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Stopped" << std::endl;*/} }; struct Playing : public msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Playing" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Playing" << std::endl;*/} }; struct Paused : public msm::front::state<> { template <class Event,class FSM> void on_entry(Event const&,FSM& ) {/*std::cout << "entering: Paused" << std::endl;*/} template <class Event,class FSM> void on_exit(Event const&,FSM& ) {/*std::cout << "leaving: Paused" << std::endl;*/} }; // the initial state of the player SM. Must be defined typedef Empty initial_state; // transition actions void start_playback(play const&) { } void open_drawer(open_close const&) { } void close_drawer(open_close const&) { } void store_cd_info(cd_detected const& cd) { } void stop_playback(stop const&) { } void pause_playback(pause const&) { } void resume_playback(end_pause const&) { } void stop_and_open(open_close const&) { } void stopped_again(stop const&) {} // guard conditions typedef player_ p; // makes transition table cleaner // Transition table for player struct transition_table : mpl::vector< // Start Event Next Action Guard // +---------+-------------+---------+---------------------+----------------------+ a_row < Stopped , play , Playing , &p::start_playback >, a_row < Stopped , open_close , Open , &p::open_drawer >, a_row < Stopped , stop , Stopped , &p::stopped_again >, // +---------+-------------+---------+---------------------+----------------------+ a_row < Open , open_close , Empty , &p::close_drawer >, // +---------+-------------+---------+---------------------+----------------------+ a_row < Empty , open_close , Open , &p::open_drawer >, a_row < Empty , cd_detected , Stopped , &p::store_cd_info >, // +---------+-------------+---------+---------------------+----------------------+ a_row < Playing , stop , Stopped , &p::stop_playback >, a_row < Playing , pause , Paused , &p::pause_playback >, a_row < Playing , open_close , Open , &p::stop_and_open >, // +---------+-------------+---------+---------------------+----------------------+ a_row < Paused , end_pause , Playing , &p::resume_playback >, a_row < Paused , stop , Stopped , &p::stop_playback >, a_row < Paused , open_close , Open , &p::stop_and_open > // +---------+-------------+---------+---------------------+----------------------+ > {}; // Replaces the default no-transition response. template <class FSM,class Event> void no_transition(Event const& e, FSM&,int state) { std::cout << "no transition from state " << state << " on event " << typeid(e).name() << std::endl; } }; typedef msm::back::state_machine<player_> player; // // Testing utilities. // static char const* const state_names[] = { "Stopped", "Open", "Empty", "Playing", "Paused" }; void pstate(player const& p) { std::cout << " -> " << state_names[p.current_state()[0]] << std::endl; } } #ifndef WIN32 long mtime(struct timeval& tv1,struct timeval& tv2) { return (tv2.tv_sec-tv1.tv_sec) *1000000 + ((tv2.tv_usec-tv1.tv_usec)); } #endif int main() { // for timing #ifdef WIN32 LARGE_INTEGER res; ::QueryPerformanceFrequency(&res); LARGE_INTEGER li,li2; #else struct timeval tv1,tv2; gettimeofday(&tv1,NULL); #endif test_fsm::player p2; p2.start(); // for timing #ifdef WIN32 ::QueryPerformanceCounter(&li); #else gettimeofday(&tv1,NULL); #endif for (int i=0;i</*100*//*1000000*/10000000;++i) { p2.process_event(test_fsm::open_close()); p2.process_event(test_fsm::open_close()); p2.process_event(test_fsm::cd_detected()); p2.process_event(test_fsm::play()); p2.process_event(test_fsm::pause()); // go back to Playing p2.process_event(test_fsm::end_pause()); p2.process_event(test_fsm::pause()); p2.process_event(test_fsm::stop()); // event leading to the same state p2.process_event(test_fsm::stop()); p2.process_event(test_fsm::open_close()); p2.process_event(test_fsm::open_close()); } #ifdef WIN32 ::QueryPerformanceCounter(&li2); #else gettimeofday(&tv2,NULL); #endif #ifdef WIN32 std::cout << "msm took in s:" << (double)(li2.QuadPart-li.QuadPart)/res.QuadPart <<"\n" <<std::endl; #else std::cout << "msm took in us:" << mtime(tv1,tv2) <<"\n" <<std::endl; #endif return 0; } #include <boost/statechart/event.hpp> #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/statechart/transition.hpp> #include "boost/mpl/list.hpp" #include <vector> #include <iostream> #ifdef WIN32 #include "windows.h" #else #include <sys/time.h> #endif namespace sc = boost::statechart; namespace mpl = boost::mpl; namespace test_sc { //events struct play : sc::event< play > {}; struct end_pause : sc::event< end_pause > {}; struct stop : sc::event< stop > {}; struct pause : sc::event< pause > {}; struct open_close : sc::event< open_close > {}; struct cd_detected : sc::event< cd_detected > {}; struct Empty; struct Open; struct Stopped; struct Playing; struct Paused; // SM struct player : sc::state_machine< player, Empty > { void open_drawer(open_close const&) { /*std::cout << "player::open_drawer\n";*/ } void store_cd_info(cd_detected const& cd) {/*std::cout << "player::store_cd_info\n";*/ } void close_drawer(open_close const&) { /*std::cout << "player::close_drawer\n";*/ } void start_playback(play const&) { /*std::cout << "player::start_playback\n";*/ } void stopped_again(stop const&) {/*std::cout << "player::stopped_again\n";*/} void stop_playback(stop const&) { /*std::cout << "player::stop_playback\n";*/ } void pause_playback(pause const&) { /*std::cout << "player::pause_playback\n"; */} void stop_and_open(open_close const&) { /*std::cout << "player::stop_and_open\n";*/ } void resume_playback(end_pause const&) { /*std::cout << "player::resume_playback\n";*/ } }; struct Empty : sc::simple_state< Empty, player > { Empty() { /*std::cout << "entering Empty" << std::endl;*/ } // entry ~Empty() { /*std::cout << "leaving Empty" << std::endl;*/ } // exit typedef mpl::list< sc::transition< open_close, Open, player, &player::open_drawer >, sc::transition< cd_detected, Stopped, player, &player::store_cd_info > > reactions; }; struct Open : sc::simple_state< Open, player > { Open() { /*std::cout << "entering Open" << std::endl;*/ } // entry ~Open() { /*std::cout << "leaving Open" << std::endl;*/ } // exit typedef sc::transition< open_close, Empty, player, &player::close_drawer > reactions; }; struct Stopped : sc::simple_state< Stopped, player > { Stopped() { /*std::cout << "entering Stopped" << std::endl;*/ } // entry ~Stopped() { /*std::cout << "leaving Stopped" << std::endl;*/ } // exit typedef mpl::list< sc::transition< play, Playing, player, &player::start_playback >, sc::transition< open_close, Open, player, &player::open_drawer >, sc::transition< stop, Stopped, player, &player::stopped_again > > reactions; }; struct Playing : sc::simple_state< Playing, player > { Playing() { /*std::cout << "entering Playing" << std::endl;*/ } // entry ~Playing() { /*std::cout << "leaving Playing" << std::endl;*/ } // exit typedef mpl::list< sc::transition< stop, Stopped, player, &player::stop_playback >, sc::transition< pause, Paused, player, &player::pause_playback >, sc::transition< open_close, Open, player, &player::stop_and_open > > reactions; }; struct Paused : sc::simple_state< Paused, player > { Paused() { /*std::cout << "entering Paused" << std::endl;*/ } // entry ~Paused() { /*std::cout << "leaving Paused" << std::endl;*/ } // exit typedef mpl::list< sc::transition< end_pause, Playing, player, &player::resume_playback >, sc::transition< stop, Stopped, player, &player::stop_playback >, sc::transition< open_close, Open, player, &player::stop_and_open > > reactions; }; } #ifndef WIN32 long mtime(struct timeval& tv1,struct timeval& tv2) { return (tv2.tv_sec-tv1.tv_sec) *1000000 + ((tv2.tv_usec-tv1.tv_usec)); } #endif int main() { test_sc::player p; p.initiate(); // for timing #ifdef WIN32 LARGE_INTEGER res; ::QueryPerformanceFrequency(&res); LARGE_INTEGER li,li2; ::QueryPerformanceCounter(&li); #else struct timeval tv1,tv2; gettimeofday(&tv1,NULL); #endif for (int i=0;i</*100*//*1000000*/10000000;++i) { p.process_event(test_sc::open_close()); p.process_event(test_sc::open_close()); p.process_event(test_sc::cd_detected()); p.process_event(test_sc::play()); p.process_event(test_sc::pause()); // go back to Playing p.process_event(test_sc::end_pause()); p.process_event(test_sc::pause()); p.process_event(test_sc::stop()); // event leading to the same state p.process_event(test_sc::stop()); p.process_event(test_sc::open_close()); p.process_event(test_sc::open_close()); } #ifdef WIN32 ::QueryPerformanceCounter(&li2); #else gettimeofday(&tv2,NULL); #endif #ifdef WIN32 std::cout << "sc took in s:" << (double)(li2.QuadPart-li.QuadPart)/res.QuadPart <<"\n" <<std::endl; #else std::cout << "sc took in us:" << mtime(tv1,tv2) <<"\n" <<std::endl; #endif return 0; } // player.cpp : Defines the entry point for the console application. // #ifdef WIN32 #include "windows.h" #else #include <sys/time.h> #endif #include "Player.h" int main() { // for timing #ifdef WIN32 LARGE_INTEGER res; ::QueryPerformanceFrequency(&res); LARGE_INTEGER li,li2; #else struct timeval tv1,tv2; gettimeofday(&tv1,NULL); #endif Player p; p.startBehavior(); // for timing #ifdef WIN32 ::QueryPerformanceCounter(&li); #else gettimeofday(&tv1,NULL); #endif for (int i=0;i</*100*//*1000000*/10000000;++i) { open_close oc1; p.handleEvent(&oc1); open_close oc2; p.handleEvent(&oc2); cd_detected cd; p.handleEvent(&cd); play pl; p.handleEvent(&pl); pause pa1; p.handleEvent(&pa1); // go back to Playing end_pause ep; p.handleEvent(&ep); pause pa2; p.handleEvent(&pa2); stop st1; p.handleEvent(&st1); // event leading to the same state stop st2; p.handleEvent(&st2); open_close oc3; p.handleEvent(&oc3); open_close oc4; p.handleEvent(&oc4); } #ifdef WIN32 ::QueryPerformanceCounter(&li2); #else gettimeofday(&tv2,NULL); #endif #ifdef WIN32 std::cout << "rhapsody took in s:" << (double)(li2.QuadPart-li.QuadPart)/res.QuadPart <<"\n" <<std::endl; #else std::cout << "rhapsody took in us:" << mtime(tv1,tv2) <<"\n" <<std::endl; #endif //p.handleEvent(new open_close); return 0; } /******************************************************************** Rhapsody : 7.5 Login : Component : DefaultComponent Configuration : DefaultConfig Model Element : Default //! Generated Date : Wed, 2, Dec 2009 File Path : DefaultComponent\DefaultConfig\Default.cpp *********************************************************************/ //## auto_generated #include "Default.h" //## auto_generated #include "Player.h" //## package Default //## event cd_detected() cd_detected::cd_detected() { setId(cd_detected_Default_id); } bool cd_detected::isTypeOf(short id) const { return (cd_detected_Default_id==id); } //## event stop() stop::stop() { setId(stop_Default_id); } bool stop::isTypeOf(short id) const { return (stop_Default_id==id); } //## event play() play::play() { setId(play_Default_id); } bool play::isTypeOf(short id) const { return (play_Default_id==id); } //## event pause() pause::pause() { setId(pause_Default_id); } bool pause::isTypeOf(short id) const { return (pause_Default_id==id); } //## event end_pause() end_pause::end_pause() { setId(end_pause_Default_id); } bool end_pause::isTypeOf(short id) const { return (end_pause_Default_id==id); } //## event open_close() open_close::open_close() { setId(open_close_Default_id); } bool open_close::isTypeOf(short id) const { return (open_close_Default_id==id); } /********************************************************************* File Path : DefaultComponent\DefaultConfig\Default.cpp *********************************************************************/ /********************************************************************* Rhapsody : 7.5 Login : Component : DefaultComponent Configuration : DefaultConfig Model Element : Default //! Generated Date : Wed, 2, Dec 2009 File Path : DefaultComponent\DefaultConfig\Default.h *********************************************************************/ #ifndef Default_H #define Default_H //## auto_generated #include <oxf\oxf.h> //## auto_generated #include <oxf\event.h> //## auto_generated class Player; //#[ ignore #define cd_detected_Default_id 18601 #define stop_Default_id 18602 #define play_Default_id 18603 #define pause_Default_id 18604 #define end_pause_Default_id 18605 #define open_close_Default_id 18606 //#] //## package Default //## event cd_detected() class cd_detected : public OMEvent { //// Constructors and destructors //// public : //## auto_generated cd_detected(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event stop() class stop : public OMEvent { //// Constructors and destructors //// public : //## auto_generated stop(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event play() class play : public OMEvent { //// Constructors and destructors //// public : //## auto_generated play(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event pause() class pause : public OMEvent { //// Constructors and destructors //// public : //## auto_generated pause(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event end_pause() class end_pause : public OMEvent { //// Constructors and destructors //// public : //## auto_generated end_pause(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; //## event open_close() class open_close : public OMEvent { //// Constructors and destructors //// public : //## auto_generated open_close(); //// Framework operations //// //## statechart_method bool isTypeOf(short id) const; }; #endif /********************************************************************* File Path : DefaultComponent\DefaultConfig\Default.h *********************************************************************/ /******************************************************************** Rhapsody : 7.5 Login : Component : DefaultComponent Configuration : DefaultConfig Model Element : Player //! Generated Date : Tue, 1, Dec 2009 File Path : DefaultComponent\DefaultConfig\Player.cpp *********************************************************************/ //## auto_generated #include <oxf\omthread.h> //## auto_generated #include "Player.h" //## package Default //## class Player Player::Player(IOxfActive* theActiveContext) { setActiveContext(theActiveContext, false); initStatechart(); } Player::~Player() { } bool Player::startBehavior() { bool done = false; done = OMReactive::startBehavior(); return done; } void Player::initStatechart() { rootState_subState = OMNonState; rootState_active = OMNonState; } void Player::rootState_entDef() { { rootState_subState = Empty; rootState_active = Empty; } } IOxfReactive::TakeEventStatus Player::rootState_processEvent() { IOxfReactive::TakeEventStatus res = eventNotConsumed; switch (rootState_active) { case Empty: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 12 //open_drawer; //#] rootState_subState = Open; rootState_active = Open; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(cd_detected_Default_id)) { //#[ transition 1 //store_cd_info; //#] rootState_subState = Stopped; rootState_active = Stopped; res = eventConsumed; } } break; case Open: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 11 //close_drawer; //#] rootState_subState = Empty; rootState_active = Empty; res = eventConsumed; } } break; case Stopped: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 9 //open_drawer; //#] rootState_subState = Open; rootState_active = Open; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(stop_Default_id)) { //#[ transition 2 //stopped_again; //#] rootState_subState = Stopped; rootState_active = Stopped; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(play_Default_id)) { //#[ transition 3 //start_playback; //#] rootState_subState = Playing; rootState_active = Playing; res = eventConsumed; } } break; case Paused: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 8 //stop_and_open; //#] rootState_subState = Open; rootState_active = Open; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(stop_Default_id)) { //#[ transition 7 //stop_playback; //#] rootState_subState = Stopped; rootState_active = Stopped; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(end_pause_Default_id)) { //#[ transition 6 //resume_playback; //#] rootState_subState = Playing; rootState_active = Playing; res = eventConsumed; } } break; case Playing: { if(IS_EVENT_TYPE_OF(open_close_Default_id)) { //#[ transition 10 //stop_and_open; //#] rootState_subState = Open; rootState_active = Open; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(stop_Default_id)) { //#[ transition 4 //stop_playback; //#] rootState_subState = Stopped; rootState_active = Stopped; res = eventConsumed; } else if(IS_EVENT_TYPE_OF(pause_Default_id)) { //#[ transition 5 //pause_playback; //#] rootState_subState = Paused; rootState_active = Paused; res = eventConsumed; } } break; default: break; } return res; } /********************************************************************* File Path : DefaultComponent\DefaultConfig\Player.cpp *********************************************************************/ /********************************************************************* Rhapsody : 7.5 Login : Component : DefaultComponent Configuration : DefaultConfig Model Element : Player //! Generated Date : Tue, 1, Dec 2009 File Path : DefaultComponent\DefaultConfig\Player.h *********************************************************************/ #ifndef Player_H #define Player_H //## auto_generated #include <oxf\oxf.h> //## auto_generated #include "Default.h" //## auto_generated #include <oxf\omreactive.h> //## auto_generated #include <oxf\state.h> //## auto_generated #include <oxf\event.h> //## package Default //## class Player class Player : public OMReactive { //// Constructors and destructors //// public : //## auto_generated Player(IOxfActive* theActiveContext = 0); //## auto_generated ~Player(); //// Additional operations //// //## auto_generated virtual bool startBehavior(); protected : //## auto_generated void initStatechart(); //// Framework operations //// public : // rootState: //## statechart_method inline bool rootState_IN() const; //## statechart_method virtual void rootState_entDef(); //## statechart_method virtual IOxfReactive::TakeEventStatus rootState_processEvent(); // Stopped: //## statechart_method inline bool Stopped_IN() const; // Playing: //## statechart_method inline bool Playing_IN() const; // Paused: //## statechart_method inline bool Paused_IN() const; // Open: //## statechart_method inline bool Open_IN() const; // Empty: //## statechart_method inline bool Empty_IN() const; //// Framework //// protected : //#[ ignore enum Player_Enum { OMNonState = 0, Stopped = 1, Playing = 2, Paused = 3, Open = 4, Empty = 5 }; int rootState_subState; int rootState_active; //#] }; inline bool Player::rootState_IN() const { return true; } inline bool Player::Stopped_IN() const { return rootState_subState == Stopped; } inline bool Player::Playing_IN() const { return rootState_subState == Playing; } inline bool Player::Paused_IN() const { return rootState_subState == Paused; } inline bool Player::Open_IN() const { return rootState_subState == Open; } inline bool Player::Empty_IN() const { return rootState_subState == Empty; } #endif /********************************************************************* File Path : DefaultComponent\DefaultConfig\Player.h *********************************************************************/ CD-Player example Each test was executed several times. The times are accumulated and divided by the amount of executed test runs to build an median value. ============================================================================== 100 loops of 11 transitions (10 runs) sc took in s:0.00039614 sc took in s:0.000461721 sc took in s:0.000461721 sc took in s:0.000553632 sc took in s:0.000485257 sc took in s:0.000415276 sc took in s:0.000773003 sc took in s:0.000579124 sc took in s:0.000709448 sc took in s:0.00036513 --> ~ 0.000520045 s msm took in s:1.04762e-005 msm took in s:8.93968e-006 msm took in s:8.24127e-006 msm took in s:8.31111e-006 msm took in s:9.91746e-006 msm took in s:2.31873e-005 msm took in s:2.22095e-005 msm took in s:8.38095e-006 msm took in s:1.66222e-005 msm took in s:2.08825e-005 --> ~ 1.37E-05 s rhapsody took in s:4.5746e-005 rhapsody took in s:5.28e-005 rhapsody took in s:8.73714e-005 rhapsody took in s:8.73016e-005 rhapsody took in s:5.27302e-005 rhapsody took in s:6.19492e-005 rhapsody took in s:5.27302e-005 rhapsody took in s:6.92825e-005 rhapsody took in s:4.59556e-005 rhapsody took in s:5.27302e-005 --> ~ 6.09E-05 s Result for 100 * 11 transitions: SC 0.5200 ms Rhapsody 0.0609 ms MSM 0.0137 ms ============================================================================== 1000000 loops of 11 transitions (3 runs) sc took in s:1.93943 sc took in s:1.93943 sc took in s:1.99496 --> ~ 1.95794 s msm took in s:0.0741568 msm took in s:0.0988071 msm took in s:0.0772959 --> ~ 0.08341 s rhapsody took in s:0.453220 rhapsody took in s:0.541500 rhapsody took in s:0.474185 --> ~ 0.48964 s Result for 1000000 * 11 transitions: SC 1.95794 s Rhapsody 0.48964 s MSM 0.08341 s ============================================================================== 10000000 loops of 11 transitions (3 runs) sc took in s:19.5358 sc took in s:19.6668 sc took in s:19.7063 --> ~ 19.6363 s msm took in s:1.059320 msm took in s:0.792874 msm took in s:0.870431 --> ~ 0.90754 s rhapsody took in s:4.95632 rhapsody took in s:5.02131 rhapsody took in s:4.87564 --> ~ 4.95109 s Result for 10000000 * 11 transitions: SC 19.63630 s Rhapsody 4.95109 s MSM 0.90754 s

1 0

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 02 Dec '09

02 Dec '09

I understand we'll never manage to please everyone. Apologies. For now I am settling on the boost::convert interface as I very much agree with the arguments Robert's put forward for it and I feel there is the least disagreement around this interface. Surely boost::convert() has issues of its own. However, I feel the path (convert::to_string->convert::to->convert) how I myself arrived to this logical (IMHO) conclusion seemed reasonable. More so, despite its subtle (to some) directionality the interface has proven to work (as it is essentially the same interface as for lexical_cast). You cannot deny that I made considerable sacrifices (my pets "string" namespace and "to/from" are gone, something I was ready to die :-) for yesterday...). I am hoping the others could make some concessions as well and we would settle on boost::convert()... for now. If some other issues pop up that we missed so far, we'll revisit the issue. It is because I would very much like to move forward and start looking at the functionality and implementation. Do you think it is possible or I am rushing things again? I somewhat cleaned up the implementation (removed to/from, etc.). However, before going forward I'd like to discuss one important thing that's been bugging me since Scott brought it up. Namely, all conversions are now implemented as discriminated functions like // string-to-type conversion template<class TypeOut, class StringIn> typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, detail::from_string<StringIn, TypeOut> >::type convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()) { return detail::from_string<StringIn, TypeOut>(from_str, default_value); } However, Scott mentioned that and I feel that might be cleaner if we could implement it as namespace boost { template<class TypeOut, class TypeIn, class Enable =void> class convert; } Then for every conversion we'll be able to encapsulate *complete* implementation in the respective specialization class. Like for string-to-type template< class TypeOut, class StringIn, typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, void>::type> class convert { convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()); }; The reason I like it is that it eliminates other support/intermediate classes (like something used-to-called boost::string::value<...> and detail::from_string) and we can do int i = convert(str, -1); // Nothing changed. a 'convert' instance created on the stack and converted to 'int'. convert<int, string> checked(str, -1); // named 'convert' is created. convert<int, string> checked = convert(str, -1); // the same but some might like this syntax better. if (checked.good()) success // we can check the success as ussed to with boost::string::value It feels that approach gives us considerably more room for expansion as some special conversions will be able to have methods only specific to that particular conversion. For this approach to work with algorithms we'll need class convert { static TypeOut apply(TypeIn const&); }; and then std::transform( ints.begin(), ints.end(), std::back_inserter(strings), convert<string, int>::apply); Thanks, Vladimir.

9 63

[spirit/karma] missing specialization for char types in numeric_utils.hpp
by Robert.Macketanz＠rohde-schwarz.com 02 Dec '09

02 Dec '09

Hi, while testing some stuff using the karma generator like this >>> template <typername T> void do_calculations() { char buf [65]; // this is enough to display any of the numbers T val = value_getter(); char * ptr = buf; boost::spirit::karma::generate( ptr, boost::spirit::karma::int_, val ); *ptr='\0'; std::cout << buf << std::endl; } <<< the compiler (MSVC 2005) gave me errors when T was any of the "char" family about ambiguous overloads for "fabs()". After adding the lines BOOST_SPIRIT_ABSOLUTE_VALUE(signed char, unsigned char); BOOST_SPIRIT_ABSOLUTE_VALUE(char, unsigned char); and BOOST_SPIRIT_ABSOLUTE_VALUE_UNSIGNED(unsigned char); in boost\spirit\home\karma\numeric\detail\numeric_utils.hpp , the problem went away. (This is with boost 1.41.0) I am not sure if this is the proper way to fix this or whether we'd need to regard the possibly different implementations for "char" in various compilers. If this really fuixes this bug, could anyone please commit the changes to the next release? Cheers, Robert

2 1

[MSM] Review
by Kenny Riddile 01 Dec '09

01 Dec '09

This is my first time reviewing a Boost submission, so I'll do my best :) First of all, I'm not going to compare MSM to StateChart for two reasons: 1) I haven't used StateChart 2) I see them both as being individually useful, even if they can solve some of the same problems. Is there not overlapping functionality in many STL containers? Still, they're all well-suited to particular problems. - What is your evaluation of the design? I have been using MSM on and off since January 2009 and have seen the design evolve as new features were added. I first used it in a simple iPhone game which required a way to "update" an FSM's current state. This feature was generalized into the current ability to "visit" the current state. The more I used the library and communicated with the author, it became clear that the design, and any changes to it, were thoroughly thought-out. I especially like the clarity with which one defines an FSM (specifically the transition table). The fact that a single instance of each state is default-constructed and bound to the FSM's lifetime is something that should be carefully considered when deciding if MSM fits with a particular use-case. It was suggested in another review thread that a mechanism to optionally pass prototypical states in to a new FSM be added so that states didn't have to be default-constructible. I agree with this suggestion. Aside from that, the design has made it intuitive to accomplish everything I've tried to do with MSM. - What is your evaluation of the implementation? I've only looked at the implementation a few times over the last year when trying to track down apparent bugs (which were all promptly fixed). Aside from those instances, I try to avoid looking at things that hurt my brain. I've seen the code in "C++ Template Metaprogramming" that MSM is based on, and consider it sound. Is there a test suite for MSM? Do these tests pass on all platforms officially supported by Boost? - What is your evaluation of the documentation? The documentation was invaluable when I was first playing around with MSM. The examples are concise and clearly demonstrate what they are meant to. I would prefer that the documentation be broken into multiple pages similar to other released libraries. - What is your evaluation of the potential usefulness of the library? I think MSM is useful because I have found uses for it. My only significant experience with MSM has been in mobile game development, and I have used MSM in one shipped iPhone game. It has worked very well in particular situations, such as simple AI for a single game entity. The "staticness" of an MSM FSM is advantageous in this example, since constantly creating and destroying states can noticeably affect performance when a large number of entities are present in a simulation. Conversely, I wouldn't use MSM to control the high-level application flow of a game. I've found that the persisted states and default-constructibility requirement end up being hoops to jump through that just aren't worth it in this case where state transition speed isn't a concern. Long compile times in the name of run-time performance have never bothered me either. I can always upgrade my development machine, but a customer can't upgrade their iPhone. - Did you try to use the library? With what compiler? Yes. I've used MSM with MSVC9 and GCC compiling for the iPhone. - Did you have any problems? I've found a bug or two when using MSM, but they were always fixed promptly and correctly. There is of course the transition table size limitation imposed by mpl::vector and the compiler. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I've used an earlier version of the library in a shipped product, and I've played with recent versions prior to the review. - Are you knowledgeable about the problem domain? I understand how FSMs work and what they can be used for. - Do you think the library should be accepted as a Boost library? Yes, I absolutely think MSM should be accepted into Boost, and will continue to use it regardless of the review results. I would like to see the documentation restructured and the default-constructibility requirement for states removed via the means already described. My vote for acceptance is not contingent on these requests.

1 0

Re: [boost] [msm] Review
by Christophe Henry 01 Dec '09

01 Dec '09

Hi Simon, >I agree that the feature can be costly. I don't have a lot of experience with fsms with very tight time constraints though - > SC seems to meet our time requirements (ie the state machine itself is much faster than the other operations we perform). Sure but Msm is a general-purpose library and can therefore not allow itself not to be performant. Quite a few Msm users are from the embedded world and performance does matter there (anyway, this is C++ so it always does, right? ;-) ). Msm also proves that thanks to metaprogramming, a library can bring ease of use and speed. >>+ your state data is always available. In my experience, state data is >>not only needed in the entry or when the next event is processed, but >>during a transition or even at some time after a transition. This >>means, that you have, during a transition, access to data from the >>source or the target state. > This is simple to emulate in SC. The state data can be owned by the outer state, or by the state_machine itself. Sure, but then the statechart documentation itself makes a pretty good point why this is less than ideal(http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/faq.html#Sta…. In short, this workaround means that some data saved this way in the top-level fsm will only have a meaning in some of the states of this fsm. Doesn't this pretty much defeat the concept of state local storage itself? >>+ combined with the visitor, you can at any time access data from the >>currently active state and build a generic way to do something with >>state data. >Granted. Personally though, I prefer to keep my fsm opaque, and force the use of events and actions > to update and monitor the fsm respectively. Any other method (in our application) is a violation of the desired encapsulation. I should have explained a bit better. What you write is exactly what the visitor concept is for. It allows you to delegate to the active state(s) an action to execute at any time, without even needing an event. Thus you keep your fsm opaque and more robust. And all this happens without rtti or virtual calls. >IMO the lack of state local storage is actually a relatively minor issue. The big ticket issue for me is its ability >(or rather, the compiler's ability) to create large state machines. With SC, I might create a 50 transition state machine. >Over time, normal maintenance might add another 10 or 20 transitions. This isn't a big deal. >However, I'd be less likely to start developing such a state machine with msm for fear that any additional transitions might push the compiler 'over the edge'. Granted, the limit is, for the moment, the compiler. I managed yesterday 150 transitions with g++4.3. If Msm becomes part of Boost and we report to Microsoft that g++ is beating them that much, they might find some motivation to fix their bug. If you read the beginning of this thread again (the review), you'll see that the reviewer managed 15 states and 80 transitions with VC9, which already starts being a reasonable-sized state machine. Msm is clearly not only for very small machines. >So for medium to large state machines, I would choose SC. > For very small state machines, I might be tempted to choose a C style hand written state machine > to avoid the learning overhead for such a trivial application (though Euml is cool enough that I might overcome that). As you already seem to use SC quite much, learning Msm should not be such a large overhead. If you try, please let me know how it went. And if eUML is tempting you to use Msm, then it did its job :) Christophe

2 1

[fiber] new version in vault
by Oliver Kowalke 01 Dec '09

01 Dec '09

I've uploaded a new version of boost.fiber - main features are: - multiple schedulers can be used in one thread - user can provide its own scheduler implementation as template argument to class scheduler - classes disable_interruption and restore_interruption moved into namespace boost::this_fiber regards, Oliver

6 29

BOOST_MSVC vs. _MSC_VER wrt #pragma warning
by Emil Dotchevski 01 Dec '09

01 Dec '09

I understand that BOOST_MSVC is needed to detect MSVC because other compilers besides MSVC define _MSC_VER. But what about #ifdefing #pragma warning, should it use _MSC_VER or BOOST_MSVC? The reason why the ifdefing is needed is to prevent GCC and other compilers issuing a warning about #pragma warning, but presumably compilers that have _MSC_VER defined wouldn't warn about that, would they? -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

2 1

[1.42.0] Release branch open for merges
by Beman Dawes 01 Dec '09

01 Dec '09

The release branch (https://svn.boost.org/svn/boost/branches/release) is open for merging all stable changes from trunk, 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: http://svn.boost.org/trac/boost/wiki/ReleaseSchedule Release practices for developers: http://svn.boost.org/trac/boost/wiki/ImprovingPractices -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus

3 3

[msm] Review
by Christophe Henry 01 Dec '09

01 Dec '09

Hi Juraj, First of all, thank you for being the first one to write a review. I imagine it's not an easy thing. Thank you also for bringing a few very interesting points to the discussion. I'm happy to build on them and hope to finally start some discussion. >MSM does lack some of the SC functionality. >There is no state-local storage in SC sense, as all states are >constructed when main state machine is constructed. This can be easily >worked around though. As this point is being brought for the second time, I'd like to spend some time on it. You already have state local storage with msm, just not like with SC. Like SC, msm defines states as classes, meaning they can have data. There is however one important difference with SC. Msm builds all the states upon state machine creation. States are not destroyed until state machine destruction. This has advantages and disadvantages: - states must be default-constructible - you might need to heap allocate the state data if you cannot initialize it at state construction. + speed: states don't need to be constructed again and again. Constructing a state (and its attributes) each time it becomes active can be costly, even if memory allocation can be optimized. + your state data is always available. In my experience, state data is not only needed in the entry or when the next event is processed, but during a transition or even at some time after a transition. This means, that you have, during a transition, access to data from the source or the target state. + combined with the visitor, you can at any time access data from the currently active state and build a generic way to do something with state data. + you can build examples like the iPodSearch where states keep iterators to some container, thus keeping information from an iteration to the next one. + you avoid having data released inside a destructor. Knowing that destructors should not throw, it makes your life easier. + on_entry is templatized, giving you more leeway to add event-specific handling. + your event data is not lost upon state entry Msm's handling is hard to emulate with SC, on the other hand, SC's handling is easy to emulate with Msm. It has its drawbacks but all considered, I think it is a superior solution. >It is impossible to stop event from propagation (SCs discard_event()) >without actually changing state. It is true. At the moment you cannot. Actually, I don't think UML foresees this possibility. OTOH, I think it is an interesting one and will be happy to borrow it from SC. I think that using the transition table is one of Msm's biggest strengths so I offer to add a row or a functor allowing event propagation to be stopped. You could even give it a guard, thus allowing fine-grained transition conflict resolution. > You cannot conditionally defer an event. Again you're right. I think UML doesn't foresee this either, but I also like it and will also borrow it from SC. You offered the idea of a d_row (deferred row) or dg_row (the same with a guard). I think it is the best possibility with the simplest front-end and makes deferred events a first-class citizen, being in the transition table and coming into play during conflict resolution. For the functor and eUML front-ends I think it could be done as an execution row. Something like: State1() + Event1() / defer_() Seems an interesting starting point. >There seem to be some differences on how event deferral is handled when > composite states are used. This part is a still bit mysterious to me. I will add a part about the dispatch algorithm to the documentation. >Aesthetically - I'm not a great fan of one big fat html documentation > and would prefer to have it broken down and cross-referenced as most > boost libraries docs are organized, but this is just a minor issue. If Msm is accepted into Boost, I'd probably move to BoostBook anyway, so this will be done at this time. > The author seems masochistic enough to try to tackle this. :) Sure :) and I don't mind the term at all :) Thanks for the review and the very good points you brought during the last weeks! Regards, Christophe

3 2

Re: [boost] [msm] Review
by Christophe Henry 30 Nov '09

30 Nov '09

Hi Sebastian, > I know nothing about MSM and very little about state machines in > general, but if all states are constructed at SM instantiation time, > would it be possible to pass the SM constructor a tuple of constructed > states that are copied/moved into the internal states? In theory it'd be possible because MSM stores the states in a fusion::set, which can be constructed from a forward sequence. And according to the fusion doc, a tuple can be adapted to a forward sequence. So I suppose it'd work. The problem would be to find an acceptable syntax because a msm::back::state_machine already has a templated constructor used to pass arguments to the front-end, for example: struct player_ : public msm::front::state_machine_def<player_> { player_(int some_value){…} } typedef msm::back::state_machine<player_ > player; player p(3); So we'd need to pass the tuple as extra argument, the first or the last one and add a bit of SFINAE to check if this argument is a tuple. > Would it be worth the effort? I don't know. It has never been requested so it's hard to know, but I find the idea quite interesting. Let's make a quick poll (which I'll shamelessly use as a way to make the review slightly more alive). Would someone make use of this feature? Christophe

1 0

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 30 Nov '09

30 Nov '09

> Why the transition table uses non-type template parameter for actions > and guards instead of using a agreed function name for handling events > in states? Thinking further about it, do you mean like Statechart's react function? It'd be possible of course, I even imagined adding a SC-like frontend. The problem is, when your fsm becomes bigger, you might find out that following what your fsm is doing is harder because you have to look in many different places in your code. On the opposite, having more information in the transition table will help you have a better view of the structure of your state machine when it gets bigger. The other drawback (in my opinion) of SC's react, is that it automatically forces on you some forward state declaration as a state will need to know all of its possible followers. It also prevents reuse of states or composites in another fsm. And finally, my biggest worry about such a react function is that it becomes harder to build a GUI which can generate your code from a diagram and next to impossible to parse back the code into a model, so it 's not an ideal approach for Model-Driven development. A transition table, on the other side, makes it pretty simple to build a tool whose job is model <-> code development (both ways). Regards, Christophe

1 0

[program_options] Formatting; split at space
by Chard 30 Nov '09

30 Nov '09

Function: format_paragraph File: options_description.cpp, line 423: if (last_space != line_begin) { // is last_space within the second half ot the // current line if ((unsigned)distance(last_space, line_end) < (line_length - indent) / 2) // "- indent" ? { line_end = last_space; } } I'm given to understand that the code around here is designed to split the description at a space, iff the space occurs at least half-way through the description text. The code currently subtracts the indent from the line_length, where the line_length (within format_paragraph) represents the space available for the description (indent has already been subtracted from line_length at the beginning of format_paragraph). The result is that the longer the option names, the less chance of the split occurring at a space within the description. Was this the intention? E.g. if an option is 40 chars long, then there is no chance of it splitting at a space (for 80 column default).

2 1

property_tree equal_range causes compiler error
by YuQian Zhou (周宇前) 30 Nov '09

30 Nov '09

add to boost/libs/property_tree/examples/debug_settings.cpp: line 55 pt.equal_range("debug.level"); then compile: ~/boost/libs/property_tree/examples$ g++ -I../../../ debug_settings.cpp -o debug_settings ../../../boost/property_tree/detail/ptree_implementation.hpp: In member function ‘std::pair<typename boost::property_tree::basic_ptree<Key, Data, KeyCompare>::assoc_iterator, typename boost::property_tree::basic_ptree<Key, Data, KeyCompare>::assoc_iterator> boost::property_tree::basic_ptree<Key, Data, KeyCompare>::equal_range(const Key&) [with Key = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, Data = std::basic_string<char, std::char_traits<char>, std::allocator<char> >, KeyCompare = std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >]’: debug_settings.cpp:55: instantiated from here ../../../boost/property_tree/detail/ptree_implementation.hpp:449: error: ‘class boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > > > >’ has no member named ‘base’ ../../../boost/property_tree/detail/ptree_implementation.hpp:449: error: ‘class boost::multi_index::detail::bidir_node_iterator<boost::multi_index::detail::ordered_index_node<boost::multi_index::detail::index_node_base<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > >, std::allocator<std::pair<const std::basic_string<char, std::char_traits<char>, std::allocator<char> >, boost::property_tree::basic_ptree<std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::basic_string<char, std::char_traits<char>, std::allocator<char> >, std::less<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > > > > > > >’ has no member named ‘base’

2 1

Can someone with Visual Studio take a look at bug #1076, please?
by Marshall Clow 30 Nov '09

30 Nov '09

There is a test case attached to the bug: https://svn.boost.org/trac/boost/ticket/1076 Thanks! -- Marshall

3 3

Status of the bug sprint....
by Marshall Clow 30 Nov '09

30 Nov '09

for Thursday, November 19th. Yesterday, 859 open tickets. Today, 861 open tickets. That's not the direction that we want to go, folks. ;-) -- Marshall

7 26

Compiler Warnings Tests
by Paul A. Bristow 30 Nov '09

30 Nov '09

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users-bounces@lists.boost.org] > On Behalf Of Robert Ramey > Sent: Friday, November 27, 2009 5:07 PM > To: boost-users(a)lists.boost.org > Cc: boost(a)lists.boost.org > Subject: Re: [Boost-users] Compiler warnings from Macs, IBM acc, Borland, Comeau, > Metroworks, et al - are they a Problem? > > I know this suggestion has been made but I want to expand a little on it. > > a "library" - warning policy test. This would be just like any other > library as far as the testing system goes. It would have maybe > 10? small compile only tests which would emit warnings or not. > The source would describe which warning is in fact being tested. > > Presumably, the test matrix would permit one to look at the warning > messages. (I'm not sure that the current one does this). > > In anycase, it would permit the test matrix be used to check > the warning status for each warning on each compiler at > a specified warning level. > > I see this as the only way to get a real grip on how these things > vary among the array of compiler's we might use. > > I realize that it would be some work, but I would think it wouldn't > be all that much more - if any - than that which has already been > expended on the wiki. It would have the great advantage of > being relatively free of "maintainence by hand". It would automate > the whole process of determining the status of different compilers > in this area. OK I can see some merit in this (now I understand your proposal a bit more). And I'm starting a new thread for Compiler Warnings Tests The Microsoft docs examples might be a good start? // C4244_level4.cpp // compile with: /W4 == actually warnings = all (warnings = errors will allow normal fail testing if it isn;t possible to check for warnings?) // AND MS extensions off? int aa; unsigned short bb; int main() { int b = 0, c = 0; short a = b + c; // C4244 bb += c; // C4244 bb = bb + c; // C4244 bb += static_cast<unsigned short>(aa); // C4244 bb = bb + static_cast<unsigned short>(aa); // OK } So are you proposing a collection of these, with versions that should compile and others that should not, for example: int main() { int b = 0, c = 0; short a = b + c; // C4244 } and another with int main() { int b = 0, c = 0; short a = static_cast<short>(b + c); // OK - NO C4244 } all run by a jamfile.v2. Or am I still misunderstanding you? Vicente has said he will think about it. I will also give it some more thought. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

4 7

[buiild] stop on first error
by Vladimir Prus 30 Nov '09

30 Nov '09

As of today, if you run: ./bootstrap.sh ./bjam in trunk, then the build will immediately stop on any error. The same is true with bootstrap.bat on Windows. The previously behaviour was to continue building other targets that don't depend on the failed one. The "keep going" behaviour has some good properties, for experienced users, but for new users of Boost, it was sufficiently confusing: - It's easy to miss compilation error, and then you learn that something has failed at the end of build - There's no clean at-the-end summary of what has failed, and what to do - Some users don't even know how to capture build output for further analysis, and the build output, with all the errors, can easily overflow scrollback buffers of console windows The new behaviour is implemented by writing an option into project-config.jam. Anybody who wants the old behaviour can edit that file, or pass --keep-going on the command line. The change does not affect regression tests. - Volodya

3 3

[filesystem][iostreams][program_options] linker issues on msvc
by Alexander Arhipenko 30 Nov '09

30 Nov '09

Guys, We use boost.build not only for building boost but also to create own binary packages. For a long time I observe linker errors on msvc due to lack of usage requirements in Jamfile's. Issue is reproduced when somebody builds executable like this: exe foo : main.cpp /boost/filesystem ; #or /boost/program_options or /boost/iostreams Following trivial patch resolves these issues: Index: libs/program_options/build/Jamfile.v2 =================================================================== --- libs/program_options/build/Jamfile.v2 (revision 57802) +++ libs/program_options/build/Jamfile.v2 (working copy) @@ -1,6 +1,9 @@ project boost/program_options : + usage-requirements + <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1 + : source-location ../src ; @@ -17,4 +20,4 @@ <link>shared:<define>BOOST_PROGRAM_OPTIONS_DYN_LINK=1 # tell source we're building dll's ; Index: libs/filesystem/build/Jamfile.v2 =================================================================== --- libs/filesystem/build/Jamfile.v2 (revision 57802) +++ libs/filesystem/build/Jamfile.v2 (working copy) @@ -11,6 +11,7 @@ project boost/filesystem : source-location ../src : usage-requirements # pass these requirement to dependents (i.e. users) + <library>/boost/system <link>shared:<define>BOOST_FILESYSTEM_DYN_LINK=1 <link>static:<define>BOOST_FILESYSTEM_STATIC_LINK=1 ; @@ -29,4 +30,4 @@ : ; Index: libs/iostreams/build/Jamfile.v2 =================================================================== --- libs/iostreams/build/Jamfile.v2 (revision 57802) +++ libs/iostreams/build/Jamfile.v2 (working copy) @@ -7,7 +7,11 @@ # See http://www.boost.org/libs/iostreams for documentation. -project /boost/iostreams : source-location ../src ; +project /boost/iostreams + : usage-requirements + <link>shared:<define>BOOST_IOSTREAMS_DYN_LINK=1 + : source-location ../src + ; # The biggest trick in this Jamfile is to link to zlib and bzip2 when # needed. To configure that, a number of variables are used, which must Regards

3 9

Crazy Borland/Codegear long long behaviour?
by John Maddock 30 Nov '09

30 Nov '09

I'm having a load of trouble getting Boost.Integer to play nice with the Borland/Codegear compilers, for example given: void print_val(long long l) { std::cout << std::hex << static_cast<int>((l & 0xFFFFFFFF00000000LL) >> 32); std::cout << std::hex << static_cast<int>((l & 0xFFFFFFFFLL)) << std::endl; } And then: static const long long MaxValue = SCHAR_MAX; static const long long sll = _LLONG_MAX; const long long cll = _LLONG_MAX; long long ll = _LLONG_MAX; BOOST_TEST(MaxValue <= ::boost::integer_traits<boost::long_long_type>::const_max); // fails BOOST_TEST(MaxValue <= _LLONG_MAX); // passes BOOST_TEST(MaxValue <= sll); //fails BOOST_TEST(MaxValue <= cll); // fails BOOST_TEST(MaxValue <= ll); // passes print_val(_LLONG_MAX); // OK prints 7fffffffffffffff print_val(ll); // OK prints 7fffffffffffffff print_val(sll); // Oh no, prints ffffffffffffffff print_val(cll); // Oh no, prints ffffffffffffffff So as soon as a long long is declared const (whether static or not) it seems to be incapable of actually holding a sensible value!! Anyone got any ideas what's going on or any workarounds? Thanks, John. PS I'm still using Borland-5.8.2, but judging by the test matrix results the latest versions have similar issues.

3 4

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 29 Nov '09

29 Nov '09

Hi Felipe, > Why the transition table uses non-type template parameter for actions > and guards instead of using a agreed function name for handling events > in states? I'm not sure I understand the question. Please excuse (and correct) me if I miss the point. You mean, why not remove action and guards from the transition table and delegate all handling to a state (source or target)? Well, you can do this if you want, as there are already such methods defined, on_entry and on_exit. So theoretically you could use a _row, which has only source state / event / target state and delegate all work to on_entry and on_exit. It would work in some cases. However, you could also have the following: _row< State1, event1, State3>, _row< State2, event2, State3> and maybe _row< State1, event3, State4> Now you have a problem in State1 and 3. State3 can be the target of 2 transitions from 2 states and State1 can be the source of 2 transitions to 2 states. Where to add the common handling? It'll fatally end with some if/else on the event type. If you carefully choose your on_entry/exit, action and guard you will avoid this and get cleaner code with on_entry and on_exit (called each time a state is entered/left independently of the event) doing the work common to all transitions and the action/guard the work specific to one event. To be honest, as on_entry and on_exit are templatized on the event you could use SFINAE to handle event-specific tasks and get rid of actions and guards anyway but SFINAE isn't everybody's tool. If you feel good with them, then sure, why not? > That should get the transition table a lot smaller and maybe even > faster for not using a pointer (though speed-wise, that's a wild > guess). Luckily Msm allows you both ways :) You have a valid point with your wild guess. I'm unsure myself why but if you use the functor-based frontend, which is doing strictly the same, you will see some speed gain (about 20%) compared to the pointer version. I hope I could answer the question satisfactorily. Regards, Christophe

1 0

[config] BOOST_CONSTEXPR and C++0x constexpr
by Vicente Botet Escriba 29 Nov '09

29 Nov '09

Hi, I was wondering if it will be useful to define BOOST_CONSTEXPR as follows #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #else #define BOOST_CONSTEXPR constexpr #endif and if it is correct to use it as for example static BOOST_CONSTEXPR Rep zero(); If this is the case, could this be added to Boost.Config? If not, what I'm missing? Best, Vicente -- View this message in context: http://old.nabble.com/-config--BOOST_CONSTEXPR-and-C%2B%2B0x-constexpr-tp26… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

GGL Review Results
by Hartmut Kaiser 29 Nov '09

29 Nov '09

Hi all, The review of the Generic Geometry Library is over now. We have had vibrant discussions with regards to the library itself. In addition those stirred up a lot of controversial discussion about the Boosts review process. In this review results I will concentrate on the library at hands. Formally this review ended with 12 YES and 2 NO votes. This result reflects the overall discussion and the general consensus of this library being worth to be included into Boost. Based on this result and the discussions the Generic geometry Library has been formally accepted into Boost. It is worth highlighting that most of the reviewers emphasized the excellent quality of the library design. Here are some quotes: - "The design is very clear. I think it can serve as a standard example of how to cover a big non trivial problem domain using meta-programming, partial specialization and tag dispatch to make it uniformly accessible by a set of generic algorithms." - "The design looks clear enough so that I was able to understand about what was being done. Adding concept checking is a good idea. It also surely is a modern generic design." - "I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library." At the same time the 2 NO votes reflect a couple of shortcomings which still need to be addressed before final inclusion into SVN. Here is a list of contingencies noted by the reviewers: - Robustness: algorithmic robustness and arithmetic stability have been discussed widely. The consensus of the reviewers is that all algorithms need to be robust and that the user should be able to make sure all calculations are arithmetically stable. GGL addresses arithmetic stability by allowing to instantiate all algorithms with arbitrary number types. But it turns out not the entire library has been converted to use this scheme yet. Any design issues that would prevent strong robustness guarantees (without drastic refactoring) in the future should be identified and fixed prior to release. The documentation needs to reflect the actual guarantees and complexities of every algorithm. - Concepts: more refinement needs to be done for the existing concepts. At least 2 users claimed to not have been able to adapt their data structures to the existing scheme. The library aims for defining the concepts and interfaces for future geometry related work in Boost, so these use cases need to be addressed. Users mentioned the missing concept inheritance. This might be a good way to address the current problems of concepts being too fine grained and too difficult to use. What needs to be done at minimum is to enhance the flexibility of the concept mechanism enabling to adapt user provided data structures more easily. The concepts need to be sound even in the light of extensions. - Boolean operations: while the library provides a set of Boolean operations those seem to be not complete and/or robust in terms of clockwise/counterclockwise geometries, closed/open polygons. Robust Boolean operations are a strong requirement, so this should be fixed as reported by at least one reviewer. - Documentation: the documentation of the library is not complete and needs additional effort. Using Doxygen alone as a documentation tool has its (known) shortcomings when it comes to generic libraries. The authors already mentioned to plan to switch to QuickBook after review allowing to have better control over the generated docs. - Testing: several reviewers mentioned the need for a thorough testing framework allowing the verification of the correctness of the algorithms in a wide range of use cases. Different test strategies need to be employed, such as high volume and random tests, known border case tests, tests using different numeric precision types, etc. Minor (non-contingency) issues: - Names of used concepts: currently the library is using mainly terms as established by the OpenGIS Consortium (OGC). This is misleading for users coming from different (non-GIS) domains. It has been suggested to introduce different namespaces for the different geometry domains (GIS, graphics, 3D, etc.) allowing to use the expected terminology established in that particular domain. - Name of the library: the name 'GGL - Generic Geometry Library' is misleading as it is not a generic geometry library but a library using generic programming techniques related to geometry. It has been suggested to use the name Boost.Geometry instead. This is not a requirement imposed by the review results, but I would like to suggest to the authors to consider renaming. - Integration with Boost.Units has been suggested. The library does not need to be completetly integrated with Boost.Units, although it appears to be reasonable to deal with types as exposed by Boost.Units especially for distance and area calculations. - Spatial data structures (such as spatial trees) have been mentioned to be crucial for a geometry related library. While the library can't implement all possible data structures in this field it can (and should) define concepts and interfaces allowing future extensions while maintaining interoperability. - In addition to that the reviewers made a lot of remarks related to different smaller inconsistencies part of which already have been addressed during the review. Barend has a full list of the remaining ones and promised to address all of them. Last but not least I would like to encourage cooperation between the authors of this library and the author of Boost.Polygon as both libraries have their strength' worth combining. In an ideal world and at some point I would like to see both libraries to be merged. But this is obviously not something to expect really soon. At this point I would like to thank all who participated in the review and, certainly, the authors for submitting this excellent library to Boost. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

2 1

Boost.Integer makeover
by John Maddock 29 Nov '09

29 Nov '09

Folks, Boost.Integer has had a quick makeover in Trunk - starting from the "last known good" release - and then fixing all outstanding issues filed since that release. New-look docs are visible here: https://svn.boost.org/svn/boost/trunk/libs/integer/doc/html/index.html I'd really appreciate it if: * Folks can read through the docs looking for the usual SNAFU's * Test the code on whatever exotic compilers/platforms you may have available. Some random thoughts that occurred to me while doing this: * I don't see the point of the static-min-max templates - there are 4 of them when 1 would probably do (template <class T, T val1, T val2> static_min_max), but in any case the implementation is almost too trivial for a separate template to make sense? * I haven't added mpl-compatible templates yet as per https://svn.boost.org/trac/boost/ticket/1224, is there demand for this? Cheers, John.

9 22

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 29 Nov '09

29 Nov '09

Hi Darryl, > I found code size of stripped executables compiled with gcc 4.3 to be > quite reasonable - especially at high optimisation levels, although > still about twice the size (the docs state) VC9 achieves. I'm assuming > that the large sizes mentioned are simply due to the generated files not > being stripped. Correct. Stripping will greatly improve the executable size, eventhough it'll still be more than what VC produces. > I was unable to compile the euml example - I haven't investigated the > errors yet. g++4.3 should manage this. Please contact me if you need any assistance. > I had hoped to pick what I'd consider a realistic use for a high > performance FSM tool (a low level comms protocol) and do a basic mock-up > implementation using MSM. However a reasonably typical layer 2 protocol > (LAPD) has 8 states and a transition table that in a condensed form (row > for each event, column for each state with the column describing the > actions and transition) is 10 pages long, so it is pretty obvious I > can't do that... Its likely that a bit of refactoring could bring the > total number of transitions down somewhat using composite states, but > the number of events to be handled exceeds the typical limits for number > of transitions so this still seems hopeless. 8 states doesn't seem like a huge number to me. How many transitions are we talking about? I'm not so sure that it can't be done, especially as you're using g++ 4.3 which is the best compiler with Msm. I managed to compile 100 transitions in about 40s (while running in a VM). I'm pretty sure the compiler can manage more. Supposing that every of your 8 states has a distinct transition to every other state including itself it'd be 64 transitions, which your g++4.3 will easily manage. You can even allow yourself to have more than one to every state. In the very worst case, if you had so many events (say more than 100) that g++4.3 itself would crash we could easily group events with the same source and same transition inside the same event and reduce the number of transitions to what g++ would manage. > At this point, I really like what msm is trying to do - it just doesn't > quite do it for me in a practical application. Maybe that just means > waiting for Moore's law and compiler technology to catch up? Well, it'd be a solution but hopefully we won't have to wait yet ;-) Seriously, I'd be happy to work with you on this one. It'd be quite fun and I'm pretty confident it can be done if I'm right about my assumption on the number of transitions. Regards, Christophe

2 1

First results using Comeau C/C++ compiler
by Mateusz Loskot 28 Nov '09

28 Nov '09

Hi, After quite some time of trying to build Boost, especially Boost.Test, using Comeau C/C++ frontend with GCC 4.x on Linux, I've started to get some promising results. During this investigation I was juggling number of fixes and patches [1] and eventually I found quite surprising solution. Yesterday, while reading signal.h and other headers to find out how to get signals features compiling for Boost.Test library, I came across an interesting macro which seems to be a passkey to the world of GNU C Library for Comeau toolset :-) It is _GNU_SOURCE macro [2]: "If you define this macro, everything is included: ISO C89, ISO C99, POSIX.1, POSIX.2, BSD, SVID, X/Open, LFS, and GNU extensions." Defining this macro seems to solve all issues I reported [1] so far. BTW, I've sent request to Comeau team for their opinion about usage of this macro with Comeau C/C++ frontend. Hopefully, it will be assumed safe to use, then we've got solution for all/most of the problems. Second due to the fact Comeau does not support linking as shared, I had to explicitly request to link Boost.Test binaries statically. I attach patch for Boost.Test Jamfile.v2 files adding the macro and configuring static link for como toolset. Let it be an example showing what kind of changes/options are needed by como toolset to build Boost.Test binaries. I haven't tried, but I suppose it's safe to assume that the same changes are needed to build other libraries like Asio, Program Options, and others. I'm going to find it out. To summary, there are two required changes in build configuration to enable como toolset, so far. So, what is the best approach to incorporate those two settings to other libraries (only those when it's needed): * Should I hack all Jamfiles where those changes are needed? * Or, it would make sense to set these options for como toolset, by default? * Where <link>static should go? To Jamfiles or nowhere and static linking should be explicitly enabled as bjam argument? I also tested: como --v2 link=satic Gennadiy, I'm sorry for making quite a mess in Trac by reporting number of tickets and submitting number of patches which eventually turned out to be unnecessary. It took me number of iterations to sort it out and I was subsequently recording my discoveries. [1] - int64_t/uint64_t https://svn.boost.org/trac/boost/ticket/3548 - snprintf, vsnprintf https://svn.boost.org/trac/boost/ticket/3558 - POSIX features (e.g. signals.h) https://svn.boost.org/trac/boost/ticket/3662 [2] _GNU_SOURCE http://www.gnu.org/software/libc/manual/html_node/Feature-Test-Macros.html Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

3 4

[flyweight][#3658] Dependency on static initialization/destruction order
by Andrey Semashev 28 Nov '09

28 Nov '09

Hi, I've created the ticket #3658 [1] on the flyweights library. The ticket is about Boost.Flyweight depending on the static initialization/destruction order, which can lead to application crashes in some cases. The library does provide certain tools to work around the problem [2], but these tools are only usable in the most obvious cases and do not solve the problem in its root. What I have proposed in the ticket is to implement reference counting in the flyweights, so that the flyweight value is only destroyed when no flyweight handles refer to it. AFAIK, Boost.Flyweight already has reference counting, so the work is only to shift value owning from the holder to the flyweights. Comments are welcome. [1] https://svn.boost.org/trac/boost/ticket/3658 [2] http://www.boost.org/libs/flyweight/doc/tutorial/technical.html#static_init

2 2

[msm] Review
by Juraj Ivančić 28 Nov '09

28 Nov '09

Hi all, This is my first attempt at reviewing a library, so please bear with me. - What is your evaluation of the design? I think that MSM is brilliantly designed and offers a great deal of advantages over StateChart (SC). The part I like the most about MSM compared to StateChart is the way state machine is defined. Transitions are not a part of state, but are listed in the state machine itself in the transition table. Although it is generally a bit more difficult to write the MSM transition table than its SC counterpart (especially when resolving transition conflicts) I found it very rewarding. It gets difficult to get a clear picture of SC state machine when it gets large - especially when many custom_reactions are used. Also, when composites are used in SC, it is difficult to figure out the hierarchy. IOW SCs distributed sm definition makes it very hard to get a clear picture of what is going on without a pen and paper at hand. Please do not think that I have anything against SC - I have been using it since it became a part of boost and still intend to. It has saved me from writing my own feeble double-dispatch implementations and saved me a lot of time and nerves on more than one occasion :) MSM does lack some of the SC functionality. There is no state-local storage in SC sense, as all states are constructed when main state machine is constructed. This can be easily worked around though. It is impossible to stop event from propagation (SCs discard_event()) without actually changing state. You cannot conditionally defer an event. There seem to be some differences on how event deferral is handled when composite states are used. This part is a still bit mysterious to me. A MSM feature I really like though is that on transitions both source and target state exist. This allows storing transition event data in the target state in case this is needed. This could not be done in SC because on target state construction event that caused the transition is lost. The latest MSM 2.0 offers separation to front-end/back-end. This is potentially a very powerful feature which makes me hope that some day in the (nearby) future I'll be able to create/modify a state machine in some GUI app and have it automagically transformed into high performance C++. The author seems masochistic enough to try to tackle this. :) - What is your evaluation of the implementation? Reading the implementation quickly causes a severe headache. - What is your evaluation of the documentation? It found it well written and containing useful examples. The first part is pretty much quick-start guide, and it gets more and more complicated as you read along. I found it lacking info on some border-line cases. It does however often reference UML state machine standard, which I am unfamiliar with, so this could be my fault. Aesthetically - I'm not a great fan of one big fat html documentation and would prefer to have it broken down and cross-referenced as most boost libraries docs are organized, but this is just a minor issue. - What is your evaluation of the potential usefulness of the library? I find it very useful in its current state. Furthermore, I gathered that the author is planning on adding new front-ends (back-ends?) thus making it even more so. - Did you try to use the library? With what compiler? Yes, with MSVC9. - Did you have any problems? As it often is with metaprogramming libraries, error messages leave much to be desired. I had to figure out how to use mpl::vectorX with X>50. This ancient post helped: http://tinyurl.com/yf7e9mo It wouldn't hurt to have it included in some way in the docs. There are some behind-the-scenes vector unions in MSM, so it is possible that you will require, e.g. mpl::vector60 without ever directly using mpl::vector with more than 40 members. The exact formula for determining max needed vector size would be useful. MSM state machines compile for ages. I also managed to find a bug or two and some documentation errors. I sent reports to the author and he had them resolved in literally hours. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? As in-depth one can get without looking under the hood. Thorough read of the docs, playing around/testing and nagging the author :) - Are you knowledgeable about the problem domain? Not especially. I spent a great deal of time using StateChart and have played with the MSM 2.0 for the last couple of weeks (since the announcement on this list). I have also recently ported a pretty complex state machine (~15 states, ~80 transitions) from SC to MSM. And finally, yes, I think that this library should be accepted as a part of boost.

1 0

Interest in Devector implementation?
by christopher hopman 28 Nov '09

28 Nov '09

So, I have been working on a devector implementation for the last week or so (see https://svn.boost.org/trac/boost/wiki/soc2009#Boost.Devector) There is some stuff that still needs to be done, and some testing that is still needed, but I thought I would check if there was interest in such a thing. The implementation is basically a standard deque implementation with one addition. That is, there can be allocated "chunks" both before and after those in use. This leads to a couple of advantages for users. First, in many use cases, devector is faster than deque because it will have less allocations. For example, when used strictly as a queue, the regular deque has a number of chunk allocations linear in the total number of elements inserted in the queue, devector has allocation linear in the maximum elements in the deque at one time. When used as a stack, a particularly bad case can occur with a normal deque implementation, the case where the top of the stack switches back and forth between two chunks. Second, this allows users of devector to reserve space on either side of the structure. This does not give the same efficiency boost as vector::reserve, but, possibly more important, it allows for stronger exception guarantees and for better guarantees about when iterators are invalidated. Another benefit of devector is that chunk size is not a compile time constant. In fact, chunk size is not even required to be constant over the lifetime of a given devector. Also, devector iterators allow lower level access than std::deque as described by Matt Austern ( http://lafstern.org/matt/segmented.pdf) Support for in-place construction (described at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2212.html) will become available with c++0x's emplace_back(). Though I expected that std::deque would have a slight performance advantage due to its compile-time constant chunk_size, early tests have actually shown devector to have a slight advantage even in cases where it has no advantage from not deallocating unused blocks. My guess is that this is due to std::deque needing to do more work to maintain its invariants in the face of exceptions. Again though, that is just some simple early testing that I did. The current implementation does not actually allow changing chunk_size (though this is actually a matter of like 5 LOC), nor does it give the segmented iterator access (again a simple addition). Code is available at http://pages.cs.wisc.edu/~hopman/devector/ (along with code that tests most of the std::deque interface). -Chris Hopman

1 0

[serialization] polymorphic archives + boost_class_export generates linker errors
by Christoph Heindl 28 Nov '09

28 Nov '09

Hi, I've posted this with no luck to the boost-users mailing list: the attached example [1] generates a couple of linker [2] errors on msvc 9.0 / boost 1.40.0 all related to missing archive_serializer_map symbols. when switching from polymorphic archives to corresponding non-polymorphic archives the attached example runs fine. It seems that the usage of BOOST_CLASS_EXPORT in conjunction with polymorphic archives triggers the linker error. I tried to add explicit template instantiations, such as [3], for the missing types to boost archive, recompiled boost and was able to get rid of the linker error. The problem then, however, is that the example fails at runtime with an assertion that a type-lookup did not succeed. So I guess adding the explicit template instantiations was not the correct approach. Is this a bug? Can anyone confirm this issue? Best regards, Christoph

4 10

[random] documentation rewrite
by Steven Watanabe 28 Nov '09

28 Nov '09

AMDG I'm in the process of updating the Boost.Random documentation. I've put what I have right now at: http://www.cs.hmc.edu/~swatanabe/random_doc/libs/random/doc/html/ The content is mostly the same as the current docs, although I've filled in some missing pieces and fixed some of the more egregious out of date docs. Any comments, criticism, etc, are welcome. In Christ, Steven Watanabe

5 10

Re: [boost] Boost.Array Maintainer
by raindog＠macrohmasheen.com 27 Nov '09

27 Nov '09

*top post* I think that it should be acceptable for other people to have the authority to submit patches and have them reviewed by other people and as long as they submit high quality code there should be the expectation that the code gets merged by someone who has the rights to do so. Look at other open source projects for ideas *end too post* ------Original Message------ From: Vicente Botet Escriba Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Subject: Re: [boost] Boost.Array Maintainer Sent: Nov 27, 2009 7:58 AM John Maddock wrote: > >>> Question: does someone have to be a maintainer of an existing library >>> (or author of one of the accepted libraries) to become a maintainer of >>> an existing (orphaned?) library? >> >> This is a very interesting question. Some lingering tickets with patch >> could be cleared faster if soem orphaned components of bosot were >> assignated new manager. > > Indeed. Something that occurred to me earlier was "how many tickets were > looked at in the last sprint, assigned a patch, but haven't been looked at > since?" That would be a good test of the owner being missing-in-action! > > Re Boost.Array, I seem to remember Alisdair Meredith taking this on, I'm > cc'ing him just in case my memory isn't what it once was ! ;-) > > It seems to me though that the bug sprints would be a good opportunity to > widen the maintainer list a little - what if we assigned an interested > volunteer to act as temporary maintainer for an orphan library during the > sprint. (S)he fixes whatever they can fix, then gets another bug sprint > volunteer to review the changes, if all looks well, and the tests are all > passing on Trunk, only then merge to release. > > Thoughts? John. > > _______________________________________________ > Unsubscribe & other changes: > http://lists.boost.org/mailman/listinfo.cgi/boost > > Hi, I don't know if this is the best way, but it is clear that we have a problem with very old tickets. It will be great to identify the libraries that will need this kind of help, and make a call for volunteers. Best, Vicente -- View this message in context: http://old.nabble.com/Boost.Array-Maintainer-tp26534655p26544289.html Sent from the Boost - Dev mailing list archive at Nabble.com. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

1 0

warning policy issue
by Robert Ramey 27 Nov '09

27 Nov '09

On page https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines#warn… it's suggested that the following warning at level 4 can be eliminated with a static cast warning C4244: 'argument' : conversion from <type1> to <type2> possible loss of data I've found this not to be true at least with msvc 7.1 Robert Ramey

5 9

Removing LEDA adaptors from Boost.Graph
by Jeremiah Willcock 27 Nov '09

27 Nov '09

Are there any users who are using the LEDA interfaces to Boost.Graph? There are several tickets filed against them but the tickets are all years old. Is it safe to remove them? Do they need a deprecation period first? -- Jeremiah Willcock

2 2

[LibrariesUnderConstruction]Mirror - update
by Matus Chochlik 27 Nov '09

27 Nov '09

Hi, I would like to ask the admins to update the info about the Mirror library on the LibrariesUnderConstruction page in particular to add the links to the C++0x version of Mirror on sourceforce: http://sourceforge.net/projects/mirror-lib/ and to add a link to the online docs for the C++0x version: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ TIA ________________ ::matus_chochlik

2 2

[LibrariesUnderConstruction] Boost.Numeric_Bindings
by Rutger ter Borg 27 Nov '09

27 Nov '09

Hello all, I see the Numeric_Bindings library is missing on the LibrariesUnderConstruction trac page. This library is under development since 2002. Herewith a short description of the library. Boost.Numeric_Bindings is a C++ library for numeric computing. It is a generic layer between data containers and linear algebra algorithms. For the data container part, it supports both compile-time statically sized and run-time dynamically sized vectors, matrices, through a traits system. Currently it includes traits for C-arrays, for standard vectors, for uBLAS' containers, Eigen containers, TNT, Boost.Array, to name a few. It offers compile-time inspection, iterators, and views on all mentioned containers. For the algorithm part, it provides a C++ interface to algorithms offered by BLAS, LAPACK, and more. This covers algorithms from most vendor-provided math libraries, such as the reference BLAS, ATLAS, Intel's MKL, AMD's CML, NVidia's CUDA, etc.. The "stable" release is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings-v1/ The current development version is available at http://svn.boost.org/svn/boost/sandbox/numeric_bindings/ Questions and/or comments are welcomed. Thanks, Rutger

3 4

Compiler warnings from Macs, IBM acc, Borland, Comeau, Metroworks, et al - are they a Problem?
by Paul A. Bristow 27 Nov '09

27 Nov '09

https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines (bottom of the page) has a collection of suggestions for 'quieting' warnings on MSVC and GCC, but no information on other compilers yet. Can users of these compilers please 1 Assert that they never have a problem with unhelpful compiler warnings from Boost stuff, or 2 Send common warnings and suggestions for dealing with them by suppressing or by 'fixing' the code (so that I can add to the guidelines. Thanks Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 0

Boost.Array Maintainer
by Dean Michael Berris 27 Nov '09

27 Nov '09

Good day everyone, Does anybody already maintain Boost.Array? I see quite a number of patches and "todo" tickets and am wondering whether someone should be taking care of such a crucial piece of the collection. If there isn't anybody willing to maintain Boost.Array I don't mind looking after it until someone else does. Question: does someone have to be a maintainer of an existing library (or author of one of the accepted libraries) to become a maintainer of an existing (orphaned?) library? HTH -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

6 6

[unordered] 1.41.0 unordered_map doesn't allow declaration with incomplete type.
by Jon Spencer 27 Nov '09

27 Nov '09

The new version of the unordered library doesn't allow you to declare an unordered map with an incomplete type. The following code would compile with the old version but not the new: struct a; struct b { boost::unordered_map<int, a> c; }; Or the more useful: struct d { boost::unordered_map<int, d> e; }; As far as I know these constructs are allowed with the other standard containers. The problem show up in "boost/unordered/detail/fwd.hpp" with the the declaration of value_base, which requires that the value_type of the map not be incomplete at declaration time. Jon.

2 1

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 27 Nov '09

27 Nov '09

Thomas Klimpel wrote >> Some of the accepted boost libraries seem to >> receive only minimal maintenance by their original authors, >> and making it easier to contribute >> libraries to boost would probably only increase the number of >> libraries in minimal maintenance mode. So I >> guess the recent efforts to encourage the boost >> community members to spend some maintenance time on >> libraries they haven't authored is exactly the >> right thing to do for the current situation. Agreed, that is a problem, but different from the one I'm trying to emphasize here. >> I'm not sure whether you want to highlight the excessive >> quality criteria for acceptance into boost here, >> or the lack of review managers. Probably more the lack of review managers. I wish more of the core boost library developers would step up and mentor new library submissions. Not sure why they don't. Its actually quite fun. >> But the sandbox is actually quite a nice place to flesh out a >> potential library. And there is quite a number of libraries in the >> sandbox that are currently in active flesh out mode, and will stay in >> that mode for quite some time. The sandbox is just a nice place to dump a library. Most are quickly abandoned and receive very little attention. Why? Exposure, they need exposure. Having a place in for the promising experimental libraries to to get some exposure, and where the authors can toot how great their library is would be fun for all involved. That's why I come to boost -- for an exchange of ideas and to be inspired by others. The sandbox does not do that for me. Having libraries in the experimental branch would focus everyone attention on the upcoming libraries. Nothing can focus a library's authors attention if he knows that his library is getting exposure and being noticed by others. I played a part in developing the the review queue, but it never changes. I don't like how its evolved and its stuck in the status quo. The review queue does not give enough exposure and its now taking about a year to get your library reviewed. Uggh. Actually, I would like to see that the review queue is abandoned and replaced with the experimental branch. The only important review would then be when to decide when the library has matured enough to move it from the non-stable to the stable branch of boost. The review wizards would manage this process. It would be much more fun for all involved. The current system is stale and not inspiring the level of innovation that I believe is possible here.

15 21

Re: [boost] Review Queue Needs Attention
by Tom Brinkman 26 Nov '09

26 Nov '09

>> judging by the review schedule (almost no review managers), that would mean >> boost isn't very interested in new libraries in general. It would seem so. >> I would recommend that authors try find a review manager before they request a review. Review managers are generally recruited from people that already have a library that has been approved in boost, that means you luke (hint). The wizards could open it up to anyone. Its been considered, but rejected in the past. I would like to focus attention on something different. That would be creating a "non-stable" branch of boost, where the proposed libraries would live for a while, get some exposure. Since most libraries are header file only, it should not be a problem. While not all will compile on all platforms, and certainly not have perfect documentation, it would be a place for future boost authors to elicit feedback. The experimental libraries would not affect the core boost libraries in any way. I'm absolutely convinced that it would encourage lots more participation. There is so much more to do, we haven't even scratched the surface of what is possible. The core boost authors have put in place a wonderful place to come and share ideas, but we are letting it flounder. Ugh.

7 6

Failures on SPARC64 [Was [1.41.0] Beta 1 available]
by Alexander Churanov 26 Nov '09

26 Nov '09

Folks, I've tried to re-built 1.41 and 1.39 using the suggested patch. The libraries build successfully, but a single test ( "spinlock_try_test" ) for smart_ptr fails. Please, examine the issue and provide with solution or workaround. I've created a ticket on that - https://svn.boost.org/trac/boost/ticket/3678 Alexander Churanov, maintainer of devel/boost-* for FreeBSD

1 0

[Review] GGL review starts today, November 5th
by Christophe Henry 26 Nov '09

26 Nov '09

I apologize in advance for not being able to bring a complete review due to my lack of knowledge of the problem domain, but I hope to bring a few elements. I also apologize in advance for the unfair treatment to Luke that I was not able to do the same about Polygon due to my lack of time at the point of the Polygon review. *What is your evaluation of the design? The design looks clear enough so that I was able to understand about what was being done. Adding concept checking is a good idea. It also surely is a modern generic design. I found only 2 points to criticize: - linestring has std::vector as basis class, and therefore it should be clearly documented that this class is not made to be derived from. - most or all of geometries classes have no virtual destructor and thus this should be clearly documented or changed. Better even would be to give the user choice through a policy. *What is your evaluation of the implementation? The code is clean and nice to read and I found it pretty easy to understand (apart from the deep geometry stuff of course). *What is your evaluation of the documentation? The examples are nice to read, the rest of the doc is a bit light and would probably not let me do more complicated stuff. I'd love an example about every feature. *What is your evaluation of the potential usefulness of the library? For me quite big. I'd probably never need the advanced features but the simple ones would solve my biggest problem, which is how to avoid ever having to implement something like this myself, which I would probably never manage anyway. About the completeness of the library, I am not able to judge it and trust the more experienced reviewers. *Did you try to use the library? With what compiler? Did you have any problems? I compiled several examples with VC9 + VC10 beta2. Both compiled without warnings level 3. The VC10 code analyser found a few points (reported to one the library writers), which I suppose are minor. Interestingly, the analyser did not find a bug in the linestring example, which happens only with VC10. This bug needs fixing but must be pretty simple to correct. *How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent a few hours reading and running the examples and checking the analyser and compiler level 4 warnings. I also spent 2 hours looking at the code. *Are you knowledgeable about the problem domain? Not at all. I'm simply looking for a library in case I ever need to do something in this domain. *Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. YES, eventhough I wouldn't count my own opinion as a full vote due to my lack of domain expertise. I like: - some nice features I understood like the linestring and polygon - the fact that the code is clean (meaning lots of care has been spent on it) and that the authors are responsive, which is a sign that the library will be well-maintained. - the examples I like less: - the documentation which gave me the frustrating feeling I missed most of the cool stuff and needs some warning messages for the problems I cited above. Best regards, Christophe Henry

5 7

GGL Review
by Gordon Woodhull 26 Nov '09

26 Nov '09

I believe GGL should be accepted as Boost.Geometry My main concern is the number of things which are incomplete. Certainly the obvious lackings such as missing boolean operations, clockwise versus counterclockwise polys, closed versus open polys, should be fixed or rationalized before this is released. It sounds like Barend and friends have promised to complete all of these things. I hope Hartmut is willing to manage a mini-review when the authors believe this is ready for release, to make sure that all concerns raised in the first review have been addressed in some way. I asked the same for Boost.Polygon; I think it is even more important here because the scope is much broader, whereas Polygon seems to have covered integer polygons pretty well. Then there are a lot of things which the authors claim are possible but which will probably need to be contributed by others: triangles, 3D, ellipses, splines, homogeneous coordinates ... I am confident that the authors will help these things to happen, and I have no reason to think that they won't fit in. OTOH it may be that some concepts do not fit in; for example, it's not clear to me whether or not the 45/90 degree concepts of Boost.Polygon are orthogonal or skew. It is going to take some time for everyone to figure this out, and I think that Boost is the right forum for this discussion. I hope that future domain libraries are developed as extensions to GGL, but it may be that they demand their own frameworks. I think it's naive to assume outright that all can fit into one framework, but I am optimistic. Both libraries allow external data structures and concepts to be adapted to them, and so the first step in determining their commonality will be to write those adapters. I'm pleased to see that Luke has already started this effort from his side. Oh, for concept maps! My two cents on floating point robustness: in many applications, the use of geometrical computations is "one-way": there is a model, some operations are applied to produce coordinates, which are then output. This is mostly true in the domain I wish to use this library, graph drawing (network visualization). If the results are not fed back into the system, floating point robustness is not going to be an issue. While some work could probably be done here, I think it is OK that users must understand the issues with floating point for best results. I'd like to see GGL run with Boost.Polygon's robustness tests and randomly generated efficiency tests. It sounds like this has already begun. A couple of people asked for GIL examples. This would require a line and curve bitmap rendering library, which would be a really cool addition to Boost. ===== How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ===== Sorry I have not had time to conduct a more thorough review. I have spent a couple of hours looking at the documentation and examples, and have read the review discussion thoroughly (another five or six hours). I've also followed most of the discussion in the past. ===== What is your evaluation of the design? ===== It seems very well thought out, for the domain which has been explored so far. The only concern I have (which I haven't thought out thoroughly) is the absence of hierarchical concepts. IIUC a new class must subscribe to all concepts, not just the most derived. This seems like it might get onerous when there are a lot more concepts / if the granularity is reduced. ===== What is your evaluation of the implementation? ===== From the discussion and from the presentation at BoostCon, I understand that not everything which is described is implemented, and everything which is implemented does not completely live up to the standards which the library sets. Again, I think these discrepancies should be resolved either by implementation or by narrowing the scope and documenting. As is, it's rather confusing. ===== What is your evaluation of the documentation? ===== I'd like to see an overview of the concepts - there are the detailed descriptions in doxygen but nothing written in English. :-) Doc seems mostly to consist of very technical rationales, which are good, and then examples, which are also good. But not much overview. I think doxygen is convenient for developers but not very useful for users, because of the high structure/content ratio. ===== What is your evaluation of the potential usefulness of the library? ===== Very useful. ===== Did you try to use the library? With what compiler? Did you have any problems ? ===== Not yet. ===== Are you knowledgeable about the problem domain? ===== As others have pointed out, it's not clear the domain is well- defined. I'm not familiar with GIS. I have developed visualization and graphics applications which need 2D geometry for more than a decade, and this looks like it will serve many of my needs. I wish both this review and the Polygon review had been delayed until the libraries were more mature. As it is, we're going on trust that the promise will be fulfilled. But I understand that there are social and real-world constraints as well as technical and I think it's best that both libraries are accepted a little early so that the community has a chance to cooperate in lifting the concepts. I am very happy to see the authors resolving some of their differences. There's a long road ahead... Cheers, Gordon

2 2

Re: [boost] [Serialization] warnings and maybe a 'bug'
by bernard cupic 26 Nov '09

26 Nov '09

Is it possible tha the problem is in the shared_ptr_helper.hpp file in the line 114: Â Â Â template<class T> Â Â Â struct non_polymorphic { Â Â Â Â Â Â Â static const boost::serialization::extended_type_info * Â Â Â Â Â Â Â get_object_identifier(T & t){ Â Â Â Â Â Â Â Â Â Â Â return boost::serialization::singleton< Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â BOOST_DEDUCED_TYPENAME Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â boost::serialization::type_info_implementation<T>::type Â ==>Â Â Â Â Â Â Â >::get_const_instance(); Â Â Â Â Â Â Â } Â Â Â }; If you compare it with the following code (same file, just below the upper code): Â Â Â template<class T> Â Â Â struct polymorphic { Â Â Â Â Â Â Â static const boost::serialization::extended_type_info * Â Â Â Â Â Â Â get_object_identifier(T & t){ Â Â Â Â Â Â Â Â Â Â Â return boost::serialization::singleton< Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â BOOST_DEDUCED_TYPENAME Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â boost::serialization::type_info_implementation<T>::type Â ==>Â Â Â Â Â Â Â >::get_const_instance().get_derived_extended_type_info(t); Â Â Â Â Â Â Â } Â Â Â }; it smells like a bug to me. Best regards. -- Bernard Cupic Software Development Manager USCS d.o.o. Flaciusova 1, HR-52100 Pula e-mail: [1]bernard.cupic(a)uscs.hr tel/fax: +385 52 380 687 References 1. mailto:bernard.cupic@uscs.hr

1 0

[xpressive] Significant compiler warning
by Ian Emmons 26 Nov '09

26 Nov '09

I have a program that uses Boost.Xpressive. When compiling this code on the Macintosh with the darwin-4.2.1 toolset, I get the following compiler warning: .../boost_1_41_0/boost/xpressive/traits/cpp_regex_traits.hpp:84: warning: left shift count >= width of type Here is the offending line of code: umaskex_t const highest_bit = 1 << (sizeof(umaskex_t) * CHAR_BIT - 1); The problem (if my thinking cap is screwed on correctly) is that the 1 that is being shifted is of type int, and is not converted to the target type of umaskex_t until after the shift operation. I believe that this should be changed to the following to avoid highest_bit being set to zero: umaskex_t const highest_bit = static_cast<umaskex_t>(1) << (sizeof(umaskex_t) * CHAR_BIT - 1);

2 1

[Exception] SFINAE use breaks Borland in Trunk
by John Maddock 25 Nov '09

25 Nov '09

Boost.Exception is currently failing for Borland compiles with for example: http://tinyurl.com/ycu779q The issue appears to be use of SFINAE like techniques without a BOOST_NO_SFINAE fallback. The problem here is that since Boost.Exception gets pulled in by almost everything, we need it to be lightweight and well supported, otherwise the rest of us are stuck even if we want to continue to support the older compilers :-( Thanks! John.

3 4

Re: [boost] [msm] scalability
by Christophe Henry 25 Nov '09

25 Nov '09

> a library that I plan to submit to boost causes > 50 s compile times even for simple examples, > so do you have any recommendations on where to start? There is a template profiler from Steven Watanabe, you could start there: http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… > my library invokes a lot of Boost.Serialization and some MPL/fusion code, > so I'm not even sure if I can do anything about that within my library. As you use some MPL, you should check all your algorithms for complexity (especially if you use many mpl::fold). A quadratic complexity in a metaprogram will hurt you pretty fast. I had the feeling that SFINAE also hurts you quite much on some compilers. HTH, Christophe

3 2

Idea: Boost Software Foundation?
by Dean Michael Berris 25 Nov '09

25 Nov '09

Hi Everyone, I have been watching the passionate debate about how to go about achieving the following: 1. Make Boost less monolithic and more open to contributions 2. Make Boost easier to distribute and support 3. Make Boost better but less complex and more manageable Someone mentioned the "incubator" idea and now that I think about it more I think this model works very well for Boost. Let me try to draw some parallels between the Boost C++ Library and the Apache Software Foundation: 1. As a project, Boost and Apache try to (and I'd like to say both do) deliver high quality open source components under a liberal and commercially friendly license. Boost has many sub-projects that are worth naming like Boost.Build, (Boost.?)Quickbook, BCP, and Boost.Jam (although a little stagnant IIRC). Maybe treating other libraries as sub-projects that have a publicly-accessible and easily "forkable" repository would be a good thing. Git and Github come to mind. 2. As a software distribution, Apache has decentralized the release management of the libraries and software projects under its umbrella. This means sub-projects can depend on specific version releases of other sub-projects instead of making sure that there's only one release that bundles everything together. 3. As an entity, the only difference I see between Apache and Boost are that: * Boost is a volunteer-backed, non-foundation backed entity, while the Apache Software Foundation is legally a non-profit non-stock organization. * Boost does not have resources that "it" owns while ASF employs people in different capacities. * Although the Boost Software License and the Apache Software License are both OSI approved, there seems to be no legal team dedicated to ensuring that the terms of the licenses (and the contributions made by contributors) are "properly" applied. I don't want to instigate an "uprising" here, but I for one would like to see a Boost Software Foundation whose main task would be to further the Boost-licensed projects, and lends its name to signify the high quality and organized peer-reviewed and meritocracy-driven C++ application and library development for the betterment of the C++ language and vendor/implementor/library-author community. And then to see the Boost Software Foundation have a formal means of having projects "built for Boost-inclusion" be drawn into an umbrella project to become "incubated and developed with Boost Quality in mind". If I understand how Apache projects are run, it appears that: * A project manager is assigned/nominated by the community to represent a sub-project in the bigger Apache project. * There are official developers who have commit access to the repository; developers who want to become an official developer of the project signs a contributor agreement which states in no uncertain terms that they agree that their changes committed to the repository are licensed under the Boost Software License. * To become a "committer" to the project, you have to be asked by official developers or nominated by peers based on your contributions in the form of patches or pulls from your "fork". I do not see why this model should not work for Boost granted that some people already take the libraries they maintain as their full-time (or almost full-time) projects (Boost.Thread, Boost.Spirit/Fusion/Phoenix). And because of the decentralized nature of this model, the only "review" that has to happen is whether a sub-project should be incubated, and whether projects in the incubator are deemed "mature" enough to become full-blown Boost.* projects. One other idea about distribution: the biggest hindrance I think is the lack of a "centralized" or "repository-like" location from where released versions of a library can be pulled easily. Haskell has Cabal, Perl has CPAN, Debian has official 'apt' repositories, Ruby has multiple Gem foundries, Python has the Cheese shop (?). Although SVN is centralized by nature, it's not the best means of distributing releases that can be kept in-sync from various locations. Maybe the Boost community might be able to come up with a similar solution and contribute towards building a C++ package-based solution to distributing libraries in a cross-platform and scalable manner? I hope this helps. I personally have no idea how to get a Boost Software Foundation up and running but I do want to participate in that effort in a substantial manner if other people think that would be a good idea and would like to make it happen too. Have a good day everyone, that's my $0.02 worth. -- Dean Michael Berris blog.cplusplus-soup.com | twitter.com/mikhailberis linkedin.com/in/mikhailberis | facebook.com/dean.berris | deanberris.com

5 11

[thread] Bug sprint: #2100 thread fails to compile with -fno-exceptions
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Ticket description: "The thread component fails to compile with GCC when -fno-exceptions is specified. The attached patch allows the libraries / tests shipped with boost 1.35.0 to compile. There didn't seem to be a better option to make g++ happy than to just #ifndef out the catch(...) block, as it would otherwise complain about the throw in the block." from https://svn.boost.org/trac/boost/ticket/2100 Hi, I think that Boost.Thread has not been designed to work without exception. What would be the behavior of the application if we remove just any throw statement? In order to achieve the reporter goal, we should need to add functions returning a return code. IMO this is out of the scope currently. Thus I propose to close the ticket. Anthony, do you agree? Vicente -- View this message in context: http://old.nabble.com/-thread--Bug-sprint%3A--2100-thread-fails-to-compile-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 4

[thrad] #3179 Sleep with local_time
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi, Anthony this ticket have a simple solution. https://svn.boost.org/trac/boost/ticket/3179 Nest follows my contents Replying to anonymous: When calling sleep with an absolute time, it sleeps about two hours instead of one second in code similar to the below example. ptime now = second_clock::local_time(); this_thread::sleep( now + second(1) ) After a lot of headache I think that might is due to a missmatch with utc and local time. Please make it possible to sleep until a "local time" (local time zone) and write something about it in the documentations, I haven't found anything special about which type of time should be used. Changed 5 days ago by viboes ¶ The this_thread::sleep prototype is template<typename TimeDuration> void sleep(TimeDuration const& rel_time); The TimeDuration? you can pass as parameter must be one for which system_time+TimeDuration? is defined. You are right that this should be documented. BTW the interface for thread::sleep is void thread::sleep(system_time const& abs_time); Anthony, to be coherent, shouldn't you add the absolute time interface on the namespace this_thread? Waiting fro Boost.Chrono, what about adding void sleep(system_time const& abs_time); void sleep_until(system_time const& abs_time); template <class TimeDuration> void sleep_for(TimeDuration const& rel_time); Best, Vicente -- View this message in context: http://old.nabble.com/-thrad---3179--%09-Sleep-with-local_time-tp26513016p2… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2361 thread_specific_ptr: nature of the key, complexity and rationale
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi Anthony, As you have made some modifications on the thread-specific_ptr, maybe you could now complete the documentation to answer the questions of the ticket. Best, Vicente -- View this message in context: http://old.nabble.com/-thread---2361--%09-thread_specific_ptr%3A-nature-of-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2742 Why the at_thread_exit cleanup function is const?
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi Anthony, thanks for fixing this ticket. Best, Vicente -- View this message in context: http://old.nabble.com/-thread---2742-Why-the-at_thread_exit-cleanup-functio… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[thread] #2742 Why the at_thread_exit cleanup function is const?
by vicente.botet 25 Nov '09

25 Nov '09

Hi, Anthony, could you verify the patch and test I have attached to the ticket works for other platforms that cygwin? Thanks, _____________________ Vicente Juan Botet Escribá

2 1

Boost sprint: #3407 boost::call_once not re-entrant (at least in win32)
by Vicente Botet Escriba 25 Nov '09

25 Nov '09

Hi, I have changed the ticket from threads to thread As this works as expected, Anthony could just add on the documentation why reentrant call_once functions are not a good idea. The explanation of Steven could be a good starting point: "I'll also point out that there is no good behavior for a recursive call to call_once. If it calls the function again, then f will be called twice. If it does not, then whatever initialization that call_once is doing may be incomplete. In either case, you have to know whether a call can be recursive and carefully design for it. If it happens accidentally, you're probably toast regardless of how it behaves. In the face of recursive calls it is impossible to maintain the post-condition that the function has run exactly once." After this modification IMO the ticket can be closed. Best, Vicente -- View this message in context: http://old.nabble.com/Boost-sprint%3A--3407-boost%3A%3Acall_once-not-re-ent… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 20

[test] New ticket #3664 (SIGCHLD always considered fatal error)
by Johan Nilsson 25 Nov '09

25 Nov '09

New ticket: https://svn.boost.org/trac/boost/ticket/3664 Regards / Johan

2 2

Boost Server Downtime Wednesday Morning
by Doug Gregor 25 Nov '09

25 Nov '09

The main Boost server will be down for a short time Wednesday, November 25th (tomorrow!) from 8:00AM Eastern time to 8:30AM Eastern time to replace some memory. This outage will affect most of Boost's services, including the mailing lists, boost.org web server, and Boost Subversion repository (including the sandbox). Sorry for the inconvenience! - Doug

1 0

Re: [boost] Re view Queue Needs Attention
by Tom Brinkman 25 Nov '09

25 Nov '09

>> What's the difference between a non-stable branch as you're suggesting and >> the existing sandbox? The only difference I could see is to establish some >> kind of pre-review process. But that would just move the problem to a >> different spot, no? The "non-stable" branch would be for libraries that have requested reviews or for "approved" libraries that have not yet stabilized. The "sand-box" branch would be for all other libraries that either have not requested reviews or don't plan to. The "review-wizards" John or Ronald or any of the "boost-moderators" could monitor the "non-stable" branch. This would clear the review queue. The only important review would be to establish when a particular library has achieved sufficient maturity to be moved from the "non-stable" branch to the "stable" branch. Once a library is in the "non-stable" branch, the library could be reviewed by anyone anytime. There would be no need for scheduled reviews, like we've had, although they could still be done, if the review manager wants to schedule it. The reviews would be ongoing and done in a blog format, not limited to a ten day block of time. After a library has been in the "non-stable" branch for say six months, the review manager could posts its progress to the mailing list and pose questions to elicit more feedback. The "non-stable" branch would be included as part of the boost installation, but only an optional part, not required. If a library is distributed as "non-stable", it should get lots and lots of attention. Nothing focuses an authors mind more than if they know that their library is going to get some exposure. The libraries in the review queue are not getting the exposure that they need, and are just sitting there for 6-18 months. Very few people are actually aware of these libraries. A better job needs to done to elicit feedback from domain experts. Having only a 10 day review period is way to short. It needs to be like 6-12 months, where the domain experts can contribute at their leisure. This could best be done if a "non-stable" branch is created, which is distributed along with the "stable" branch.

1 0

[serialization] how to serialize map of non-default-constructible?
by ivo.t＠moss-soft.de 24 Nov '09

24 Nov '09

Hi to everybody, I'm new to the list, work for some time with Boost and C++ and have a fair knowledge but am not an expert yet. I try to serialize a map whose type ist not default-constructible, and I'm seriously stuck there. I thought the load_construct_data and save_construct_data overrides would help me there, but that seems not to be the case. I tried to create a private default constructor hoping that the map (respectively pair) constructor could access it, due to the boost::serialization::access friend declaration, but that didn't work as well. I really do _not_ want to make a public default constructor. What could I do as a workaround?? Any help would be greatly appreciated!! Btw, I work with Boost 1.39 and Visual Studio 2005. Thank you very much in advance Ivo

2 1

[filesystem]: infinite-recursion with symlink
by variadic.template 24 Nov '09

24 Nov '09

While playing around with boost::filesystem and the recursive_directory_iterator, I'm running into a infinite-recursion caused by symlinks. Not following symlinks would be, a solution, of course, but... So, is there a way to ascertain the path where the symlink is aiming at? And a second question: I didn't find anything about permission-handling - are there any plans? In my eyes, this is something essential for a filesystem-library. Thanks in advance

5 7

Proposal for library addition: faster signals/slots, reactor, atomics
by Helge Bahmann 24 Nov '09

24 Nov '09

Hello everyone I have written a small library providing: - a (thread-safe) signal/slot implementation - poll/timer/reactor implementation - atomic operations modelled after the proposed C++0x standard (x86 32/64 bit, ppc, alpha, more if someone donates hardware; fallback implementation using locks) Currently I am reworking the library to be more closely tied to and better reuse services provided by Boost. Obviously, there is considerable functional overlap with Boost.Signal/Boost.Signals2 and Boost.Asio, however what sets my implementation apart is that it is considerably faster, measurable in both synthetic tests and real-world applications (the main way this is achieved is through extensive use of atomic operations and carefully designed accessor protocols instead of locking, there is a small documentation section explaining the technique). The signal/slot implementation is thread-safe, with the same guarantees as Boost.Signals2, but about 3 times as fast as (thread-unsafe) Boost.Signal (!) and about 6 times as fast as (thread-safe) Boost.Signals2. The reactor implementation is obviously only suitable for Unix-like systems, while the proactor interface provided by Boost.Asio is a nice and portable abstraction. However, my reactor implementation is about 2-3 times as fast on Unix-like systems for typical network-server-style apps. Moreover I have always found Boost.Asio to be difficult to integrate with third party libraries (think ALSA or ldap) and frameworks (think Qt, Glib), so other developers not interested in portability may also prefer a bare reactor implementation. If you are interested, I invite you to have a look at: http://www.chaoticmind.net/~hcb/projects/libtscb Maybe parts of the library might be interesting for Boost? In particular the atomic operations could be salvaged and provide a "transitional" implementation internal to boost as an interim solution until compiler vendors catch up with C++0x, and I would also like to propose the reactor as a higher-performance alternative to Boost.Asio (my signal/slot implementation lacks combiners and other features provided by Boost.Signals2). Best regards Helge Bahmann

6 7

[serialization] Boost fails to serialize via reference to a pointer
by Alexander Churanov 24 Nov '09

24 Nov '09

Folks, I've encountered an issue and not sure whether it is a bug in boost or in the application. >From the compiler error messages it looks like there is a bug in boost and a reference (or value) is to be returned from the function which has a pointer return type. The issue was detected when building x11-toolkits/gigi with the boost-1.41. The error log fragment is available at http://alexanderchuranov.com/gigi-boost-1.41.0.log . The operating system is FreeBSD 7.2-RELEASE/i386 . The compiler is c++ (GCC) 4.2.1 20070719. One can reproduce the issue using the following preprocessed translation unit: http://alexanderchuranov.com/saveload.ii The command-line is g++43 -o saveload.o -c -fno-strict-aliasing -pipe -Wall -Wno-parentheses -O2 -pthread saveload.ii The application successfully builds with 1.39.See http://portsmon.freebsd.org/portoverview.py?category=x11-toolkits&portname=…. Alexander Churanov, mainatainer of devel/boost-* for FreeBSD

2 1

[Spirit] Who's using Spirit
by Hartmut Kaiser 24 Nov '09

24 Nov '09

Hi all, We started to collect references to projects and products using Spirit here: http://boost-spirit.com/home/?page_id=594. If you're interested in getting your product/project mentioned on this page, please drop me a note. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

1 0

2nd Call for Participation - BoostCon 2010
by Hartmut Kaiser 24 Nov '09

24 Nov '09

Please distribute! -------------------------------- 4th Annual Boost Conference 2010 -------------------------------- Aspen CO, USA, May 4-10, 2010, www.boostcon.com 2nd Call for participation ---------------------- We invite you to submit session proposals to the 4th Annual Boost Conference: BoostCon 2010 (Aspen CO, USA, May 10-14, 2010). Traditionally the main face-to-face event for all things Boost (www.boost.org) BoostCon 2010 will present leading speakers from the whole C++ community. From using the Boost libraries to writing and maintaining them, from evangelizing to deploying Boost within your organization, from infrastructure and process to vision and mission, and the new C++ Standard, BoostCon brings together the sessions, the colleagues, and the inspiration to support your work with C++ and Boost in particular for the next year. To reflect the breadth of the Boost community, the conference includes sessions aimed at two constituencies: Boost end-users and hard-core Boost library and tool developers. The program fosters interaction and engagement within and across those two groups, with an emphasis on hands-on, participatory sessions. Session topics -------------- Topics of interest include, but are not restricted to, the following: * General tutorial sessions introducing one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * C++0x and how it will change life for users and library writers * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Other topics likely to be of great interest to Boost users and developers Interactive and collaborative sessions are encouraged, as this is the nature of both the on-line Boost community and the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. Session formats --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to Boost and Boost users. Panels Panels feature three or four people presenting their ideas and experiences relating to Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific Boost-relevant skills. Workshops Workshops provide an active arena for advancements in Boost- relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. Submitting a proposal --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions or multiples of 90-minutes. Fractional proposals will be grouped into 90 minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned 90 minute, three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). Submission details ------------------ All submissions have to be done through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=boostcon10. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the BoostCon website and will be available to attendees. For general information on the BoostCon 2010 paper submission or the scope of technical papers solicited, please refer to the conference website at www.boostcon.com. For any other questions about the submission process or paper format, please contact the Program Committee at boostcon10(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to BoostCon. Important dates --------------- Proposal submissions due: Dec 10th, 2009. Proposals decisions sent (tentative program available): Jan 15th, 2010. Fully scheduled program available: Feb 5th, 2010. Session materials due: Apr 15th, 2010. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) David Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

[new Warnings policy] what to do about msvc "deprecation" and "unsafe" warnings
by Robert Ramey 24 Nov '09

24 Nov '09

I've implemented the suggestions in "new warnings policy". It probably DID catch a few bugs which have probably been in there for years. It wasn't as bad as I thought - mostly tedium and a few hours of testing. But now I have a couple of questions: a) I added <toolset>gcc:<warnings>all # ? <toolset>msvc:<warnings>all # == /W4 To my jamfile. With MSVC 9.0 I now get a blizzard of "deprecation" and "unsafe" warnings. If the policy is updated to address this, I will implement the recommendations. Robert Ramey PS I'm wondering if I should replace the above with something which maximizes the warning level for all compiles. Perhaps just <warnings>all #?

16 59

[test] Use of snprintf
by Mateusz Loskot 24 Nov '09

24 Nov '09

Hi, I'm testing Boost with Comeau C/C++ frontent which, as far as I found, does not support mixing C++ and C99 modes. So, compiling Boost.Test library fails because ::snprintf can not be found [1]. I could not find any guidelines regarding use of elements of C99 in Boost libraries (are there any?). Scanning Boost libraries for snprintf shows that it's not widely used, but only in 3 files: boost/test/impl/debug.ipp boost/test/impl/execution_monitor.ipp libs/format/benchmark/bench_format.cpp Would it make sense to remove use of snprintf? [1] https://svn.boost.org/trac/boost/ticket/3558 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

5 10

[msm] scalability
by Simon Gittins 24 Nov '09

24 Nov '09

Hi There I've been looking at the msm library with respect to using it in an application with a reasonable number of transitions and states. In order to simulate a larger application (without having to write more code), I've been using MsmSimple.cpp and EumlSimple.cpp and have been duplicating the rows in the transition table (the original code has 12 transitions, and I would copy and paste all the transitions so we end up with 24, or 36 etc transitions). In this way I hoped to be able to get a reasonable approximation of the compile time performance and limitations of the library. I'm testing with VS8. I have a couple of comments/questions: - I think it would be worthwhile talking a little more about compile time performance in the documentation. Also I'd like to see some suggestions of how to improve compile times (and how factors including the number of entries in a transition table affect the compile time). - Is there provision to split a machine across multiple compilation units (I assume not)? - You include instructions for how to increase the maximum size of an MPL vector, but this only works up to 50 entries. What do we need to do to increase this further? - Euml looks really cool, but I'm getting an ICE when using it with 36 transitions in EumlSimple.cpp (12 and 24 work fine though). - One of my favourite features of boost::statechart is state local storage. It looks like this would have to be done manually in msm? The library is looking really powerful and expressive (not to mention fast!) for small state machines. Cheers Simon Gittins --------------------------------------------------------------------- CONFIDENTIALITY NOTE: Please consider our environment before printing this email.This email and any attachments are confidential and may be subject to copyright, legal or some other professional privilege. They are intended solely for the attention and use of the named addressee(s). They may only be copied, distributed or disclosed with the consent of the copyright owner. If you have received this email by mistake or by breach of the confidentiality clause, please notify the sender immediately by return email and delete or destroy all copies of the email. Any confidentiality, privilege or copyright is not waived or lost because this email has been sent to you by mistake. ---------------------------------------------------------------------

1 0

boost::lambda and math functions
by Peter Foelsche 24 Nov '09

24 Nov '09

I've the following template function: template<typename T> T exp2(const T T0_d) { return exp(0.5*T0_d) + 2*exp(T0_d); } I want to define this as a lambda function in place (but don't know how). It will be used with T=double and T=MyAutomaticDerivativeClass. I've already defined the return type of arithmetic operators applied to MyAutomaticDerivativeClass: namespace boost { namespace lambda { template<class Act, typename X, typename Y> struct plain_return_type_2<arithmetic_action<Act>, X, Y> { typedef ... type; }; } } What else is missing? Thanks Peter

2 2

GGL Review
by Phil Endecott 23 Nov '09

23 Nov '09

Dear All, Here is my review of GGL: I have attempted to try the same examples that I did for my Boost.Polygon review. Unfortunately limited time has made it impossible for me to be as thorough as I would have liked. Here is what I have done, and the issues that I encountered along the way. (You may want to look at my Boost.Polygon review for background. It can be seen here: http://thread.gmane.org/gmane.comp.lib.boost.devel/193204/focus=193758 ) My first exercise was a GUI application in which I wanted to merge a large number of small rectangles into a single more complex polygon. Unfortunately I failed at the first step with this: I wanted to teach the library about my existing types (point, box, etc), but how to do this is not properly documented. It seems that there are some macros (with not-Boost-style names) but their only mention in the documentation is in an example. Yes, I could probably have worked out what to do from the example, but I have limited time and furthermore I don't think it's acceptable to expect a library end-user to learn something relatively fundamental like this from an example. (From my brief look at the example, it does look as if this mechanism is significantly less verbose that what I had to do to teach Boost.Polygon about my types, which is a good thing.) So I moved on to my second example, which reads a file containing the borders of the states and provinces of the US and Canada and determines which ones contains points that the user enters. I implemented this using the geometry types provided by the library, so the question of adapting to types did not arise. This all worked quite smoothly, though I did encounter the following issues, mainly with the documentation, which I imagine could be corrected quite easily: - The docs do not say what the C template parameter in point_xy<T,C> is. - The "complete list of members" for ggl::linear_ring is empty. (Presumably the issue here is that the members are all inherited from the std::container; it could at least say that.) - The documentation for ggl::linear_ring says that V is a "container type e.g. std::vector, list, deque"; it should describe this in terms of std concepts (presumably bidirectional container) so that I know if my own custom type will work. Looking at the code I don't see any concept-checking for this; that would be nice. - The args to the within() function are reversed wrt the equivalent function in Boost.Polygon. This is a good example of the issue that I raised in a previous email, where the generic nature of the concisely-named functions can lead to mistakes. - Doxygen doesn't give the full path to the headers, i.e. "point_xy.hpp" rather than "geometries/point_xy.hpp". - There seems to be a dependency on Boost.Math that isn't mentioned on the list of dependent libraries. - The library doesn't seem to be in namespace boost. I guess the intention is to add this later. This is unusual. - I was surprised that the box class doesn't have width and height members. - I got a page full of warnings from my test program; the cause seemed to be unused parameters in within.hpp, lines 118 and 178. Since I have touched only a small fraction of the library, I imagine there are other places with the same issue. As I said, these are minor issues that I imagine could be corrected quickly. However they did give me the impression that the library is still very much a work-in-progress - especially the documentation - rather than a fully-formed finished work. I don't necessarily believe that a library has to be perfect before it can be accepted into Boost, but I think it needs to be a little less rough around the edges than this. That unfortunately was all of the actual testing that I have been able to do. I'll now discuss other issues: Firstly there's the situation concerning Boost.Polygon. My feeling is that the situation that has developed here is very unfortunate. I think it's extraordinary that Boost can even consider having two incompatible, overlapping Geometry libraries reviewed within a few weeks of each other, with authors who are so publicly antagonistic towards each other. How on earth did we get into this situation? (Answer: IMO, the progress towards review flowed to the current situation by following the path of least resistance, and "someone" - a "leader" ? - should have jumped in earlier to steer things in a more constructive direction.) Anyway, Boost.Polygon has now been accepted (within an hour of this review starting! I mean, was that calculated to be antagonistic?) and we have to consider what that implies. One option is to imagine the two libraries in parallel universes. That may be the most stress-free way. But it's not what would deliver the best results for Boost's end users. What I would prefer to see is some work to investigate how more common ground can be introduced. For example: - Common terminology. ("within" vs. "contains", "extents" vs. "envelope", and dozens more. GGL's not-unreasonable adoption of OGC terminology is an issue here.) - Inter-operable types. I would like to hope that the basic geometry traits classes could be shared. Failing that, perhaps a method of forwarding from one set of traits to the other could be used. I am unsure how deeply the choice of tag dispatch vs. SFINAE makes inter-operation more difficult. Maybe someone could comment on that. Let me say a little about performance. There has been a great deal of discussion about this on the list. My feeling is that all libraries should document the worst-case complexity of all of their functions. In the current case we have polygon boolean operations where I believe I learnt as an undergraduate 20 years ago that they should be O(n log n). Here IIUC the implementation is worst-case O(n^2) but typically better. I feel uncomfortable with that, however many benchmarks and years of real-world use have gone in to it. Is it not possible to contrive an introsort-like "fallback" solution that gives both good typical case performance and an optimally-bounded worst case guarantee? The other controversial implementation issue is floating-point robustness. I'm still not clear what the position of this library is on that. Are we just given assurances that it seems to be robust in real-world use, or is it believed that it actually is certainly robust? I expected to see this discussed in the library documentation, but I don't see anything - maybe I've missed it. If it is "believed to be robust in real-world use", it would be helpful to describe the possible failure modes (e.g. segfault, runs forever, or just outputs the wrong answer.) In summary: Congratulations to the authors on getting their library to this point. I'm sure that it contains much useful code. At this time, the library is let down by incomplete documentation, and I feel it should be rejected for that. I believe it is also essential that some effort is done to find common ground (I'm avoiding saying "merge") with Boost.Polygon. If the authors are unable to work together, then I would prefer that Boost keep things simple for its end users, and avoid years of antagonism on the mailing list, but suggesting that one (or other!) library should exist outside of Boost. To answer the usual questions: - What is your evaluation of the potential usefulness of the library? Very useful. - Did you try to use the library? With what compiler? Yes; gcc-4.x on Linux. - How much effort did you put into your evaluation? I've spent about 5 hours in all. - Are you knowledgeable about the problem domain? I'm not a geometry expert, but I have done projects that could make use of this sort of library. Regards, Phil.

16 51

Lots of issues with Boost.Test in Trunk?
by John Maddock 23 Nov '09

23 Nov '09

I'm getting an absolute ton of warnings - of the kind that are normally errors - from Boost.Test while working on Boost.Integer: compile-c-c++ ..\..\..\bin.v2\libs\integer\test\integer_test.test\msvc-9.0\debug \threading-multi\integer_test.obj integer_test.cpp d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(941) : warning C4535: calling _set_se_translator() requires /EHa d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1128) : warning C4273: 'boost::execution_monitor::catch_signals' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(190) : see previous definition of 'catch_signals' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1199) : warning C4273: 'boost::execution_monitor::execute' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(173) : see previous definition of 'execute' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1340) : warning C4273: 'boost::execution_exception::execution_exception' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(125) : see previous definition of '{ctor}' d:\data\boost\trunk\boost/test/impl/execution_monitor.ipp(1348) : warning C4273: 'boost::execution_exception::location::location' : inconsistent dll linkage d:\data\boost\trunk\boost/test/execution_monitor.hpp(117) : see previous definition of '{ctor}' d:\data\boost\trunk\boost/test/impl/debug.ipp(637) : warning C4273: 'boost::debu g::under_debugger' : inconsistent dll linkage and so on. Normally, I would put this down to a problem with Boost.Integer's Jamfile, but in this I see nothing wrong. Any ideas anyone? Thanks, John.

4 6

[serialization] [1.41] serialization of shared_ptr<> fails to compile
by Marco Jez 23 Nov '09

23 Nov '09

Hello, I'm still having troubles with Boost.Serialization in Boost 1.41. The following example code fails to compile with latest Boost release, while it works with 1.39: #include <boost/archive/binary_iarchive.hpp> #include <boost/serialization/shared_ptr.hpp> #include <boost/shared_ptr.hpp> #include <iostream> // dummy struct with no actual serialization code struct Test { template<typename A> void serialize(A &, unsigned) {} }; int main() { boost::archive::binary_iarchive ia(std::cin); boost::shared_ptr<Test> x; ia & x; return 0; } The compiler (MSVC 9) gives me this error: error C2440: 'return' : cannot convert from 'const boost::serialization::extended_type_info_typeid<T>' to 'const boost::serialization::extended_type_info *'c:\boost\include\boost-1_41\boost\archive\shared_ptr_helper.hppIt seems that an address-of (&) operator is required in shared_ptr_helper.hpp at line 111, that is: ... return boost::serialization::singleton< ... should read: ... return &boost::serialization::singleton< ... This change makes my code compile, but I'm not sure whether it's an appropriate fix or not, as I don't know Serialization's internals. Cheers, Marco

2 1

[test] Boost.Test broken in Trunk
by John Maddock 23 Nov '09

23 Nov '09

Folks, Boost.Test is currently completely broken in Trunk for msvc: compile-c-c++ ..\..\..\bin.v2\libs\test\build\msvc-9.0\debug\asynch-exceptions-on\threading-multi\exception_safety.obj exception_safety.cpp d:\data\boost\trunk\boost/test/detail/unit_test_parameters.hpp(54) : error C2059 : syntax error : '__declspec(dllexport)' d:\data\boost\trunk\boost/test/detail/unit_test_parameters.hpp(55) : error C2059 : syntax error : '__declspec(dllexport)' and: d:\data\boost\trunk\boost/test/impl/progress_monitor.ipp(44) : error C2039: 'log_sink' : is not a member of 'boost::unit_test::runtime_config' d:\data\boost\trunk\boost/test/impl/progress_monitor.ipp(44) : error C3861: 'log_sink': identifier not found Obviously this completely breaks regression testing for msvc as well :-( Strangely, I can't see how any of the recent fixes could have caused this either? John.

2 2

Does anyone use the IBM pSeries?
by Marshall Clow 23 Nov '09

23 Nov '09

We've got a really old bug (#583) with patches to support V8 of this compiler. Looking for someone to apply these patches to a local boost install, and report back on the results.... https://svn.boost.org/trac/boost/ticket/583 -- Marshall

1 0

Using units prefix dynamically to get the appropriate prefix for the size of the value?
by Paul A. Bristow 23 Nov '09

23 Nov '09

I'd like to use the units library prefix (k, M, G ...) system, but I'd really like to determine the prefix dynamically (automatically) depending on the value. For example, if I have a length of 12300 m I'd like an output of "12.3 km" but if my length is 0.0123 m, I'd like an output of "12.3 mm". I can't see how to do this (and including the correct length unit of m or meter of course). Suggestions? Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 3

Possible regression in Boost.Test
by Ian Emmons 23 Nov '09

23 Nov '09

A previously reported issue in Boost.Test, which the bug tracking system indicates as fixed, is still present in the 1.41.0 release. The issue I am speaking of is entitled "Boost:Test pointer error with g++ 64-bit on Mac OS X 10.6 Snow Leopard", discussed here: https://svn.boost.org/trac/boost/ticket/3432 It looks to me like one of two things happened here. Either the bug was fixed on a branch but the branch was never merged into the release, or a merge conflict overwrote the change before it was ever released. In 1.38.0 and 1.39.0 the method in question looked like this: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( test_id_2_unit_type( tu.second->p_id ) == tut_suite ) delete (test_suite const*)tu.second; else delete (test_case const*)tu.second; } } The ticket claims to have fixed the bug like so: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( test_id_2_unit_type( tu.second->p_id ) == tut_suite ) { test_suite const* p = (test_suite const*)tu.second; delete p; } else { test_case const* p = (test_case const*)tu.second; delete p; } } } But in 1.40.0 and 1.41.0 the method looks like this: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map if( ut_detail::test_id_2_unit_type( tu.second->p_id ) == tut_suite ) delete static_cast<test_suite const*>(tu.second); else delete static_cast<test_case const*>(tu.second); } } Perhaps whoever switched the C-style cast to static_cast removed the local pointer variable and reintroduced the bug? In any case, the bug needs to be re-fixed, in the next release, and I would suggest adding a comment so that a future maintainer doesn't eliminate the apparently pointless local pointer variable, like so: void clear() { while( !m_test_units.empty() ) { test_unit_store::value_type const& tu = *m_test_units.begin(); // the delete will erase this element from map // Important: The pointer MUST be copied to local // storage in order to avoid the issue described in // https://svn.boost.org/trac/boost/ticket/3432 if( ut_detail::test_id_2_unit_type( tu.second->p_id ) == tut_suite ) { test_suite const* p = static_cast<test_suite const*>(tu.second); delete p; } else { test_case const* p = static_cast<test_case const*>(tu.second); delete p; } } }

2 1

[thread] unlock on multiple lockables
by Vicente Botet Escriba 23 Nov '09

23 Nov '09

Hi, I don't know if I have already requested that but ... Is there any deep reason to don't provide the equivalent of the free functions lock, try_lock Non-member function lock(Lockable1,Lockable2,...) Non-member function lock(begin,end) Non-member function try_lock(Lockable1,Lockable2,...) Non-member function try_lock(begin,end) to unlock multiple lockables? Non-member function unlock(Lockable1,Lockable2,...) Non-member function unlock(begin,end) Thanks, Vicente -- View this message in context: http://old.nabble.com/-thread--unlock-on-multiple-lockables-tp26471789p2647… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 5

Re: [boost] Meta State Machine library review starts Monday
by Christophe Henry 23 Nov '09

23 Nov '09

>Is there any direct link for an online documentation? Yes, in the Sandbox, which will also be more up to date than the one in the Vault: http://svn.boost.org/svn/boost/sandbox/msm/libs/msm/doc/index.htm

1 0

[1.41.0] [integer] integer.hpp does not compile in MSVC 8.0 with /Za option on
by Adam Badura 23 Nov '09

23 Nov '09

An empty CPP file containing only inclusion of <boost/integer.hpp>: --------------- #include <boost/integer.hpp> --------------- does not compile in MS Visual Studio 8.0 Standard when /Za option ("Disable Language Extensions") is used. The output is following: --------------- D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(67) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(79) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(85) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(119) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(126) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(132) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(138) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(144) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(150) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer_traits.hpp(156) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template D:\Libraries\boost_1_41_0\boost/integer.hpp(88) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(94) : see reference to class template instantiation 'boost::int_max_value_t<MaxValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(89) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(90) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(91) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(101) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(107) : see reference to class template instantiation 'boost::int_min_value_t<MinValue>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(102) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(103) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(104) : error C2065: 'const_min' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(116) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(122) : see reference to class template instantiation 'boost::uint_value_t<Value>' being compiled D:\Libraries\boost_1_41_0\boost/integer.hpp(117) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(118) : error C2065: 'const_max' : undeclared identifier D:\Libraries\boost_1_41_0\boost/integer.hpp(119) : error C2065: 'const_max' : undeclared identifier --------------- I suppose this happens to other editions as well. Also it seems that the same happens with 2005 version. 1.40 version had the same problem and I reported it but it seems no one cared about it. Adam Badura

6 13

Re: [boost] [Review] GGL review starts today, November 5th
by Christophe Henry 23 Nov '09

23 Nov '09

Steven Watanabe wrote: >FWIW, non-virtual destructors are the norm in Boost. >I strongly dislike the idea of having a policy enabling >virtual destructors. I understand this in many cases. OTOH, the geometry types seem to me to be begging for usage the OO way. A small note in the documentation seems to be better than hours of debugging and cannot hurt anyway. The policy was simply a suggestion as it proved a useful solution in my own experience.

1 0

Meta State Machine library review starts Monday
by Christophe Henry 23 Nov '09

23 Nov '09

>I remember hearing alot about UML years ago, but I have not heard very >much about it lately (last 5 years). >Any sense who popular UML is these days. It seems to me it was once >greatly touted as the cure to most of project management and >prototyping needs. >Does anyone have any experience using it? >Where is it primarily used, what kind of projects can benefit from it? I personally try to design my projects with UML, eventhough I mostly use only a few diagrams. It helps quite a bit for documentation and Model-Driven development. But I wouldn't want to start a big discussion about UML. Msm is implementing only a small part of it, the state machine chapter. There were state machines long before UML. The biggest advantage of following the standard whenever possible is that at least there is a standard and it is formally defined, so that you know what you get. If your question was about where to use state machines, this would need a longer answer. Common cases include GUI development, implementation of communication protocols or whenever you might be tempted to define some flags to define the state of a given class (those who never defined a dirty flag, raise your hand ;-) ). In these cases, state machines help you abstract away implementation details and allow someone else understand your code more easily. I also found them a huge help during development as thinking in terms of a model made a problem much easier to solve. HTH, Christophe

1 0

[iostream] closing filtering_ostream
by Vladimir Prus 23 Nov '09

23 Nov '09

Hello, I must be missing something basic, but I cannot find that in Boost.Iostream documentation. Suppose I am writing into filtering_ostream, and I'm done. I wish to close the ostream, flushing whatever remaining data and reporting whatever I/O errors arise to user. However: base64.cpp:17: error: ‘class boost::iostreams::filtering_ostream’ has no member named ‘close’ The documentation say: By default, if the Device at the end of the chain is popped or if the filtering_stream is complete when it is destroyed, all the filters and devices in the chain are closed using the function close. So I assume something is closed in destructor, but what if I don't want the destructor to potentially throw, and instead what to close the stream explicitly? - Volodya P.S. Actually, I'm sure there's a Trac issue saying that potentially throwing destructor is not good.

2 1

Meta State Machine library review starts Monday
by Tom Brinkman 23 Nov '09

23 Nov '09

I remember hearing alot about UML years ago, but I have not heard very much about it lately (last 5 years). Any sense who popular UML is these days. It seems to me it was once greatly touted as the cure to most of project management and prototyping needs. Does anyone have any experience using it? Where is it primarily used, what kind of projects can benefit from it?

1 0

Preliminary submission: generic linear algebra algorithms library Boost LA
by Emil Dotchevski 23 Nov '09

23 Nov '09

I remember some past discussions on this mailing list about the need for similar library in Boost, so I hope it is OK to skip the interest query and request a preliminary review for Boost LA. Boost LA provides a set of generic linear algebra algorithms, primarily for working with vectors and matrices of static size. The library also defines vector and matrix data types, however it allows users to introduce their own types by specializing the vector_traits and matrix_traits templates. Documentation and source code available at http://www.revergestudios.com/boost-la, released under the Boost Software License. Thanks, Emil Dotchevski

9 25

[GGL] Is this a bug, or undocumented behavior?
by Jonathan Franklin 23 Nov '09

23 Nov '09

I have been running some of my own polygon union test cases on the union_inserter. The union_inserter doesn't appear to return a minimal set. E.g. if the start point of a polygon appears in the union, it will appear twice (consecutively). Is this expected behavior? If so, it should probably be documented. I have some other algorithms which expect a sequence of unique points, so I would need to pre-process the result of this function call. Thanks, Jon

2 2

Re: [boost] Core libraries should separated from experimental libraries
by Thomas Klimpel 22 Nov '09

22 Nov '09

Stefan Seefeld wrote: > Wait. You'd like to have releases bundle both, and you don't want to > provide distinct guarantees. What's the point in this split, then ? 1) To make the life of package maintainers (e.g. debian, ubuntu) easier. 2) To make adoption of boost in corporate environments easier, by offering the option to only use the "core" package, potentially cherry-picking only a few of the other libraries from the "complete" package. 3) Have a first step in the direction you want to go, but sufficiently similar to the existing release mode that it may still be possible to reach agreement. 4) Guarantees and what actually works are two different things. Even now, Boost.MPI and Boost.Phyton are probably tested on fewer systems than other Boost libraries without external dependencies. But with respect to your question, the "core" packages would probably actually be quite stable, but without an explicit guarantee for this. Regards, Thomas

2 3

[1.41] Are docs on the website updated?
by Andrey Semashev 22 Nov '09

22 Nov '09

I'm looking at Boost.DateTime changelog page: http://www.boost.org/doc/libs/1_41_0/doc/html/date_time/details.html#date_t… It looks like it has not been updated since the previous release. The source documentation in SVN (release branch) includes changes between 1.40 and 1.41. Is this a known issue?

2 2

new library boost.fiber in vault
by Oliver Kowalke 22 Nov '09

22 Nov '09

I've re factored boost.fiber (-> boost vault http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concu…) The library provides a so called lightweight thread of execution (also known as user-space thread or fiber on WIN32). The API is modeled after boost.thread. Beside a scheduler (currently simple round-robin) for the fibers the library provides sync. primitives like mutex, condition- and event-variables (auto-reset, manual-reset, count-down). Message can be passed between fibers via bounded-/unbounded-fifo. Some feedback would be nice. regards, Oliver

5 15

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 22 Nov '09

22 Nov '09

Thomas Klimpel said: >> I don't know whether I understand your concerns. >> I'm just not sure that it >> will be easy to agree on a set of core >> libraries. If it were just the official boost libraries >> themselves, it would at least be easy to figure out >> which library must necessarily be considered as >> "core". But you will never know exactly which boost >> libraries are used by closely boost related projects, >> like the libraries in the sandbox. For them, the >> official release boost libraries present the "core" >> libraries, and the other sandbox libraries are the >> experimental ones (and as Glas shows, it is quite >> possible that there is even a dependence to another >> experimental library). My major concern is about how to encourage continued innovation. Having potential libraries languish in the review queue for many many months, in some cases, years, can't be a good thing for getting people to want participate in boost. Think about all the people behind the scenes that see the review queue and say, why bother, its too cumbersome. There are alot of good ideas out there, but they need a place to get some exposure, and to flush them out. Debian has demonstrated that a stable and a non-stable branch can be quite successful. Boost should adopt a similar approach.

2 1

Core libraries should separated from experimental libraries
by Tom Brinkman 22 Nov '09

22 Nov '09

Continued from "Shouldn't both logging proposals be reviewed in the same formal review" Vladimir Batov said: > People will eventually start asking to distribute boost in parts, where > the "core" libraries are separated from the "experimental" libraries. >>> Isn't it already the case? Just put yourself into the shoes of a project >>> manager facing overruns, deadlines, etc. I -- an excited s/w eng. -- come >>> over and say -- there is a library that does what we want. Your first >>> questions will be 1) quality? 2) will the lib. around long enough? 3) will >>> the interface be stable enough? 4) etc. >>> In that setting I suspect you'll steer clear from anything >>> "inspirational-only". > For boost to remain popular and successful, this issue will eventually > have to be addressed. Fortunately, it probably does not need to be > addressed for a few years. >>> I'll probably have to disagree. I'd be more likely leaning towards >>> "addressed now". I'm actually sympothetic with your point of view and you've certainly made some strong points. My experience has been similar. Nevertheless, no matter how much you wish boost was something different, Boost's mission statement is pretty clear. I dont see that changing anytime soon. You should know that my favorite development library is Gnome (GLIB). http://library.gnome.org/devel/glib/2.22/ Its a very different library, its mission statement clearly states different priorities. Granted its a 'C' library, but its the library that my teams turns to for most of our programming needs. Its not community based like boost is. Not much original thinking is done their, its all about being practical, minimilistic and writing tight code. Boost is different. The libraries here reach for the moon -- some succeed. Boost is where I come for inspiration and there has been some absolutly brillant successes. However, for practical day to day developer needs, I discourage doing too much advanced C++. Neverthless, boost needs to keep on pushing the envelope. Functional programming is the future and boost is where you come to see whats possible in that domain. I would hate to see that change. If boost's focus is switched to addressing the needs of day to day "average" programmers, I would loose interest. I want boost developers to continue to reach for the stars. If "average" developers happen to find boost useful, of course they can use it, but they need to appreciate where boost priorities have been and use it appropriately.

10 14

[thread] Bug sprint #3097 throwing destructor
by Vicente Botet Escriba 22 Nov '09

22 Nov '09

Ticket Description: thread::detach() and thread::~thread() could throw thread_resource_error while locking thread_info_mutex. Currently it is on windows only. Hi Anthony, A simple reading of the current code let me think that this bug has been solved. thread::~thread() { detach(); } void thread::detach() { release_handle(); } void thread::release_handle() { lock_guard<mutex> l1(thread_info_mutex); thread_info=0; } Do you agree? Best, Vicente -- View this message in context: http://old.nabble.com/-thread--Bug-sprint--3097-throwing-destructor-tp26467… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Review] GGL Review ends today, November 22nd
by Hartmut Kaiser 22 Nov '09

22 Nov '09

Hi all, The review of the Generic Geometry Library officially ends today, November 22nd. Please send in your reviews if you have not done so yet. If you need more time for your review, please get in contact directly with me to work out some individual schedule. Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

GGL Review
by Michael Caisse 22 Nov '09

22 Nov '09

Let me start by apologizing for the short amount of time I was able to put into this review. I have spent about 5 hours reviewing the documentation, looking at some of the source and trying a few examples of mine own. Clearly an enormous amount of work has gone into this library and I feel like it deserves more of my time than I am able to give right now. Nevertheless, I thought it important to review the most critical portions of the library. Based on the library review announcement, GGL is promoting key concepts for describing geometries. Some algorithms are provided. As such, it seems to me that the interfaces and concepts are key and is what I have devoted my time to looking at. And now for the executive summary spoiler: I believe that this library offers well defined concepts for geometry. The design is sound and the extension capabilities appear to be reasonable based on my short trial. I found the interface and concepts to the library usable and therefore recommend acceptance of this library within Boost. That was a wordy way of saying it has a Yes vote from me. ===== What is your evaluation of the design? ===== I am quite pleased with the use of tag-dispatching and strategies. I was happy to see this approach taken and by looking at the documentation and source code it seems sound. I believe this approach offers the greatest latitude for a generic library. ===== What is your evaluation of the implementation? ===== Very clean. Every file I opened and took a look at was readable and easy to follow. The directory structure is obvious and made exploring the library an easy feat. I would like to see ggl::exception inherit from boost::exception instead of std::exception. I was unable to spend time evaluating the implementations of algorithms in any detail. ===== What is your evaluation of the documentation? ===== I found the "Design rationale" section well written and quite applicable to the problem at hand. According to the review announcement: "GGL defines concepts for geometries and implements some algorithms on such geometries." As such, the concepts are paramount to the review and the design rationale provides more than tidbits about the underlying structure of the library. It provides the requirements for compliance to the concepts promoted by the library. Adding generality step-by-step while using a basic concept such as distance allows the reader to follow the logic behind the tag-dispatching and quickly see how extensions and modifications could be incorporated. I am not typically a fan of Doxygen generated docs for generic libraries. Much has already been said about this by other reviewers; however, I did not find the documentation as lacking as some have described. I think the current state is adequate for using the library and did not encounter any problems using the docs while writing my own small tests. I can see that some of the descriptions are a little terse and if I was trying to implement something more complex I might have questions. A few specific comments on the docs......................... design.html section "Return type" typename Strategy::return_type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>( G1 const& G1 , G2 const& G2 , S const& strategy) -- should be -- typename Strategy::return_type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>( G1 const& g1 , G2 const& g2 , S const& strategy) and inline typename distance_result<G1, G2>::type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>(G1 const& G1, G2 const& G2) -- should be -- inline typename distance_result<G1, G2>::type distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…>(G1 const& g1, G2 const& g2) design.html section "Multi" The comments at first confused me. They are correct but by the end of reading a whole page on type traits my eyes were getting tired. Perhaps something like this for clarification: struct distance <http://geometrylibrary.geodan.nl/formal%5Freview/group__distance.html#g22a6…> < GeometryTag1, GeometryTag2, G1, G2, Strategy, false, // G1 is_multi result true // G2 is_multi result > ===== What is your evaluation of the potential usefulness of the library? ===== I think a library implementing generic geometry concepts is extremely useful in many domains. I think this library provides usable concepts for a geometry library with a design and implementation that allows extension to user types and algorithms. ===== Did you try to use the library? With what compiler? Did you have any problems? ===== I found that the examples did not compile using the normal method. I was using the boost_1_41_0 release. cd libs/ggl/example bjam release Changing the Jamfile include requirement to <include>../../.. makes it work fine. I compiled with VC8, gcc-4.3.3, and gcc-4.3.2 m68k-elf cross-compile. The cross-compiler is for a device without FPU and I will continue looking at this library for integer only calculations next week. gcc-4.3.3 spat a bunch of warnings about "use of C99 long long integer constant" from boost/integer_traits.hpp. Not a GGL issue. The 03_polygon_example.cpp tickles some uninitialized warnings with gcc-4.3.3 that originate from intersection.hpp. ===== How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? ===== I spent about 5 hours reviewing the library with a careful read of the Main Page, Design rationale, Spatial set-theoretic operations, and Relation to Boost and std libraries. I also looked over the source code, examples and implemented my own small test cases. ===== Are you knowledgeable about the problem domain? ===== Somewhat. I spent almost 10-years working with GDS-II and other semiconductor mask formats. I worked on transforming data at the "server" level and writing microcode for very accurate and high speed rendering on custom hardware. I have about a year experience working with GIS data sets. I can appreciate the integer versus floating point discussion that has been going on. Different domains have very different requirements. Those who promote the idea that integer only is pointless or floating point is THE solution haven't worked in the other domains. One is not more important than the other; however, concepts described by a library should be able to adapt to either. This library obviously performs in the FP realms and I have no problem envisioning how to adapt types and algorithms to work with it for integer only problems. I hope to explore this domain further in the coming weeks with GGL. Thank you GGL team for your hard work. Thank you Hartmut for your willingness to manage this review. Best regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[serialization][1.41] export.hpp should #include extended_type_info.hpp
by Marco Jez 22 Nov '09

22 Nov '09

Hi everyone. Header file <boost/serialization/export.hpp> has a dependency to <boost/serialization/extended_type_info.hpp>, because it defines the macro BOOST_CLASS_EXPORT_KEY2 which specializes the class template guid_defined<> which, in turn, is defined in extended_type_info.hpp. Perhaps export.hpp should #include extended_type_info.hpp? Regards, Marco

1 0

[build] Performance tests
by vicente.botet 22 Nov '09

22 Nov '09

Hi, I would like to execute some performance test with Boost.Build. Is there a way to force the execution of the tests without building the executables? Are there some examples of performance tests for some Boost libraries? Thanks, Vicente _____________________ Vicente Juan Botet Escribá

3 6

[property_tree]bug in serialization of json, when it process UTF8 encoding string with std::string.
by Qiu Yuzhou 22 Nov '09

22 Nov '09

Hi, Because char is singed in msvc, the ptree serialization code will truncate the value when it greater than 127. Patch for boost_1_41_0\boost\property_tree\detail\json_parser_write.hpp: 21a22,33 > template<typename Ch> > unsigned long to_unsigned( Ch ch ) > { > return static_cast<unsigned long>( ch ); > } > template<> > inline unsigned long to_unsigned<char>( char ch ) > { > unsigned char* p = reinterpret_cast<unsigned char*>( &ch ); > return *p; > } > 46c58 < unsigned long u = (std::min)(static_cast<unsigned long>(*b), 0xFFFFul); --- > unsigned long u = (std::min)(to_unsigned<Ch>(*b), 0xFFFFul); Patch for boost_1_41_0\boost\property_tree\detail\json_parser_read.hpp 141a142 > template<typename CH_T> 148,149c149,150 < u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<Ch>::max)())); < c.string += Ch(u); --- > u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<CH_T>::max)())); > c.string += CH_T(u); 152a154,165 > template<> > struct a_unicode<char> > { > context &c; > a_unicode(context &c): c(c) { } > void operator()(unsigned long u) const > { > u = (std::min)(u, static_cast<unsigned long>((std::numeric_limits<unsigned char>::max)())); > c.string += char(u); > } > }; > 250c263 < | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode(self.c)] --- > | 'u' >> uint_parser<unsigned long, 16, 4, 4>()[typename Context::a_unicode<Context::Ch>(self.c)] Best, Qiu Yuzhou

1 0

ACCU 2010 - Boost folks there ?
by Alp Mestan 22 Nov '09

22 Nov '09

Hi, I'm currently wondering whether I'll go to ACCU 2010 or not. But I just would like to know if any Boost folk will be there, and if there will be some talk or whatever, about Boost ? Thanks. -- Alp Mestan http://alpmestan.wordpress.com/ http://alp.developpez.com/

2 3

[fiber] version 0.1.1 available (incl. docs)
by Oliver Kowalke 21 Nov '09

21 Nov '09

I've uploaded a new version of boost.fiber - it contains the docs as requested. http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Concu… kind regards, Oliver

1 0

Boost.Python question about converters and make_getter
by John Wiegley 21 Nov '09

21 Nov '09

I have a converter registered for a boost::optional<amount_t> object. If I use it as follows, my code works just fine: boost::optional<amount_t> py_price(annotation_t& ann) { return ann.price; } class_< annotation_t > ("Annotation") .add_property("price", py_price) ; However, if I dispense with the intermediary and use make_getter, I get an exception stating that no conversion exists for optional<amount_t>: class_< annotation_t > ("Annotation") .add_property("price", make_getter(&annotation_t::price)) ; The attached file demonstrates this bug using Boost 1.40 and Python 2.6.1. I'm running it on OS X 10.6.2 with g++ 4.4.2. My steps were: g++-mp-4.4 -I/usr/include/python2.6 -I/usr/local/include/boost-1_40 -o bug.so bug.cc -L/usr/local/lib -lboost_python-xgcc44-d-1_40 -lpython -shared $ python >>> import bug >>> x = bug.Annotation() >>> x.price2 # This works just fine >>> x.price # This causes an abort() due to terminate() John

2 2

Re: [boost] Core libraries should separated from experimental libraries
by Tom Brinkman 21 Nov '09

21 Nov '09

C++ is an for expert system and "boost" is a place for the most advanced users of c++ to share experiences. If you don't agree with that basic statement, we don't have much to talk about. I know that calling some one "average" at a particular skill is a loaded statement. It implies a sense of superiority that is uncomfortable to some. However, "average" only comes with a great deal of practice and hard work. Most of us, only ever become average at a handful of things in our life, if we are lucky. Actually, calling someone average at something is highly complimentary. If you are uncomfortable with the term "average", take your sensibilities elsewhere. No back to the issue at hand: Boost needs to separate out the core libraries from the experimental libraries. The libraries within boost that have stable api's should separated from those that don't. Boost needs a system similar to debains. People need to know what parts of boost are backwards compatible. At the same time, we need to allow for complete interface changes to the experimental libraries, to encourage and nurture those libraries that are still in active development, but still very usable. I don't see this as a difficult issue to comprehend at all. Its quite surprising to me that it gets so much push back. This is the single reason why so many people are so resistant to using boost. Hopefully somebody will take up this issue, as I fear without it, boost will become trivialized after the next release of the c++ standard. I'm just saying what people are thinking in the trenches. >From my perspective, as the former review wizard, and long time follower of boost, the current situation of having a dozen libraries in the queue, and probably a dozen more waiting behind the scenes is unacceptable. If we distributed those libraries currently waiting to be reviewed as part of the non-stable part of boost, we could be much more liberal about what libraries get accepted. The important review would then be determining when a library is going to be switched from the non-stable to the stable portion of boost. Tom Brinkman

2 1

[ANN] Elements of Programming study group
by David Abrahams 21 Nov '09

21 Nov '09

FYI, over at http://cpp-next.com we're running a study group on the new book by Alex Stepanov & Paul McJones that might be of interest to generic library authors and users.

2 1

[Ticket #3548] Comeau C++ reports global scope has no int64_t
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, I've been trying to diagnose and fix the problem with missing definition of int64_t and uint64_t when using Comeau C/C++ frontend on Linux 32-bit with GCC 4.x. I submitted all details to the Trac: https://svn.boost.org/trac/boost/ticket/3548 Shortly, the problem is that if <sys/types.h> header is included then <boost/cstdint.hpp> can't import uint64_t/int64_t types. However, if <stdint.h> is used, everything works. 1) Does compile with Comeau + GCC #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 2) 1) Does compile with Comeau + GCC as well #include <stdint.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } 3) Does not compile with Comeau + GCC #include <sys/types.h> #include <boost/cstdint.hpp> int main() { boost::int64_t a(0); } What I found is that there are slight differences, in GNU C Library, in how those integer types are defined: 1) <sys/types.h> # elif __GLIBC_HAVE_LONG_LONG __extension__ typedef long long int int64_t; # endif 2) <stdint.h> # else __extension__ typedef long long int int64_t; # endif More details are in the #3548 ticket report. Shortly, sys/types.h vs stdint.h are somewhat competing and seem to confuse <boost/cstdint.hpp> definitions. Both headers define __int8_t what disables the other definitions, thus depending on which header goes first, that one wins but with different effect regarding int64_t type. I exchanged a few e-mails with Comeau team about it and, as for this moment, we've concluded this slight differences between the two headers seem a bit odd and competing indeed. Comeau team has been very helpful and they are willing to make further investigation of this problem. In the meantime, I decided to report this issue to GNU C Library bugzilla (I should send to their mailing list first, my mistake): http://sourceware.org/bugzilla/show_bug.cgi?id=10990 Ulrich Drepper confirmed that this is not GNU C Library issue: "stdint.h is a C99 header and C99 demands the implementation of long long. The headers are correct." Fair enough. However, it makes it more difficult to me to understand where fixes should go. So, I'd like to ask the Community here for help in diagnosing this problem. My thought for now is that if Boost Integer is used with Comeau C/C++ frontend with GCC, Boost configuration could detect if <sys/types.h> was included first and try to disable its effects, like undefine __int8_t and only let int64_t and uint64_t definitions from <stdint.h> header. I believe that solving this problem is quite important to make Boost compilable with Comeau C/C++ frontend, because, as far as I've tested, it mostly leaks when compiling Boost.Test and tests of Boost libraries. I'd be thankful for any thoughts on this. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

1 0

Status of Comeau toolset for upcoming 1.41.0
by Mateusz Loskot 21 Nov '09

21 Nov '09

Hi, Recently, I've reported [1] issues [2] related to building with Comeau toolset. The upcoming release info [3] does not mention Comeau toolset. May I ask what's the status of support of Comeau? Is it safe to assume Boost 1.41.0 will be usable with Comeau C/C++ ? [1] http://lists.boost.org/Archives/boost/2009/10/157410.php [2] https://svn.boost.org/trac/boost/ticket/3548 https://svn.boost.org/trac/boost/ticket/3558 [3] http://beta.boost.org/users/news/version_1_41_0 Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

4 5

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

> If I had a library that only implemented quad-trees and then proposed > it as Boost.Generic Spatial Index, I would think the reviewers would > have something to say about that. > Please note that GGL is a "geometry library" implemented using "generic programming". Though we aim to a broad scope, we don't aim to "generic geometry" Barend p.s. (please make the To: of this thread: boost, and not boost-users)

2 2

Updating the Boost Review Process Was: [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
by Jose 21 Nov '09

21 Nov '09

I propose these 3 changes (starting with the word ADD: below) to the current review policy in http://www.boost.org/community/reviews.html I realize that there is no mention to the word "vote" in the review policy, just "review comments". See message below for rationale on why these may be good changes. ----------------------------------- INTRODUCTION ... The final "accept" or "reject" decision is made by the Review Manager, based on the review comments received from boost mailing list members. ADD: Consensus should be objectively measured with the votes and otherwise the right to accept solely by the review manager could be revoked. ... RESULTS At the conclusion of the comment period, the Review Manager will post a message to the mailing list saying if the library has been accepted or rejected. A rationale is also helpful, but its extent is up to the Review Manager. If there are suggestions, or conditions that must be met before final inclusion, they should be stated. ADD: In conflicting reviews or with little consensus the Review Manager should justify way the library was accepted or not accepted. NOTES FOR REVIEW MANAGERS ... ADD: The review manager must not have or have had business ties with the library author/organization. ... ---------- Forwarded message ---------- From: Jose <jmalv04(a)gmail.com> Date: Mon, Nov 16, 2009 at 12:09 PM Subject: Re: [boost] [Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale To: boost(a)lists.boost.org Hi, I am not expert in geometry but what matters is that boost continues to provide generic libraries (if possible !) like BGL, GIL, .. I think there is no blame on library authors which make a huge effort. What was broken is the review process, and some of the reasons why the review process was broken were: 1) The result of the review was 6 positive to 4 negative, when boost normally aims for consensus. This is the most objective point. Also, the issues the review manager was proposing to be fixed would not change the votes as the library was not appropiate even for 2D geo applications 2) The scope of GTL was changed before the review (see snippet 2 at the end) but the review docs still mention a wider app focus (see snippet 1 at the end). This confusion appeared when GTL was being reviewed. 3) The review manager didn't have time for the review (if you look at the apology at the beginning of the review email summary) 4) The GGL library proposal, which had been iterating the design with input from boost, in my opinion received an unfair treatment in the way the schedule was managed. 5) Boost failed to set the scope for a geometry library/ies and created tension with candidate library authors There are more points but I don't like long emails. I propose to change the current review process: http://www.boost.org/community/reviews.html ----------------- NOTES FOR REVIEW MANAGERS Decides if there is consensus to accept the library, and if there are any conditions attached. ----------------- AMENDMENT 1 that consensus should be objectively measured (with the votes) and otherwise the right to accept solely by the review manager could be revoked. Clearly there was no consensus in this library, and no clear discussion if one single library was possible (I understand your points that multiple libraries in this case may be preferable but still that is not incompatible with a complete design discussion) AMENDMENT 2 The review manager should have or have had no business ties with the library author/organization. Amendment 2 is not related to this review, but this would support the current transparency. I feel that in some cases there might be a vague prejudice in favor of big/important/known organizations to get their libraries accepted regards jose --------------------------------------------- Snippet from Boost.Polygon docs http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm "These so-called Boolean algorithms are of significant interest in GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD, and many more application areas, and providing them is the primary focus of this library." 7/19/09 I am changing the name of my library from GTL (Geometry Template Library) to boost::polygon and narrowing the scope from "computational geometry" to "polygon manipulation". This scope precisely describes the current scope of what is implemented. It also clarifies the position of the library relative to similar proposals. ------------------------------------------------

17 64

Fixing warnings - progress
by Paul A. Bristow 21 Nov '09

21 Nov '09

I've updated https://svn.boost.org/trac/boost/wiki/WarningFixes on progress we are making (a little effort would go a long way to fixing the remaining warnings) to show what has been fixed, and where we need more information, and more work. Please post information to be added, or edit the page yourself - it is a wiki after all ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost-users] [Review] GGL review starts today, November 5th
by Barend Gehrels 21 Nov '09

21 Nov '09

Hi Michael, Thanks for your review! I don't understand some of the problems you have had, so I'll explain or ask some things. > Some general thoughts: > > Integration with Boost.Units should be encouraged. I don't think > is_angle, etc should be in GGL. If I have a vector of quantities, > things should Just Work. > I think you mean is_radian, which is used internally to know if spherical coordinates are in degree's or in radian's. We didn't thought it a good idea, just for this one piece, to integrate with another boost library. Though for some coordinate systems it certainly would make sense (see also answer to Brandon's review) > As it is, Barend favors GIS, > Bruno favors gaming, and the resulting library is a mashup of GIS > terms and other arbitrary terminology and it excels in no one > particular area. > Thanks for your namespace suggestion in another thread. This will help to improve this. > > Yes. I spent a few hours trying to get it to with ESRI, a leader in > the GIS domain. Their API is completely COM based however, and it > proved extremely difficult to get working with GGL. I wasn't able to > successfully do this with Boost.Polygon either. > Yes, it would be very cool if this would work nicely, and it is meant to work. It is not clear to me if you get anything working, or nothing. However, I'll come back to you because it would be very useful if there is an example, showing integration between GGL and ESRI. > The Examples link at the bottom of the main page of documentation is > broken (last line), This was not a hyperlink (could be though, sorry) > and custom_point_example.cpp doesn't compile - > cs::cartesian needs to be ggl::cs::cartesian. > This surprises me. It is declared within a macro, so ggl namespace is not necessary there. I've not heard of this problem before, and it seems to compile fine normally for everyone (so I must now say: for most people). Are you sure? > It was not clear what includes I had to include to register my custom > point type. GEOMETRY_REGISTER_POINT_2D is defined in > ggl/geometries/register/point.hpp, but the following won't compile: > Normally, including <ggl/ggl.hpp> is enough, but indeed this should also compile, will be add the dependency. > It also doesn't appear that the custom point type can be in its own > namespace when using these registration macros. For instance, the > following doesn't compile: > > namespace foo { > struct test { > double x, y; > }; > } > GEOMETRY_REGISTER_POINT_2D(foo::test, double, ggl::cs::cartesian, x, y) > [...] I had to have "using namespace math" just to register my point correctly. > Yes, that was a known issue and should have been documented. We didn't search for the solution yet, it must be simple. > Using the haversine strategy caused compilation errors > because there was no overload of get_as_radian<>() for my point type. > > 1. It's not documented that the haversine strategy requires > get_as_radian, or at least I didn't see it. > Spherical coordinate systems use get_as_radian internaly (using is_radian), but it should never be necessary to overload it yourself. The normal procedure is registering your point as cs::spherical<degree> coordinate system. That would have been fine, and that was expected for the haversine function. You probably used cs::cartesian, and it didn't know if it was degree or radian. Anyway, I see your problem though, we will correct this and/or document this better. > I finally got haversine working with my point type by defining > get_as_radius as above, and the result was correct. I must say, it is a great workaround, nice that you got it working also like that. > This almost went smoothly, except that I had to specialize > strategy_tag, but didn't see any mention of this requirement in the > docs. Once I did that, my distance strategy worked and returned the > same value as haversine for values along the equator. > To be complete, the vincenty is also part of the gis extension, it was first not included, but later we wanted to show that 07 graph example, showing nicely the integration between BGL and GGL (there were not too many comments on this though). I understand that you implemented your own strategy, very cool. And indeed, you should specialize your strategy_tag, if (and only if) you want to use that one by default. Another way would have been that you specified the strategy as additional parameter. Great you got it all working like this! Of course, everything should work, but you did use some quite advanced features of GGL, and I like to see that you did succeed there. We will work on the documentation so these scenario's will cause less problems. Thanks again, Barend

1 0

Help needed in fixing warnings
by John Maddock 21 Nov '09

21 Nov '09

Dear all, I've started a wiki page here: https://svn.boost.org/trac/boost/wiki/WarningFixes for folks to collaborate on fixing warnings from Boost libraries. As noted the initial effort should be directed towards core libraries - those that get included and reused by other libraries. You can help by: * Running the tests for your favorite libraries (those not already listed, or with "unknown" status), and updating their "Status" field to reflect whether any work is needed. * Filing bug reports if it's not obvious how to silence the warnings. * Filing patches if the fixes are obvious. * Fixing the code if you're a library author! There's something for everyone there, whether you're a Boost newbie, or a hardened veteran, so I hope that many hands can make light work of this! Cheers, John.

9 23

[1.41.0] iostreams/device/mapped_file.hpp has no include guards
by troy d. straszheim 21 Nov '09

21 Nov '09

making a trac ticket... -t

2 2

[1.41.0] PDF Build of documentation available.
by John Maddock 21 Nov '09

21 Nov '09

A PDF build of the documentation for Boost-1.41 (for those libraries that support it) is now available from the usual sourceforge download site: https://sourceforge.net/projects/boost/files/ in the boost-docs/1.41.0 folder. Direct URL's are: https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (23Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (22.5Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (22.2Mb) https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_… (21Mb) Enjoy! John.

2 1

Shouldn't both logging proposals be reviewed in the same formal review?
by Andreas Huber 20 Nov '09

20 Nov '09

According to the schedule, John Torjo's Log2 library will be reviewed soon (currently 3rd in the queue). There's another logging proposal by Andrey Semashev (currently 13th in the queue). It seems to me that these proposals are sufficiently close in functionality that only one of them should be accepted into Boost. Therefore, wouldn't it make sense to review both libraries in one (longer) formal review? Regards, -- Andreas Huber When replying by private email, please remove the words spam and trap from the address shown in the header.

19 42

[Variant] [BGL] Variant<edge_descriptor, edge_descriptor> is not EqualityComparable
by Cosimo Calabrese 20 Nov '09

20 Nov '09

Hi to all, this discussion is linked to "Boost.Variant is not EqualityComparable". I've opened a new one because to involve the BGL argument. The problem is simply this. I've created a union graph adaptor, that provides a "union view" of two graphs; in that adaptor, the edge_descriptor is defined like this: typedef boost::variant< WR1<typename graph_traits<Graph1>::edge_descriptor>, WR2<typename graph_traits<Graph2>::edge_descriptor> > edge_descriptor; Now I would to use that graph to the Dijkstra's algorithm, that requires that the edge_descriptor models the EqualityComparable concept. But as we know, boost::variant doesn't support the inequality expression ( v1 != v2 ). I've tried to add it from my code (I would avoid to modify the boost lib), but it doesn't works. I'm using MSVS 2005 on WinXP, boost 1.38. I've tried to add the following line, as suggested by Stefan Strasser (thanks Stefan): using namespace std::rel_ops; to add the generic operator!=(), but the compiler doesn't find it, the compiler error is the same. Now I try to provide to you more details. If it isn't enough, I can provide the entire code. I've defined the graph adaptor like this: ////// union_graph.hpp ////// #include <boost/graph/graph_traits.hpp> #include <boost/graph/properties.hpp> #include <boost/graph/adjacency_iterator.hpp> #include <boost/graph/graph_utility.hpp> #include <boost/graph/exception.hpp> #include <boost/variant.hpp> namespace boost { template <typename T> class WR1 { /* ... */ }; template <typename T> class WR2 { /* ... */ }; template <typename Graph1, typename Graph2> class union_graph { public: typedef Graph1 graph_type1; typedef Graph2 graph_type2; // Constructor union_graph( Graph1& g1, Graph2& g2 ) : m_g1(g1), m_g2(g2) { /* ... */ } // Graph requirements typedef boost::variant< WR1<typename graph_traits<Graph1>::vertex_descriptor>, WR2<typename graph_traits<Graph2>::vertex_descriptor> > vertex_descriptor; /* ... */ // IncidenceGraph requirements typedef boost::variant< WR1<typename graph_traits<Graph1>::edge_descriptor>, WR2<typename boost::graph_traits<Graph2>::edge_descriptor> > edge_descriptor; /* ... */ }; // EqualityComparable concept, requested by IncidenceGraph concept template <typename Graph1, typename Graph2> inline bool operator!=( const typename boost::graph_traits< boost::union_graph<Graph1, Graph2> >::edge_descriptor& left, const typename boost::graph_traits< boost::union_graph<Graph1, Graph2> >::edge_descriptor& right ) { return !( left == right ); } and I've used it like this: ////// main.cpp ////// #include "union_graph.hpp" int main() { typedef adjacency_list<...> Graph1; typedef adjacency_list<...> Graph2; typedef union_graph<Graph1, Graph2> UG; Graph1 g1( 10 ); Graph1 g2( 10 ); UG ug( g1, g2 ); graph_traits<UG>::edge_descriptor e1; graph_traits<UG>::edge_descriptor e2; tie( e1, existence ) = edge( v1, v2, g ); tie( e2, existence ) = edge( v1, v2, g ); e1 != e2; } The first part of the template compiler error is: 1>D:\dev\CommesseAperte\Sviluppo\TELLUS36_Librerie\boost_1_38_0\boost/concept_check.hpp(233) : error C2678: binary '!=' : no operator found which takes a left-hand operand of type 'boost::variant<T0_,T1>' (or there is no acceptable conversion) 1> with 1> [ 1> T0_=boost::WR1<boost::detail::edge_desc_impl<boost::directed_tag,__w64 unsigned int>>, 1> T1=boost::WR2<boost::detail::edge_desc_impl<boost::directed_tag,__w64 unsigned int>> 1> ] Can someone help me? I wouldn't hack the lib, because I will do it to every new version of Boost... Thanks in advance, Cosimo Calabrese.

5 17

[type_traits][V1.41] is_base_of<void, void> gives different results for gcc and vc
by Hartmut Kaiser 20 Nov '09

20 Nov '09

Hey, I just realized that is_base_of<void, void> gives different (inconsistent) results at least for gcc 4.3.2 (which evaluates this to false) and vc2005sp1 (evaluates to true, as earlier versions of boost did consistently, btw). This is truly a border case, but should expose consistent behavior anyways. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

3 5

[Release Mgt] Vladimir Prus joins release management team
by Beman Dawes 20 Nov '09

20 Nov '09

Vladimir Prus, aka Volodya, has been a big help in getting out timely, high-quality releases for a long time, and has now become an official release manager. Please welcome Volodya to the release team! --Beman --Daniel --Eric --Rene

1 0

Re: [boost] [Boost C++ Libraries] #3644: Getting starting simplified build from source should use a log file.
by Paul A. Bristow 20 Nov '09

20 Nov '09

> -----Original Message----- > From: Boost C++ Libraries [mailto:noreply@lists.boost.org] > Sent: Thursday, November 19, 2009 8:44 PM > Cc: boost-bugs(a)lists.boost.org > Subject: Re: [Boost C++ Libraries] #3644: Getting starting simplified build from source > should use a log file. > > #3644: Getting starting simplified build from source should use a log file. > --------------------------------------+------------------------------------- > Reporter: pbristow | Owner: > Type: Bugs | Status: new > Milestone: Boost 1.42.0 | Component: Building Boost > Version: Boost 1.41.0 | Severity: Problem > Keywords: simplified library build | > --------------------------------------+------------------------------------- > > Comment(by vladimir_prus): > > Would printing this information at the end of the build address your > concerns? Well yes it would, but surely it is always better to have a log file so you can check it went OK? Or will checking %errorlevel% tell the user that? But checking %errorlevel% doesn't tell you what libraries you have just built. (If you are using the simple 'default' build, you may not care?) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

2 2

Re: [boost] [Boost C++ Libraries] #3646: Boost.test build of libraries - warnings ttat could be silenced.
by Paul A. Bristow 20 Nov '09

20 Nov '09

> -----Original Message----- > From: Boost C++ Libraries [mailto:noreply@lists.boost.org] > Sent: Friday, November 20, 2009 3:24 AM > Cc: boost-bugs(a)lists.boost.org > Subject: Re: [Boost C++ Libraries] #3646: Boost.test build of libraries - warnings ttat could > be silenced. > > #3646: Boost.test build of libraries - warnings ttat could be silenced. > ---------------------------+------------------------------------------------ > Reporter: pbristow | Owner: rogeeff > Type: Patches | Status: new > Milestone: Boost 1.42.0 | Component: test > Version: Boost 1.41.0 | Severity: Cosmetic > Keywords: test warnings | > ---------------------------+------------------------------------------------ > > Comment(by steven_watanabe): > > These should probably be disabled in the source, since Boost.Test can be > used with direct #include instead of a library. Yes - but I was trying to be realistic and not over-flagellate ;-) Paul

1 0

Re: [boost] Shouldn't both logging proposals be reviewed in the same formal review
by Tom Brinkman 20 Nov '09

20 Nov '09

Vladimir Batov wrote >> Yes, it sounds very uplifting and inspiring... and I would agree with that >> whole-heartedly... if I considered Boost merely the place of purely academic >> exercise. For many "average" programmers though the Boost libs is first and >> foremost a product that they want to *use* uniformly throughout a project, many >> projects. In that light from the commercial deployment and project management >> points of view having 2 (or worse -- plethora of) functionally-similar >> facilities readily available is a nightmare as some will end up using one >> facility and some others will prefer another facility. Shared knowledge is >> fragmented (people rarely have time and capacity to know all), code reviews, >> maintenance are difficult, the ultimate product looks unprofessional due to >> inconsistencies (in case of logging configurations, formats, destinations will >> be different). It's not an imaginary situation -- our project for various >> reasons ended up using 3 logging facilities with the very real problems >> described above. Rectifying the problem now is an expensive and tiring exercise. >> Do not get me wrong. I am all for creativity, innovation and healthy competition >> of ideas. However, all that does not have to be dumped onto the user to decide >> -- users often have no time, capacity, qualifications, freedom to make an >> educated choice. More so, users often *want* the gurus (and the level of the >> Boost community is most certainly considerably higher than the average) to make >> that educated choice for them. It's like one going to a financial planner for >> help and the planner dumping all the options on to that poor soul. Now that poor >> customer/user has to be a financial planner himself to make an educated choice. It seems to me that you are trying to make boost into something its not. Boost has never been in the business of picking the best library in a particular domain. Its a place where promising libraries can live for a while, get used, and inspire new ideas and approaches. Some of these might make into the c++ standard. I do however agree with your larger point that boost does not SCALE well. Ten years from now, its highly likely that boost will become too large to manage. People will eventually start asking to distribute boost in parts, where the "core" libraries are separated from the "experimental" libraries. For boost to remain popular and successful, this issue will eventually have to be addressed. Fortunately, it probably does not need to be addressed for a few years.

3 2

Re: [boost] [python] 1.41.0 importing python extensions fails
by Okko Willeboordse 19 Nov '09

19 Nov '09

Solved it mistake on my side sorry

1 0

[python] 1.41.0 importing python extensions fails
by Okko Willeboordse 19 Nov '09

19 Nov '09

Using MSVC 2008 on windows server 2003, Python 2.6.2 Importing python extension modules fails. As an example I compiled the tutorial hello world example; char const* greet() { return "hello, world"; } #include <boost/python.hpp> BOOST_PYTHON_MODULE(hello_ext) { using namespace boost::python; def("greet", greet); in to a dll named hello_ext.pyd. When I try to import the extension I get; >>> import hello_ext Traceback (most recent call last): File "<stdin>", line 1, in <module> ImportError: DLL load failed: The specified module could not be found. In the debugger I see that hello_ext.pyd is loaded and unloaded; 'python': Loaded 'D:\Projects\GAIUS\owillebo\temp\test\Debug\hello_ext.pyd' 'python': Unloaded 'D:\Projects\GAIUS\owillebo\temp\test\Debug\hello_ext.pyd' Digging in to it. Can anyone confirm this?

1 0

Shouldn't both logging proposals be reviewed in the same formal review
by Tom Brinkman 19 Nov '09

19 Nov '09

I was the review manager of the two futures libraries and a former review wizard. Two issues that I see: 1) Should we review two or more libraries at the same time No. Because of time commitments and lack of review managers, coordinating two reviews at the same time is too difficult. It has not worked. 2) Should we approve libraries that have significant duplication with another library already in boost? Yes. Each library should be reviewed independently, and approved if it meets the boost community standards. Boost libraries already has lots of overlap, no reason to change at this point. What we should do is encourage the authors to work together submit a combined library. Unfortunately, that has not worked either. The trend is probably going to be more and more library duplication, but this does not concern me. I would find it perfectly acceptable if another "command line" parser was approved, or even if another text parser was approved. The more the better. It shows that boost is still interesting place to come and see what talented c++ developers are up too. There are many ways to abstract a solution and build an interface around it. Boost should encourage a diversity of approaches.

2 1

[thread] 1.41.0 MSVC warning
by Okko Willeboordse 19 Nov '09

19 Nov '09

Building 1.41.0 went fine. Compiling my code failed because of a compiler warning. I had to modify ..\thread\future.hpp like below to silence MSVC 2008 SP1 on windows server 2003; 409 #pragma warning(push) 410 #pragma warning(disable: 4267) 411 all_futures_lock(std::vector<registered_waiter>& futures): 412 count(futures.size()),locks(new boost::unique_lock<boost::mutex>[count]) 413 { 414 for(unsigned i=0;i<count;++i) 415 { 416 locks[i]=boost::unique_lock<boost::mutex>(futures[i].future->mutex); 417 } 418 } 419 #pragma warning(pop)

1 0

Fix graph_parallel compilation
by Vladimir Prus 19 Nov '09

19 Nov '09

Current trunk does not compile for me as follows: ./boost/graph/distributed/detail/mpi_process_group.ipp: In function ‘int boost::graph::distributed::receive(const boost::graph::distributed::mpi_process_group&, int, int, T&)’: ./boost/graph/distributed/detail/mpi_process_group.ipp:722: error: ‘stderr’ was not declared in this scope ./boost/graph/distributed/detail/mpi_process_group.ipp:724: error: there are no arguments to ‘fprintf’ that depend on a template parameter, so a declaration of ‘fprintf’ must be available ./boost/graph/distributed/detail/mpi_process_group.ipp:724: note: (if you use ‘-fpermissive’, G++ will accept your code, but allowing the use of an undeclared name is deprecated) ./boost/graph/distributed/detail/mpi_process_group.ipp: In function ‘typename boost::enable_if<boost::mpi::is_mpi_datatype<T>, std::pair<int, unsigned int> >::type boost::graph::distributed::receive(const boost::graph::distributed::mpi_process_group&, int, int, T*, size_t)’: OK to apply the attached? - Volodya

2 2

[BGL] [PropertyMap] Key param is passed by value in put function
by Cosimo Calabrese 19 Nov '09

19 Nov '09

Hi to all, I've noticed that the put function that takes a generic put_get_helper map, takes a key param. The question is: why the key param is passed by value? Is any reason for this? The key value is not modified setting the property map. I've noticed it because in my graph type the descriptors are variant, and so every time I've to set a property map, a new copy of the variant is created. I've reported the function below, for sake of comfort. It is in boost/property_map.hpp template <class PropertyMap, class Reference, class K, class V> inline void put(const put_get_helper<Reference, PropertyMap>& pa, K k, const V& v) { static_cast<const PropertyMap&>(pa)[k] = v; } Best regards, Cosimo Calabrese

3 4

Boost release 1.41.0 available
by Beman Dawes 18 Nov '09

18 Nov '09

Boost release 1.41.0 is now available. This release contains one new library and numerous bug fixes for existing libraries. For details, including download links, see http://www.boost.org/users/news/version_1_41_0 The release can also be downloaded directly from SourceForge. See http://sourceforge.net/projects/boost/files/ To install this release on your system, see http://www.boost.org/doc/libs/1_41_0/more/getting_started/index.html Thanks, --The Boost release team

3 2

passing compiler options
by Lorenzo Bettini 18 Nov '09

18 Nov '09

Hi after running bootstrap.sh, if I want to pass my compiler (in this case cygwin), is it correct to modify project-config.jam and replace if ! gcc in [ feature.values <toolset> ] { using gcc ; } with using gcc : : : <compileflags>-DBOOST_WINDOWS_API <compileflags>-mno-cygwin <linkflags>-mno-cygwin ; this way, am I sure that these compiler options will be passed to the compiler? thanks in advance Lorenzo

2 4

GGL issues
by Jose 18 Nov '09

18 Nov '09

Hi, I am reviewing the library and trying to adapt some of the shapelib examples that don't seem to be included in the formal_review distribution. Any reason why the latlong.hpp is not included ? Without the typedefs the examples are harder to get working e.g. ring_ll_deg or area ring regards

3 16

GGL documentation issue
by Thomas Klimpel 18 Nov '09

18 Nov '09

Dear GGL authors, This is still not a review. However, the documentation issue I found doesn't allow be to submit a (positive) review before the issue is clarified. > - What is your evaluation of the documentation? Looks like "work in progress" to me. There are examples, but examples are not a sufficient substitute for a proper documentation. But I wonder whether it's just me, or whether the documentation is really insufficient. I know the library has a "ring concept", so let's try to find out from the documentation what it is. On "Related Pages" -> "OGC (Open Geospatial Consortium)" the following definition can be found: linear_ring: Sequence of point values with linear interpolation between points, which is closed and not self-intersecting On "Modules" -> "geometry concepts: defines and checks concepts for geometries" -> "ring concept More..." the following can be found: template<typename Geometry> class ggl::concept::Ring< Geometry > ring concept Formal definition: The ring concept is defined as following: * there must be a specialization of traits::tag defining ring_tag as type * it must behave like a Boost.Range * there can optionally be a specialization of traits::point_order defining the order or orientation of its points, clockwise or counterclockwise. * either it can behave like the std library, having pushback * or it can implement a mechanism for clearing and adding points. This is the same as the for the concept Linestring, and described there. Note: to fulfil the concepts, no traits class has to be specialized to define the point type. The point type is taken using boost::range_value<X>::type Both explanations don't seem to clarify what a ring really, so let's continue to browse the documentation. On "Modules" -> "A Generic Geometry Library (web-copy of article for BoostCon'09)", it is described how a triangle can be handled as a linear ring. This is indeed illuminating, because I learn from it that a "ring" is indeed a geometric figure with a non-zero area, and that there is no requirement for the first and last point of the ring to be equal. And "Example" -> "c04_b_custom_triangle_example.cpp" also contains the example from the article, so I went and tried it. It seemed to work well, but then I tried what happens when I comment out the area specialization. Suddenly the area was zero??? And I'm really confused now: What I initially wanted to find out was whether a ring is a geometric figure with a non-zero area. Now I'm wondering whether there is a requirement for the first and last point of a ring to be equal. A look at "Example" -> "c04_a_custom_triangle_example.cpp" indicates that this might indeed be the case: struct triangle : public boost::array<ggl::point_xy<double>, 4> My conclusion is that the documentation of the "geometry concepts" is insufficient, because I'm not even able now to tell whether there is a bug in the library or a bug in the example. And that the examples that are provided instead of a proper documentation contradict each other doesn't help either. Please clarify: a) Do you agree that the documentation of the "geometry concepts" is currently insufficient, because both the intended semantic meaning and the exact constraints on valid "values" for objects modeling the "geometric concepts" are not documented? b) Why are there two examples that more or less contradict each other? c) Is there a bug in the area function, or are both "Modules" -> "A Generic Geometry Library (web-copy of article for BoostCon'09)" and "Example" -> "c04_b_custom_triangle_example.cpp" wrong? Regards, Thomas

2 3

[1.41] mpi + python + multiple variants
by Vladimir Prus 18 Nov '09

18 Nov '09

There was a report on IRC that 1.41 beta fails to build with the following command: ./bjam threading=single,multi --with-python --with-mpi --layout=versioned because Boost.Build reports target name clash on stage/lib/mpi.so. And sure it does. The mpi Jamfiles specify that a Python extension called 'mpi' should be built if Python is available. However, nothing adjusts the name of python extension, so ST and MT variants get the same name, and clash. For all I know, this problem was there all the time, so holding 1.41 for it is not necessary. But still would be nice to fix, and for that, I need an opinion from either MPI or Python experts here. 1. Shall the name of extension module be adjusted? If so, how? I doublt that Python users will jump with joy if asked to do 'import mpi-mt-gd-gcc34'. 2. Shall a specific variant be pinned? 3. Anything else? Thanks, Volodya

2 3

Another GGL review
by Jose 18 Nov '09

18 Nov '09

YES, the library should be accepted (only show stopper is that it has to include the non-cartesian coordinates so that the library can be useful as is without resorting to additional extensions) - What is your evaluation of the design? The design is good and has taken input in multiple iterations from the community. Also, it's a very strong point that the library provides open benchmarks with multiple libraries so that the performance standing of the library can be evaluated. The week point is that the library does not satisfy the needs of some application domains (e.g. VLSI domain) where floating point types are not acceptable. It's unfortunate that this review has been muddled by the recent boost.polygon review. This is a topic beyond this review and specific to the boost review process. I think in this case it should be determined by at least two experts whether it is possible to have a generic library that can satisfy the multiple application domains, and if yes, then take GGL as the base, update the design and incorporate boost polygon algorithms as appropriate. - What is your evaluation of the implementation? The library should incorporate the key extensions that make it useful right away, i.e. non-cartesian coordinates. Not including these will hamper the usefulness and adoption of the library. An example where this happened was the GIL library, it had a wonderful generic design but a key numeric extension was not included in the Boost library. As a result, the adoption has been very limited and the key extension not updated or bug-fixed, with some algorithms being ported and some libraries being built on top, but not wide use. I think the problem with the PROJ dependency could be handled similary to the MPI library, that provides bindings to the C library. - What is your evaluation of the documentation? The docs have to show how it can be used in multiple domains, GIS, CAD, VLSI, .. Same with the examples. - What is your evaluation of the potential usefulness of the library? Very high. A broad library that could be a great match for Boost. - Did you try to use the library? With what compiler? Yes. g++ 4.4.1 on x86_64 Did you have any problems? YES, because the non-cartesian extension was not part of the library. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? 10+ hours. Studied both GTL/GGL papers/presentations presented in BoostCon09. - Are you knowledgeable about the problem domain? Yes, the GIS application domain but not core geometry and other important domains.

8 21

Differences between trunk and release for 1.41.0
by Marshall Clow 18 Nov '09

18 Nov '09

Based on svn revision 57747 -- Marshall

1 0

Re: [boost] [Boost.Locale] For Preliminary Review of Boost Community (with Full documentation)
by Fabio Fracassi 18 Nov '09

18 Nov '09

Hi, just wanted to send a short note of appreciation for your library (http://cppcms.sourceforge.net/boost_locale/docs/) From glancing at the documentation there will finally be a good localization lib in boost. (Where I think it is sorely needed, since localization should be a standard feature IMHO) I have used QT's localization features before, and really liked them. This was something I really missed since I am working with std strings, but it seems that your locale lib is au-par with what Qt has to offer. Maybe one could even make it compatible with QT .ts/.qm files one day, so that one could use the fine QtLinguist Tools. (I have never used the gettext tools) Regards, and keep up the good work Fabio Fracassi P.S. Sorry that I messed up threading, but I didn't find the original message.

2 2

Bug sprint suggestions
by Marshall Clow 18 Nov '09

18 Nov '09

If you would like to participate in the bug sprint but don't know where to begin, here are some suggestions. Here are a list of open issues that aren't connected to any milestone: <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Some of these are feature requests, and don't really have a milestone where they will be provided, but sometimes the bugs tend to get missed. -- Marshall

1 0

[1.41.0] Release candidate 3
by Beman Dawes 18 Nov '09

18 Nov '09

The third, and hopefully final, release candidate is now available. The VC++ build problems are resolved, at least on my system. http://boost.cowic.de/rc/boost_1_41_0.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.tar.gz - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.7z - Windows line endings http://boost.cowic.de/rc/boost_1_41_0.zip - Windows line endings Please download and do a test build, reporting successes as well as failures. The release procedures have been updated so that in the future the release manager will do at least one build locally, to try to head off repeats of today's fiasco. --Beman

6 14

The Bug sprint has begun!
by Marshall Clow 18 Nov '09

18 Nov '09

The bug sprint will from today until Sunday, November 29th. For those in the USA, that includes the long Thanksgiving weekend. As of 8:00 AM PST today, there are currently have 859 open tickets. The goal is to classify and fix bugs, and to close resolve Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the last bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 (Note that there are 10 tickets that have no owner!) Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (Many old milestones here, including 62 tickets w/o a milestone) and, of course, the main report at https://svn.boost.org/trac/boost/report/1 -- Marshall

1 0

2nd try, New library proposal: PolicyLoader
by Rob Meijer 18 Nov '09

18 Nov '09

I posted this to this list ones before (as the site sugests), and didn't get any response, possibly becource it is simply to useless for you guys to reply to, but I'm not sure. If it is indeed useless please let me know, so I know not to put any effort in it. The Open Computer Forensics Architecture Library (OcfaLib) hides a litle piece of template code for loading a class from a dynamically loaded library. Although this code is currently bound to OcfaLib and usage on *NIX systems, I wondered if the concept used would not be extendable to a generically usable library for this purpose. I've tried to strip the OCFA specific code to show the simple templating concept of this library. I would like to know if it is a good idea to work on this code in order to make it a powerfull cross-platform boost library that addresses this issue in an even more generic way. If it is useless, please also let me know. First lets show an example of usage: typedef SinglePointerConstructor<AbstractRepository,const char> CRepositoryType; PolicyLoader<CRepositoryType> pl(myLib,"createRepository"); CRepositoryType *constructor=pl.constructor(); _instance = (*constructor)(repRoot.c_str()); Here the 'AbstractRepository *' type _instance gets assigned a new object of a class that implements AbstractRepository to it, that is created with the "createRepository" function in the so file designated by myLib. Here is the stripped down template code: ---------------------------------- template <class T,class U> class SinglePointerConstructor { public: typedef T * (*fp)(U *); SinglePointerConstructor (fp func) : mFunction(func) {} T *operator() (U *val) { return (mFunction)(val); } private: fp mFunction; }; template <class T> class VoidToFunction { public: static T *cast(void *p) { #ifdef VOID_FP_CAST_WORKAROUND #ifdef POINTERS_64BIT return new T(reinterpret_cast<typename T::fp>(reinterpret_cast<long long>(p))); #else return new T(reinterpret_cast<typename T::fp>(reinterpret_cast<int>(p))); #endif #else return new T(reinterpret_cast<typename T::fp>(p)); #endif }; }; class PolicyLoader: { public: PolicyLoader(std::string myLib,std::string loadername):mLibHandle(0),mConstructor(0) { mLibHandle=dlopen(myLib.c_str(),RTLD_NOW|RTLD_GLOBAL); if (mLibHandle == 0) { throw std::runtime_error( std::string("Problem loading library '") + myLib + std::string("' (") + std::string(dlerror()) + std::string(")") ); } mConstructor = VoidToFunction<TConstructor>::cast(dlsym(mLibHandle,loadername.c_str())); if (mConstructor == 0) { std::string errString=std::string("Problem looking up symbol '") + loadername + std::string("' in library '") + myLib + std::string("' (") + std::string(dlerror()) + std::string(")"); dlclose(mLibHandle); throw std::runtime_error(errString); } } ~PolicyLoader() { delete mConstructor; } void closeLib() { if (mLibHandle) { dlclose(mLibHandle); } mLibHandle=0; } TConstructor *constructor() { return mConstructor; } private: void *mLibHandle; TConstructor *mConstructor; }; -----------------

3 3

[foreach] Request for auto type deduction
by Andrzej Krzemienski 18 Nov '09

18 Nov '09

Hi, Boost already provides a tool for emulating C++0x auto syntax: auto iter = map_of_strings.begin(); // C++0x BOOST_AUTO( iter, map_of_strings.begin() ); // boost It even works in more complex contexts like: if( BOOST_AUTO(ptr, get_pointer()) ) { ptr->run(); } or: BOOST_AUTO( const& val, vect.front() ); It already provides a tool for emulating C++0x range-based for syntax: for( int & x : vect ) { ...} // C++0x BOOST_FOREACH( int & x, vect ) { ... }; // boost However currently it is impossible to emulate the following C++0x syntax: for( auto & x : collection ) { ... } // C++0x Therefore, I would like to request a new tool in Boost.Foreach that would emulate the above construct, and would look something like: BOOST_FOREACH_AUTO( const& x, collection ) {...} I do not anticipate any technical difficulties with implementing this, as it can already be achiever with a verbose: BOOST_FOREACH( BOOST_TYPEOF( boost::begin(collection) ) const& x, collection ) {..} Regards, &rzej

3 2

[datetime] feature request
by Sean Farrow 17 Nov '09

17 Nov '09

Hi; I'm currently working with a company who have locked there systems down to such an extent that users can only write to/read from certain areas. I am using the date/time library. What i need to be able to do is to load the date_time_zonespec.csv file from an rc file under windows. I can write the rc loading stuff, but how do I then go about submitting this, and more importantly only compiling this .cpp file under windows within the build framework. Chances are the code will be apart of the timeZoneDatabase class. Any help appreciated. Sean.

1 0

[1.41.0] Release candidate 2
by Beman Dawes 17 Nov '09

17 Nov '09

1.41.0 release candidate 2 packages are available. The only change from RC1 is the fix for the serialization snafu. http://boost.cowic.de/rc/boost_1_41_0.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.tar.gz<http://boost.cowic.de/rc/boost_1_41_1_beta1.tar.gz>- Unix line endings http://boost.cowic.de/rc/boost_1_41_0.7z<http://boost.cowic.de/rc/boost_1_41_1_beta1.7z>- Windows line endings http://boost.cowic.de/rc/boost_1_41_0.zip<http://boost.cowic.de/rc/boost_1_41_1_beta1.zip>- Windows line endings Before pushing the release out to SourceForge, I'd appreciate it if several people would try the release candidate and report success, failure, or any problems encountered. Thanks, --Beman

3 7

[program_options] Feature request for untyped variables
by Dave Johnson 17 Nov '09

17 Nov '09

I usually store option values in a global structure so that I can access them by field name rather than by doing a map lookup with a string. This has the benefit that typos in option names are caught at compile time rather than run time. For example, I can use Options.input instead of vm["input"]. For untyped options, typically used as boolean flags (i.e. --help, --verbose), there is no way to specify where to store a value (or a count). This means I need to access them by map lookup or manually copy them to my global options structure. I'm not happy with either one. Ideally I'd like some way to specify that this option does not have a value, but I'd like to give the parser a pointer to where I want it to put a count of its instances in the command line or maybe a pointer to a bool instead. Example: // Global struct for command line options struct { bool help; bool verbose; string inputFile; ... } Options; // Parse command line options_description desc("Allowed options"); desc.add_options() ("help" , "produce help message") ("verbose" , "create more detailed output") ("input", po::value<string>(&Options.inputFile), "Name of the input file") ... ; variables_map vm; store(po::parse_command_line(argc, argv, desc), vm); notify(vm); // Hack! Need to manually assign bool options! // Options.input is automatically assigned Options.help = vm.count("help"); Options.verbose = vm.count("verbose");

2 2

[iterator] Interest check in specialized reproduction_iterator
by Christoph Heindl 17 Nov '09

17 Nov '09

Good afternoon, Would there be interest in adding a specialized iterator, called reproduction_iterator, that allows specifying a single element which is iterated n-times. Example: const std::vector<int> values = boost::assign::list_of(1)(2)(3)(5); const int c = 3; std::vector<int> result; std::transform( extboost::make_reproduction_iterator(c), extboost::make_reproduction_iterator(c, values.size()), values.begin(), std::back_inserter(result), std::multiplies<int>() ); // result contains 3, 6, 9, 15 The rationale for implementing the iterator is to provide a mechanism for the cheap iteration over a 'sequence' of equal objects. This is used (in my case) for adaption of functions that otherwise take two ranges and where I can bind one range to a single object. In the example above one can achieve the same effect by using a binder and std::transform that takes a single range. This is IMHO not always possible. 'reproduction_iterator' is implemented as random access iterator using boost::iterator_facade. Best regards, Christoph

1 0

[BGL] [variant] problem (and perhaps solution?) with strong_components.hpp and variant
by Nil Geisweiller 17 Nov '09

17 Nov '09

Hi, it seems the problem is indeed a conflict between the get function of variant.hpp and the get function of two_bit_color_map. After renaming get by getTEST in 1) two_bit_color_map.hpp line 61 2) breadth_first_search.hpp line 78 3) property_map.hpp line 164 the compiling error has disappeared. Of course it is certainly not the right way to fix that bug, maybe wrapping two_bit_color_map get (and alike) function name under some namespace... but I'm not confident enough to take such decision. Maybe there is a better way. Please if someone is more knowledgeable could help me fix that bug. Thanks for your help Nil On Tue, Oct 27, 2009 at 7:31 AM, Nil Geisweiller <ngeiswei(a)googlemail.com> wrote: > Hi, > > I resend that email with the right title header. > > ---------- Forwarded message ---------- > From: Nil Geisweiller <ngeiswei(a)googlemail.com> > Date: Sun, Oct 25, 2009 at 6:11 PM > Subject: [Graph] problem with strong_components.hpp and variant > To: boost(a)lists.boost.org > > > Hi, > > it seems there is a conflict between strong_components.hpp and > variant, maybe the method boost::get is wrongly overloaded. > > The problem occurs with 1.40 but not with 1.37, and it is still occurs > with the last svn. > > I attach a minimal code to reproduce the bug + compile error > > ###### > test.cpp > ###### > > //uncomment the line below to get the bug > #include <boost/graph/strong_components.hpp> > #include <boost/variant.hpp> > > typedef boost::variant < int, float > intorfloat; > > int main() { > int i(2); > intorfloat iof(i); > return boost::get<int>(iof); //problem is here > } > > ########### > compile error > ########### > > a-lin@a-lin-desktop:~/OpenCog/test/bin$ make > [100%] Building CXX object CMakeFiles/test.dir/test.cpp.o > In file included from /usr/include/boost/graph/graph_concepts.hpp:17, > from /usr/include/boost/graph/depth_first_search.hpp:18, > from /usr/include/boost/graph/strong_components.hpp:17, > from /home/a-lin/OpenCog/test/test.cpp:2: > /usr/include/boost/property_map/property_map.hpp: In instantiation of > ‘boost::property_traits<int>’: > /usr/include/boost/graph/two_bit_color_map.hpp:46: instantiated from > ‘boost::two_bit_color_map<int>’ > /home/a-lin/OpenCog/test/test.cpp:10: instantiated from here > /usr/include/boost/property_map/property_map.hpp:31: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:32: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:33: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:34: error: ‘int’ is > not a class, struct, or union type > make[2]: *** [CMakeFiles/test.dir/test.cpp.o] Error 1 > make[1]: *** [CMakeFiles/test.dir/all] Error 2 > make: *** [all] Error 2 > > Is it a bug? Thanks a lot! > Nil >

4 5

Fall bug sprint starts tomorrow! (Assuming that the release happens today)
by Marshall Clow 17 Nov '09

17 Nov '09

Here's the deal on the bug sprint: It will run until Sunday, November 29th. For those in the USA, that includes the long Thanksgiving weekend. The goal is to classify and fix bugs, and to close resolve Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the last bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 General information about the ticket process is at What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 (Note that there are 10 tickets that have no owner!) Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (Many old milestones here, including 62 tickets w/o a milestone) and, of course, the main report at https://svn.boost.org/trac/boost/report/1 which shows that we currently have 856 open tickets. As soon as the release is final, I will be posting the "release branch" vs. "trunk" comparison as well, so we can find things that need to be merged. -- Marshall

1 0

[GGL] performance
by Barend Gehrels 17 Nov '09

17 Nov '09

Hi list, As there were doubts expressed on this list regarding performance in more challenging environments, an additional test is provided. The resulting figures of GGL are still good, sometimes the best, sometimes the second best. For example, for a union on polygons with many diagonals, holes, and many points on both inputs: ggl 3.6 seconds b.p. 7.8 seconds terralib 8.2 seconds geos 35.9 seconds cgal 77.8 seconds (a cgal-intersection (instead of union) is the fastest in these tests) Polygons have large diagonals, holes are tested, and the number of vertices of both input polygons can be varied in the tests. More information: http://trac.osgeo.org/ggl/wiki/IntersectionStarComb, including references to sources for reproducing the figures, everyone is invited to do that. Regards, Barend

2 4

[serialization] warnings in debug build
by Christoph Duelli 17 Nov '09

17 Nov '09

building vs trunk I got (only in my debug build): boost/archive/basic_binary_oarchive.hpp:89: warning: comparison is always true due to limited range of data type boost/archive/basic_binary_oarchive.hpp:95: warning: comparison is always true due to limited range of data type boost/archive/basic_binary_oprimitive.hpp:163: warning: comparison between signed and unsigned integer expressions boost/archive/basic_binary_iprimitive.hpp:154: warning: comparison between signed and unsigned integer expressions Best regards Christoph

4 7

[Boost.Locale] For Preliminary Review of Boost Community (with Full documentation)
by Artyom 17 Nov '09

17 Nov '09

Hello All, I had written a Boost.Locale library that provides high quality localization facilities in C++ way. This library uses internally ICU library to provide all facilities: - Correct case conversion, case folding and normalization - Collation including support of 4 Unicode collation levels. - Date and time formatting and parsing - Number formatting, spelling and parsing - Monetary formatting and parsing - Powerful message formatting including support plural forms, using GNU catalogs. - Character, word, sentence and line-break boundary analysis. - Codepage conversion - Support of 8-bit character sets like Latin1 and UTF–8 encoded text. - Support of char, wchar_t and C++0x char16_t, char32_t strings and streams. I've tested it with: - Linux GCC 4.1, 4.3. with ICU 3.6 and 3.8 - Windows MSVC-9 (VC 2008), with ICU 4.2 - Windows MingW with ICU 4.2 - Windows Cygwin with ICU 3.8 Documentation: ============== Full tutorials: http://cppcms.sourceforge.net/boost_locale/docs/ Doxygen reference documentation: http://cppcms.sourceforge.net/boost_locale/docs/doxy/html/ Source Code: ============ https://cppcms.svn.sourceforge.net/svnroot/cppcms/boost_locale/trunk Building: ========= At this point I hand't written any JAM files yet and I use CMake. So checkout the code, and run cmake /path/to/boost_locale/libs/locale You need to have ICU 3.6 or above installed on your system. 4.2 and above recommended It is mandatory dependency. Notes for MSVC Users ==================== In many examples I write: wstring tmp=L"שלום עולם!"; // Unicode string In order to make these examples work correctly source code should include BOM to let MSVC know that the text is UTF-8 and not ASCII... So when you try to compile examples convert files in order to make them work correctly. Todo List ========= - Create a good set of unit tests - More boostification (Jam, etc) I'm waiting for your inputs Artyom Beilis

3 4

[Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
by Jose 17 Nov '09

17 Nov '09

Hi, I am trying to understand the goemetry libraries. I find the currently under review GGL very useful for non-cartesian geometries (and maybe cartesian too!) but I don't understand what was the rationale for accepting GTL, which is a library mainly used in chip design. The reviews for GTL clearly stated that the library was not appropiate for GIS-like applications as its focus is mainly 2D. So, can anybody explain how these two libraries fit together. I see in which cases GGL will be useful but I am rather confused with Boost.Polygon, as it's optimized for VLSI design (as stated in the BoostCon paper and by some of the reviewers) Did someone decide that it was not possible to have a single GENERIC GEOMETRY library and we should have two ? thanks

5 7

[move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)
by Ion Gaztañaga 17 Nov '09

17 Nov '09

Hi to all, I've just uploaded to boost sandbox... http://svn.boost.org/svn/boost/sandbox/move/) and Boost.Vault... http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… ...new versions of libraries Boost.Move and Boost.Container. Online documentation can be found here: Boost.Move http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html Boost.Container http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… I would like to request a review for both libraries. Boost.Move is quite small (just one header). Boost.Container depends on Boost.Move and Boost.Intrusive so you must download also the post-1.40 version of Intrusive placed in the same package (Boost.Container uses new features from Intrusive not included in Boost 1.40). Just take fresh Boost 1.39 folder and overwrite it with package contents. ************************ What's new in Boost.Move: ************************ ->The library has been modified to support moving rvalues of copyable AND movable types, a limitation of the previous version. This changes where proposed by Klaus Triendl in this thread: http://lists.boost.org/Archives/boost/2009/06/153266.php The library has now new macros to declare copyable and movable types and movable only types. Old macros are still there for backwards compatibility (specially unordered library which was also ported to this move sandbox) but I expect to remove them if current approach is considered better. ->Updated documentation and tests. ************************ What's new in Boost.Container: ************************ -> Added tests and documentation -> Updated the library to the new Boost.Move macros * * * I've tested both libraries in Windows XP using the following compilers: Visual 7.1, Visual 8.0, Visual 9.0, Intel 10.0, Mingw-gcc 4.3 and Mingw-gcc 4.3 in C++0x mode. The library should work on any C++03 conforming compiler Best, Ion

19 95

[random] Compilation errors in linear_congruential.hpp because of min()/max()
by Hartmut Kaiser 17 Nov '09

17 Nov '09

Hi, I'm getting compilations errors against Boost trunk from inside linear_congruential.hpp:+89 on VS2010 because of min()/max() being used without safeguarding them against accidental macro substitution: assert(_x >= min()); assert(_x <= max()); if I replace this with assert(_x >= (min)()); assert(_x <= (max)()); the compiler errors go away. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

2 2

[Function] Interest in boost::functions that take and return references to self-type?
by Tony Astolfi 16 Nov '09

16 Nov '09

Would there be interest in adding a feature to boost::function that allows a function to accept as input and return values of the same type as itself? I think this would be useful for implementing state machines. Something like: typedef boost::function< boost::function_self_type (event const&) > state_transition_fcn; state_transition_fcn initial_state (event const& e); state_transition_fcn second_state (event const& e); state_transition_fcn initial_state (event const& e) { if (/* some predicate on e*/) { // go to new state return &second_state; } else { // stay in old state return &initial_state; } } state_transition_fcn current_state = &initial_state; while (more_events) { current_state = current_state( next_event ); } -Tony Astolfi ps. Please point me in the right direction if such a thing already exists! Thanks!

2 1

[Review] We're halfway through the GGL review
by Hartmut Kaiser 16 Nov '09

16 Nov '09

Hey all, We're halfway through the GGL review (see attached review announcement) it is planned to end November 15th. Now would be a good time to send in your reviews! Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

4 6

[Locale] Boost.Locale - preliminary code
by Artyom 16 Nov '09

16 Nov '09

Hello, I'm working on Boost.Locale project. Source code and some basic examples can be found here: https://cppcms.svn.sourceforge.net/svnroot/cppcms/boost_locale/trunk/ It still lacks of documentation and some features. It is mostly tested under Linux gcc-4.3 and it seems to work under MSVC-9 (however I had less tested it). General description: ==================== Boost.Locale is a library that brings high quality localization facilities in C++ way. It uses `std::locale`, and `std::locale` facets in order to pro- vide localization in transparent and C++ aware way to user. C++ has quite good base for localization via existing C++ locale facets: `std::num_put`, `std::ctype`, `std::collate` etc.. But they are very limited and sometimes buggy by design. The support of localization varies between different operating systems and incompatible between them. On the other hand, there is great, well debugged, high quality, widely used ICU library that gives all of the goodies but, it has very old API that mimics Java behavior, it is completely ignores STL and provides useful API only for UTF-16 encoded text, ignoring other popular Unicode encodings like UTF-8 and UTF-16, or limited national character sets like Latin1. Boost.Locale provides the natural glue between C++ locales framework, iostreams and powerful ICU library in following areas: - Correct case conversion, case folding and normalization (DONE) - Collation including support of 4 Unicode collation levels. (DONE) - Date and time formatting and parsing including support of timezones and calendars other then Gregorian. (DONE) - Number formatting, spelling and parsing (DONE) - Monetary formatting and parsing (DONE) - Powerful message formatting including support plural forms, using GNU catalogs. (DONE) - Character, word, sentence and line-break boundary analysis. (TODO) - Support of 8-bit character sets like Latin1 and UTF-8 encoded text. (DONE) - Support of `char`, `wchar_t` and C++0x `char16_t`, `char32_t` strings and streams. (DONE) ------------------------------------------------------------ FYI, It is still work in progress but 90% of the job is done. Please take a look on it --- especially experts in Windows programming. I would glad if someone explains me the process of submission and what should be done for it. I know that it is not yet Boost ready but it goes fast in this direction. Best, Artyom.

4 5

[1.41.0] Beta 1 available
by Beman Dawes 16 Nov '09

16 Nov '09

Boost release 1.40.1 beta 1 is available from SourceForge: http://sourceforge.net/projects/boost/files/ This release contains one new libraries and numerous bug fixes for existing libraries. For details, see http://beta.boost.org/users/news/version_1_41_0for details. To install the beta on your system, see http://beta.boost.org/doc/libs/1_40_0/more/getting_started/index.html Please report any problems with the beta on the developers or users mailing list. Unless unexpected problems arise, the plan is to ship the final 1.40.0 release in a week to ten days. Thanks, --The Boost release team

15 32

[1.41][serialization] MSVC 9 crashes on compilation
by Andrey Semashev 16 Nov '09

16 Nov '09

Hi, I'm building the release branch on MSVC 9 + STLPort 5.1.5. The compiler crashes when compiling Boost.Serialization (more precisely, the xml_wgrammar.cpp file). The command line I use is as follows: bjam.exe -j 2 --toolset=msvc variant=release link=shared threading=multi runtime-link=shared optimization=speed inlining=full stdlib=stlport --without-mpi --without-wave --without-python --without-graph stage Does anyone else have these problems?

8 16

Strict or lax build configuration
by Vladimir Prus 16 Nov '09

16 Nov '09

I have a question how building Boost should behave when the user provides wrong configuration information. E.g., suppose you have this in user-config.jam: using python : 3.20 : /nowhere ; or alternatively, in 1.42 a user runs Boost.Build as follows: ./bjam -sZLIB_INCLUDES=/still-nowhere ... What should happen? - A hard error. After all, the user wanted that specific configuration. And warnings are easy to miss. - A warning. Autodetection will still run and possibly find a random version - A hard error, but also run autodetection and let user know what was found. For example: Could not find Python version 3.20 in /nowhere. There is a valid installation of 2.5 in /usr. Remove the 'using python' statement to use it. Comments? Thanks, Volodya

6 9

[interprocess] compilation errors when BOOST_USE_WINDOWS_H is defined
by Hartmut Kaiser 16 Nov '09

16 Nov '09

If all I have is #define BOOST_USE_WINDOWS_H #include <boost/interprocess/smart_ptr/shared_ptr.hpp> I'm getting a whole bunch of compilation errors related to undefined types like win32_find_data_t, interprocess_filetime, etc. Anything I could do about this (Windows7, VS2005, VS2008, VS2010, Boost SVN trunk)? Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

3 3

[exception][mpl] Boost.Exception uses unqualified size_t
by Hartmut Kaiser 16 Nov '09

16 Nov '09

The Boost.Exception library uses size_t without any qualification, which leads to unexpected ADL problems related to mpl::size_t. I'm currently not able to provide a minimal use case as I don't fully understand where this happens, but if I replace size_t with std::size_t in boost/exception/detail/object_hex_dump.hpp my problems go away. I tried to look around in other Boost libraries, but all other occurrences of size_t are qualified as std::size_t. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

7 14

[GGL] Some bits missing from Doxygen docs?
by Phil Endecott 15 Nov '09

15 Nov '09

Dear All, In the GGL docs at http://geometrylibrary.geodan.nl/formal%5Freview/ , if I go: Modules -> geometries -> ggl::linear_ring -> List of all members I see a page that says "This is the complete list of members for ggl::linear_ring< P, V, ClockWise, A >, including all inherited members.", and is then entirely empty. Is this what other people see? Maybe it is something odd with my browser. Thanks, Phil.

3 3

[1.41.0] Release candidates available
by Beman Dawes 15 Nov '09

15 Nov '09

1.41.0 release candidates are available: http://boost.cowic.de/rc/boost_1_41_1_beta1.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_1_beta1.tar.gz - Unix line endings http://boost.cowic.de/rc/boost_1_41_1_beta1.7z - Windows line endings http://boost.cowic.de/rc/boost_1_41_1_beta1.zip - Windows line endings Before pushing the release out to SourceForge, I'd appreciate it if several people would try the release candidate and report success, failure, or any problems encountered. Thanks, --Beman

4 4

[asio] multicore performance
by Isidor Zeuner 15 Nov '09

15 Nov '09

After coming along this ([1]) interesting link, I wonder what the suggested way of building a fully multicore-capable boost::asio tcp server on the linux platform would be. An obvious solution would be to listen on one interface/port per core and solve the problem at the application layer, but I'm looking for a fully transparent solution. I haven't looked more deeply into the boost::asio inner workings. Is it feasible to have modify epoll_reactor to distribute the file descriptors among multiple epoll threads? Best regards, Isidor Zeuner [1] http://stackoverflow.com/questions/1234750/c-socket-server-unable-to-satura…

2 1