- Boost - lists.preview.boost.org

[Review] GGL review extended until November 22nd
by Hartmut Kaiser 15 Nov '09

15 Nov '09

Hi all, The discussions around GGL are just start ramping up and we received only 2 (voting) reviews so far. Additionally, several people have been asking me off-list to extend the review period as they otherwise wouldn't be able to write a review in time. For these reasons the review period for the GGL library will be extended for another week. The review period will now end November 22nd. For everybody considering to vote: this would be a good time to write a review! Regards Hartmut GGL Review Manager ------------------- Meet me at BoostCon http://boostcon.com

1 0

[GGL] Initial thoughts; how to register point types
by Phil Endecott 15 Nov '09

15 Nov '09

Dear All, Following is some initial feedback on GGL, after spending an hour or so with the docs. I hope to be able to complete a proper review over the next couple of days. The documentation seems very much focused on "how it works", which is of course useful for reviewing the design, but more "what it does" and "how to use it" content would help me to actually try it with some examples. For example, I have a Point<T> class and I would like to "teach" the library about it. From the "Design rationale" page I can see that a number of traits have to be defined, but I don't see a concise reference to what I need to do. Looking at the example "c01_custom_point_example.cpp" I see that there are some macros e.g. GEOMETRY_REGISTER_POINT_2D (not a Boost-style macro name by the way) but I don't see any documentation for what these do. I guess that it defines some traits specialisations, right? Does anyone know how to get Doxygen to create next/prev buttons for navigating between the pages in the e.g. "related pages" section? Is it possible to note which versions of the Boost library dependencies are needed? I'm not convinced that overloading e.g. distance() so that it works with all combinations of geometries is a good idea. If I wanted to know the distance from a point to a polygon I'd be happy to write distance_pt_to_poly(a,b). Having the overload makes it possible for me to accidentally pass the wrong things and get no error. And there is the question of what is meant by distance "to" a polygon - is it to the nearest point, or the centroid, etc? I believe that heterogeneous co-ordinate types (e.g. latitude and longitude of one type and altitude of another) are not supported, right? Regards, Phil.

3 5

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

> Thank you for the snappy reaction. Works lovely. Good news! > I hope you submit it for a formal review soon. Chances are that you > will wait for a review manager for a better part of the decade anyway. I have a review manager (David Abrahams) so we just need to negociate a date with the review wizards. It should definitely last not that long ;-)

1 0

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

> MSM 1.20 allowed writing a state machine with actions/guards which > modify some external state. <snip/> > I no longer instantiate the state machine directly and cannot pass > parameters to constructor and it seems that msm::back::state_machine > will not do this for me (after a quick glance at the definition it > seemed to me that msm::back::state_machine expects its template > parameter to be default constructible). > Is this wrong or am I missing something obvious? Is there some way I > could still achieve the old functionality? No you're not doing anything wrong, it's a use case I simply oversaw, so it's not your fault but mine ;-) So, I corrected the problem and : - added a templated constructor, with up to 5 arguments (can be changed with the BOOST_MSM_CONSTRUCTOR_ARG_SIZE define) - actualized the doc - thanked you for this in the acknowledgments You can download the change (in back/state machine.hpp) from the sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) I tested your case and a few more so it should be ok now. Thanks a lot for the report. I'm happy you like the library. Regards, Christophe

2 1

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

>No, in this particular scenario I'd leave all the existing transitions in >place and just add the CDLoaded outer state. This is barely more work than >adding the flag, right? Ultimately, what I'm getting at is that your >justifying example in MsmSession_Handout.pdf could be better, because most >Statechart users wouldn't write the code you're implying they would. MSM vs. >Statechart aside, MSM users might be left with the question what flags are >good for when they can achieve the same with an additional outer state. >Again, flags are good, but the justifying example isn't. Ah now I think I now see what you mean. You're using direct entries and need therefore no change to the transitions. Point taken. I can change the example by adding another flag and giving it to one of the CDLoaded-states and one of the non-CDLoaded states, thus preventing the use of an outer state, eventhough it might make the example slightly more difficult than I intended. I really simply wanted to bring this new general concept. Regards, Christophe

