- Boost - lists.boost.org

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

On Iteration
by Andrei Alexandrescu 12 Nov '09

12 Nov '09

My article with a draft name "Iterators Must Go (Ahead)" is now published on InformIt and mentioned on reddit.com. Due to the vagaries of posting time and reddit dynamics, the article didn't stay long on reddit's programming page so it got very few views and comments. http://www.reddit.com/r/programming/comments/a2hv3/ Please comment here and/or there and vote up if you liked it. Many thanks to the many Boost participants who reviewed the article prior to publication (see the article's last section for a full list). Andrei

4 5

GGL Extensions
by Tom Brinkman 11 Nov '09

11 Nov '09

>> The GGL team proposes an extension model, very similar to what is used by GIL. I'm not sure that the extensions proposal worked very well for GIL. I'm not sure why. Probably it was too ambitious. Initially, just try encourage a small group of interested developers to work with you on extensions. When that number becomes too large, than start thinking about a more formalized system. If people see that there are a couple of really cool extensions that were intergrated, it might just encourage others to add extensions as well.

4 4

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

11 Nov '09

>Apologies if this is a silly question as I'm not familiar with earlier >versions of MSM, but how does this library different from Boost.Statechart? This is not a silly question but one which is begging for controversy ;-) I hope this is not starting a flame war, so from my understanding, there are advantages of using Msm on several points: - speed: Msm is much faster than statechart (see the performance page. Usually more than 20 times faster). - Design: * Msm makes heavier use of metaprogramming = longer compilation, higher speed * No RTTI and no virtual functions * Msm tries to follow the principles of declarativeness described in the book "C++ Template Metaprogramming". This leads to an interface, which is, in my opinion, easier to use. * Again in my opinion, entry/exit/guards are better with Msm. With Statechart, you have to write guard handling yourself and you don't get the event as parameter in the entry/exit. * Actions / guards are more reusable as you can provide a functor object * States are also more reusable as they don't know their containing state machine or other states (due to in-state transition-table definition in Statechart) - UML support. Msm supports forks, UML-conform event dispatching in orthogonal regions (which is that every region gets a chance to handle a given event), entry/exit pseudostates and anonymous transitions (transitions without an event). - Usage: Msm also supports different frontends. For example, eUML tries to hide metaprogramming as much as possible and tries to look like an UML diagram. This also help writing state machines easier with Msm. - Model-Driven approach. You will find in the doc directory my BoostCon paper (the only PDF) where I describe my analysis of MDD with both frameworks. But this is ultimately a matter of taste (as I will of course prefer Msm and Andreas will likely prefer Statechart), and you should take whatever fits your needs better and you are more comfortable with, so I'd advise you to look at both and see what you prefer (and even better, what I could do to improve Msm).

2 1

[1.41.0] Release plans
by Beman Dawes 11 Nov '09

11 Nov '09

The plan to do a Beta 2 has been canceled at the urging of Robert Ramey, Eric Niebler, Paul Bristow, and others. We will stick to more-or-less the same schedule, but do a final release rather than a Beta 2 release. Please complete all merges to branches/release by 9 PM, Friday, November 13th, US Eastern time (02:00, Nov. 14 UTC) That's a day earlier than expected, but will be a lot more convenient for me if we can hold to it. Thanks, --Beman

1 0

[integer] long long warning
by Vladimir Prus 11 Nov '09

11 Nov '09

Hi, if, in SVN trunk as of revision 57535, I go to libs/program_options/test and run: bjam warnings=all cxxflags=-Wextra I get a pile of warnings like this: ../../../boost/integer.hpp:145:24: warning: use of C99 long long integer constant These are actually only warnings that are now printed. Does anybody know what to do with them? Thanks, Volodya

6 11

[BGL] Trying to get a correclty working Parallel BFS code
by Sandeep Gupta 11 Nov '09

11 Nov '09

Hi All, I have spent significant effort on parallel bfs. Currently its almost working. I would really appreciate some help to get it running correctly. I have attached the code (self contained and requires no input file). I think I have followed all the guidelines regarding distributed property maps mentioned in the docs ( http://www.osl.iu.edu/research/pbgl/documentation/graph/breadth_first_searc… ). I am out of ideas of where things can could have gone wrong. The correct output of input graph 0 --> 1 2 1 --> 2 3 2 --> 3 3 --> 4 6 4 --> 5 5 --> 6 --> should be Node ID : Level 0 : 0 1 : 1 2 : 1 3 : 2 4 : 3 5 : 4 6 : 3 But when ran with 2 processes the output comes out to be Node ID : Level 0 : 0 1 : 1 2 : 1 3 : 2 4 : 3 5 : 4294967295 6 : 3 Not sure why this is happening. Any suggestions or pointers would indeed be quite appreciated. Thanks for your time. -Sandeep

3 23

[1.41, thread] small compile fix
by Tim Blechmann 11 Nov '09

11 Nov '09

hi all, trying the lastest release branch, i need the following fix to be able to compile the boost.thread sources ... would be great, if it could make it to the 1.41 release ... thnx, tim diff --git a/libs/thread/src/pthread/timeconv.inl b/libs/thread/src/pthread/timeconv.inl index 5ec3b17..50518c1 100644 --- a/libs/thread/src/pthread/timeconv.inl +++ b/libs/thread/src/pthread/timeconv.inl @@ -6,6 +6,8 @@ // boostinspect:nounnamed +#include <cassert> + namespace { const int MILLISECONDS_PER_SECOND = 1000; const int NANOSECONDS_PER_SECOND = 1000000000; -- tim(a)klingt.org http://tim.klingt.org Relying on the government to protect your privacy is like asking a peeping tom to install your window blinds. John Perry Barlow

1 0