2 1

Detached threads and Futures
by ak1mbox-boost＠yahoo.ca 14 Nov '09

14 Nov '09

Hi, I wanted to judge people interest in the following feature and to see [hope :)] that maybe it is already scheduled to appear in the next thread library. I find it often useful to run blocking operations in a fully detached thread. These are often atomic IO operations which receive some input by copy and then if they succeed return some output or error if they fail. The functionality that I need can be described as follow: 1. Encapsulate some code, providing ability to send it any number of parameters 2. Receive notification when this code has finished doing whatever it was supposed to be doing and get the resulting output or error. 3. Be able to terminate all other threads without the fear of the detached thread causing a memory corruption. 4. [Optional] Indicate to the detached thread that it should try to interrupt its operation and exit but not really care if it can't at this point. With Anthony Williams Futures addition to the thread library implementing something like this should not be too difficult. Is this already in the works or would people be interested in someone taking this on as a standalone library and an addition to thread library? Thanks, Alex

2 1

[mirror] C++0x version of the reflection library available
by Matus Chochlik 14 Nov '09

14 Nov '09

Dear list, I would like to announce that a new (alpha) version of the Mirror reflection library, re-written nearly completely from scratch in C++0x, is available at sourceforge.net for those interested, the code can be checked out from the SF repository: https://mirror-lib.svn.sourceforge.net/svnroot/mirror-lib/trunk/impl documentation pre-built with doxygen and DOT is available here: http://kifri.fri.uniza.sk/~chochlik/mirror-lib/html/ Based on a year and a half of user experience with the previous version (the one in Boost sandbox) there have been made several important changes. Just to mention a few: - The meta-objects should be more consistent with the base-level language - There is a run-time layer with an run-time interface very similar to the compile-time interface - Meta-object categories for tag dispatching have been added - "Local" names having parts of the nested name specifier stripped away if the Mirror's "using namespace" directive is used on the current (or parent) scope - C++0x features are extensively used to make things more straightforward - etc. This version does not yet implement all features from the previous version, like inherited class members, visitor-based traversals, meta-constructors and factory generators. These will be added in the near future. The library has been tested only with gcc (version 4.5.0 20091010) so I would be glad to hear about experiences with other compilers supporting C++0x. I would also appreciate any feedback, suggestions or other contributions. best regards, Matus

2 3

[iostreams] 64bit compile issue
by Christoph 14 Nov '09

14 Nov '09

in boost/iostreams/detail/streambuf/indirect_streambuf.hpp:171: error: no matching function for call to 'max(int, std::streamsize&)' suggest fix: cast 2 to std::streamsize Best regards Christoph

2 1

Halycon Days?
by Paul A. Bristow 14 Nov '09

14 Nov '09

http://tinyurl.com/yau3k57 see also youtube.com As Nom says - it is dead easy now there is a cable ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 1

[Serialization] warnings and maybe a 'bug'
by Christoph Duelli 14 Nov '09

14 Nov '09

(I tried to file a ticket, but got cookie trouble. Therefore I post here. Sorry for the inconvenience.) i) warnings (unused parameter) (These warnings are with gcc, 4.2.1) boost/serialization/shared_ptr.hpp:116: warning: unused parameter 'file_version' boost/archive/shared_ptr_helper.hpp:110: warning: unused parameter 't' /boost/archive/detail/iserializer.hpp:474: warning: unused parameter 'ar' (and 't', same line) I also get lots of boost::archive::detail::<unnamed>::init_guid<XXXX>::g' defined but not used where XXXX is some class name of mine ii) maybe a 'bug' (code does no longer compile) Code that used to compile with Boost 1.40 does no longer compile with the 1.41 beta: (I had no time to investigate yet; in case it is obvious for you once you see the code I have decided to include this point in this posting): boost/archive/shared_ptr_helper.hpp:114: error: cannot convert 'const boost::serialization::extended_type_info_typeid<MEPfad>' to 'const boost::serialization::extended_type_info*' in return (where MEPfad is a class of mine) Best regards Christoph

3 5

Beta build of PDF docs available for 1.41
by John Maddock 14 Nov '09

14 Nov '09

A beta build of the PDF documentation build for Boost-1.41 is available from the usual sourceforge page: https://sourceforge.net/project/admin/explorer.php?group_id=7586 in the Boost-docs/1.41.0 directory. Or directly from https://sourceforge.net/projects/boost/files/boost-docs/1.41.0/boost_pdf_1_…. If Boost authors would like to skim these for the usual SNAFU's that would be great. Otherwise I intend to release the final PDF build at the same time as Boost-1.41.0. Enjoy, John.

4 6

[msm] Version 2.0 available
by Christophe Henry 14 Nov '09

14 Nov '09

Dear Boosters, I'm happy to announce the review-ready new version of Msm (2.0). Msm is a framework which enables you to build a Finite State Machine in a straightforward, descriptive and easy-to-use manner. The generated code is optimized for speed and will force you to use neither RTTI nor anything virtual. Msm supports most of UML state machine 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 much more. Msm v2.0 is a redesign of Msm v1.20 and offers a separation beetween front- and back-ends. There is currently one backend and several frontends: - the same frontend as Msm v1.20 - a variation of this frontend based on functors for actions - eUML, a boost::proto-based compile-time language allowing you to use UML notations directly inside your code, thus making writing code from a state machine diagram easier. eUML also comes in with a functional programming library similar to Boost.Phoenix, adapted to state machines. I'll be happy for any comment. You can find Msm v2.0 in: - the vault (http://www.boostpro.com/vault/index.php?directory=Msm) - the boost sandbox (http://svn.boost.org/svn/boost/sandbox/msm/) The documentation can be found at libs/msm/doc/index.htm and the code in the boost/msm subdirectory. The 1.0 and 1.10 are now retired. To close up the 1.x path, I'll bring a 1.21 with the latest bugfixes and then retire the 1.20 from the vault. Best regards, Christophe

4 3

Boost bug sprint delayed until Wednesday, November 18th
by Marshall Clow 13 Nov '09

13 Nov '09

To allow time for the 1.41 release to complete, the start of the Boost Bug sprint has been delayed until next Wednesday, November 18th. That doesn't mean you can't work on bugs before that, though - just don't check fixes into svn until then. Find bugs, reproduce them, generate patches - all of those are fine! We started the last bug sprint with just over 800 open tickets. We finished with about 720 open tickets. Now (several months later) there are 854 open tickets. Useful reports: Active tickets https://svn.boost.org/trac/boost/report/1 Ticket counts by milestone https://svn.boost.org/trac/boost/report/21 Ticket counts by component https://svn.boost.org/trac/boost/report/19 Ticket counts by type https://svn.boost.org/trac/boost/report/20 Ticket counts by owner https://svn.boost.org/trac/boost/report/18 With 1.41 about to go out the door, we've still got a _bunch_ of tickets that were "to be resolved" by earlier milestones: Boost 1.36.0 101 Boost 1.37.0 45 Boost 1.38.0 64 Boost 1.39.0 89 Boost 1.40.0 139 That's more than half the active tickets! I'm sure that some of these have been fixed, or no longer apply. But which ones? -- Marshall P.S. If you're going to be participating in the sprint, please drop me a note.

1 0

boost.python problem in release branch (GSoc work)
by Ralf W. Grosse-Kunstleve 13 Nov '09

13 Nov '09

I just found out that two boost.python tests (svn trunk and release) are not valgrind clean. I fear this could be a serious problem, although I've not seen actual failures apart from the valgrind diagnostics. What I know at the moment is: libs/python/test/properties.py libs/python/test/data_members.py produce valgrind errors with trunk revision 56305 but not 56304 (fedora 8 64-bit). The critical revision 56305 is: Merged 2009 GSoC work from sandbox-branches/bhy/py3k branch back into trunk. It is merged into the release branch already. Unfortunately, without revision 56305 boost.python does not work with Python 2.6.3 and 2.6.4, i.e. backing out rev. 56305 and some followup revisions would only replace one problem with another. How far along is the 1.41 release? Is there a chance it could be delayed for a few days? Ralf P.S.: I'll add this issue to the tracker when I get a chance (hopefully tomorrow).

4 7

A fresh approach to iteration (Andrei Alexandrescu)
by Neal Becker 13 Nov '09

13 Nov '09

http://www.informit.com/articles/article.aspx?p=1407357&seqNum=7

1 0

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 13 Nov '09

13 Nov '09

>But you'd have to refactor an equivalent MSM Machine too (you'd need to introduce the flag), right? True, but adding one line to a few states is a lot less work than adding a composite, giving it a transition table and changing the transition table of the state machine.

2 1

Official warnings policy?
by John Maddock 13 Nov '09

13 Nov '09

I'm *not* saying we should do this for 1.41, but should we have an official policy regarding compiler warnings and which ones we regard as "failures"? I realize these can get pretty busy-body at times, but if the user sees several pages of warnings when building Boost it doesn't look so good. So my suggestion would be that we have two test-runners (if we have any spare!) that build with warnings-as-errors, maybe: -Wall -pedantic -Wstrict-aliasing -fstrict-aliasing -Werror For gcc and: /W3 /WX for MSVC? Obviously these may prove to be far too busy-body, but is this worth a try? Cheers, John.

31 202

Re: [boost] GGL Questions
by Bruno Lalande 12 Nov '09

12 Nov '09

Hi Peter, Thanks for your interest in GGL, and for trying to integrate it into your project. Lines and rays don't exist yet in GGL indeed. Adding them would basically consist in defining the corresponding concepts (like for polygon, segment, etc...) and then specialize the distance and intersection (to start with) algorithms for them, which is completely feasible. I'm personnally more video games oriented so I have already thought about the need of such things actually. As for directions, it's not there just because we didn't need it until now (there only exist a notion of orientation for points ranges traversal). I guess it would only be a traits to define and to use in algorithms that needed it. So to summarize, all those things are not yet there, but can easily be added. HTH Bruno

1 1

[iostreams] Is anyone maintaining Boost.IOStreams?
by Richard Smith 12 Nov '09

12 Nov '09

I've just looked through the list of bugs for the iostreams library: https://svn.boost.org/trac/boost/report/14?USER=anonymous&page=4 >From a quick scan, it looks like this library is not being maintained any more. Is this true? Just scratching to scratch the surface, the following dozen bugs seem to be to all be trivial to fix. Many have patches, and the others have a sufficiently clear description that fixing them should only be a couple of minutes' work. 2094 -- has a patch that ought to be uncontroversial 2154 -- relates to code that seems not to exist any longer 2817 -- proposed resolution seems straightforward 2894 -- seems pretty straightforward 2932 -- would be trivial to fix, assuming a fix is desired 3010 -- appears to have been fixed 3011 -- has a patch that ought to be uncontroversial 3197 -- trivial suggestion to remove a compiler warning 3311 -- obviously an error and trivial to fix 3352 -- looks like a genuine subtle bug; includes a patch 3403 -- minor documentation niggle, complete with patch 3505 -- looks a genuine bug and includes patches Some of the other bugs look pretty serious to me, and I might be inclined to spend some time investigating them if I thought there was any realistic chance of the resulting patches being accepted. -- Richard Smith

5 12

[Iostreams] Release notes
by Daniel James 12 Nov '09

12 Nov '09

Hi, I've added some release notes for Iostreams, but I don't really know much about the library so it'd be really helpful if someone who does could take a look at them. http://beta.boost.org/users/news/version_1_41_0 Daniel

3 2

Re: [boost] [msm] Version 2.0 available
by Christophe Henry 12 Nov '09

12 Nov '09

Hi Andreas, >:-) You won't get any flames from me. Yes, I don't agree with some of the >points in MsmSession_Handout.pdf (e.g. 2.4, a user in his right mind would >put Stopped, Open, Paused and Playing into an outer CDLoaded state and then >only say if (state_downcast<const CDLoaded *> != 0)). True, it is a possible solution. But 1) you don't always want to refactor your state machine and 2) sometimes you can't. For example, to take the example in the Statechart documentation(http://www.boost.org/doc/libs/1_40_0/libs/statechart/doc/tuto…, if ( ( state_downcast< const NumLockOff * >() != 0 ) && ( state_downcast< const CapsLockOff * >() != 0 ) && ( state_downcast< const ScrollLockOff * >() != 0 ) ) could have been replaced by if(fsm.is_flag_active<IsOffState,Active::Flag_AND>()). And in this case I don't see a working refactoring solution. In my experience, the flag system has proven invaluable (to define, for example, several success states in a test case defined as a state machine). > However, although I haven't yet reviewed anything in-depth so far, I'm definitely impressed by the progress the library has made. I hope I'll find the time to contribute > an in-depth review. This would be great and your experience could prove invaluable. I'd be very thankful for it. > Out of curiosity, have you made any tests how many states compilers can manage without running out of memory? IIRC, a Boost.Statechart FSM with 128 states > and several hundred transitions was the most I was able to fit into one TU. Good point indeed. There are 2 limitations. First, Msm is based on boost::mpl::vector for the transition table and on boost::fusion::set to contain the states. Both have a default limit of 20, which can be extended to 50. This is the theoretical limit. Of course, you can add some vectorxxx.hpp headers (which I did). I tried up to 80 transitions and 80 states in one machine. The second limitation is the compiler. The test compiles on VC and g++, eventhough you might need lots of RAM (1.4GB with VC9, 400MB with g++) and 40-60s. The execution speed stays the same, thus proving the O(1) double-dispatch. I suppose that, while it must be possible to push this further, Boost.Statechart will likely break the compiler later than Msm. Regards, Christophe Henry

2 1

CGL Questions
by Peter Schregle 12 Nov '09

12 Nov '09

Oops, I meant "GGL Questions" of course.

1 0

CGL Questions
by Peter Schregle 12 Nov '09

12 Nov '09

We are thinking about replacing our geometric algorithms with the ones from GGL. We would want to somehow adapt our own geometric primitives so that GGL can work with them, and with points, line segments and polygons this works rather nicely. However, we also have a few other concepts, where we have not found a simple way to adapt them to GGL. 1) Line We consider a line being an infinite line in the mathematical sense, i.e. it does not have endpoints but extends into infinity on both sides. We want to be able to calculate the distance between such a line and a point, or the point of intersection ot two lines if it exists. 2) Ray We consider a ray being a line with one endpoint or origin, and extending into infinity. Here also we want to be able to calculate the distance between a ray and a point, or between two rays, or points of intersections etc. 3) Direction In order to implement a line and a ray as descibed above, we have introduced the concept of direction (which is basically the same as a direction unit vector, or an equivalent angle). Is there a concept like this in GGL? How could we calculate the angle of a line segment in GGL? Best regards Peter PS: By the way: I find the acronym GGL unfortunate. For me it feels a bit awkward, and I was typing it wrong all the time while preparing this text. Everytime I use it I'm forced to think hard about what it means, in order to get it right. I would prefer a more descriptive name like geometry or geolib, or something else that can be memorized better.

1 0

getting started
by anirvana mishra 12 Nov '09

12 Nov '09

hello everybody, I have been using c++ for quite a long time but never thought of doing some development work for it.But now i think is the high time to contribute to this community and am looking forward for some good development work. can anyone tell as how to get started? Thanks -- All the best.

2 1

Boost.Variant is not EqualityComparable
by brook＠biology.nmsu.edu 12 Nov '09

12 Nov '09

I just ran into the case that Boost Variant does not satisfy the EqualityComparable concept. While it provides operator==() and operator<() (and therefore is LessThanComparable), it does not provide operator!=(), which is required for the EqualityComparable concept. Is this by design or oversight? It seems reasonable to expect that a Boost Variant model this concept, but perhaps I am missing something. In case it is by oversight, the following patch seems to provide the missing operator. Cheers, Brook --- boost/variant/variant.hpp.orig 2009-05-13 21:21:59.000000000 -0600 +++ boost/variant/variant.hpp 2009-05-25 19:21:40.000000000 -0600 @@ -1681,6 +1681,8 @@ return rhs.apply_visitor(visitor); } + bool operator!=(const variant& rhs) const { return !(*this == rhs); } + bool operator<(const variant& rhs) const { //

6 7