headers
Bruno Lalande | 1 Mar 2009 01:18
Picon

Re: [geometry] area, length, centroid, behavior

Hi,

> GIS is my work area, so I know it's huge, but it seems like you are
> trying to tackle GIS + generic geometry library.  I don't get the
> impression that game programmers, for example, will enjoy or use this
> library.  Polygons are not closed (and rarely used, only triangles
> are) in games, and cannot have holes, and any error checking to
> determine otherwise is wasteful.  Winding is handled by the rendering
> API, and is also rarely, if ever, checked since the model exporter
> will have enforced the correct winding.

Me and Barend discussed a bit about this, as I'm personally more
concerned about game programing than GIS. So I guess that until now,
my participation to the library has been influenced by this point of
view.

What you say is true about what the library currently *provides*
(GIS-oriented algorithms, even if polygons with holes can be used in
games contrary to what you say, to display 2D vectorial fonts for
instance). But it's false about the *potential* of the library, and
this has always been my main concern since the beginning.

I focused my efforts until now on the kernel because I think that the
different application domains (GIS, games or whatever) won't
necessarily share the same algorithms but can share the same kernel.
If an algorithm is to slow because it can handles polygons with holes
while game programmers use plain triangles, the key of the problem is
to know if the library has been designed generically enough to sort
that out. If mechanisms like tag dispatching and/or concept refinement
are present and designed so well that I can add a triangle concept,
(Continue reading)

Permalink | Reply | 42 comments |
headers
Hartmut Kaiser | 1 Mar 2009 01:41
Picon
Gravatar

Re: Boost.Convert+Boost.Parameter

> > and for user types (uses operator<<() and operator>>()):
> >
> >    convert<spirit::tag::stream>::to()
> >    convert<spirit::tag::stream>::from()
> 
> Is it possible to have something like
> 
>     convert<int>::from()
>     convert<user_type>::from()
> 
> (we do not need 'to' with the interface).

Sure. I just wanted to highlight my point of the API's being compatible.

> > (spirit::stream is an instance of spirit::tag::stream). The idea
> would be
> > to
> > use Spirit directly if you need more powerful constructs like
> sequences
> > and
> > convert for conversion of single items.
> 
> For more powerful constructs my preference will probably be to "use
> Spirit
> directly" literally instead of through the (likely limiting) convert
> interface.

Agreed.
Regards Hartmut
(Continue reading)

Permalink | Reply | 0 comments |
headers
Andrew Sutton | 1 Mar 2009 03:36
Picon

Re: [graph] kolmogorov_max_flow color map, gray state

> I can rule out this possibility: every node except the source and sink
> node is connected to both the source and sink.  That is, there exist a
> directed path (source,node,sink) for all nodes.

Could those correspond to cycles? I know that with BFS/DFS (and
Dijkstra's?), gray vertices tend to indicate that they're still in a buffer,
which could indicate that the algorithm is re-pushing some vertices or
edges. I'm just guessing here.

> The difficulty is that the boost graph library does not seem to provide
> a way to easily obtain an edge cut set from the max flow solution.  This
> is not trivial, because the edge cut set might not be unique.  (That is,
> just taking all edges with zero residual capacity does not work.)

This isn't particularly surprising. The people that write the algorithms
tend to have a specific set of needs and they don't often generalize to
tasks that should be easy. Consider the task of tracing the edges from one
vertex to another along the shortest path. It should be easy, but its not,
nor is there a clear example that demonstrates how its done.

There's the potential to build a little library around each algorithm, but
things haven't quite worked out that way. If you're interested in
contributing a framework for this task, we'll certainly try to get it
integrated.

Andrew Sutton
andrew.n.sutton <at> gmail.com
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
(Continue reading)

Permalink | Reply | 1 comment |
headers
Vladimir Prus | 1 Mar 2009 06:58

Re: rule cpp-pch unknown in Jamfile</D:/boost/trunk/libs/math/build>?

Steven Watanabe wrote:

> AMDG
> 
> Peter Dimov wrote:
>> Steven Watanabe:
>>> AMDG
>>>
>>> Peter Dimov wrote:
>>>> Further investigation shows that it works (for me) with toolset=gcc
>>>> and an explicit toolset=msvc, but doesn't for toolset=borland and
>>>> when the toolset is omitted (this works in the release branch and
>>>> defaults to msvc).
>>>
>>> I'm going to guess that you initialize neither gcc nor msvc in
>>> user-config.jam.
>>> Is that correct?
>>
>> Correct. I don't have a user-config.jam.
> 
> Ok.  I see what's going on.
> the Jamfile actually ought to have an
>   import pch ;
> but this hasn't been detected before because it works
> as long as some other module does the import.

You're right. Since the change is obvious I gather John would not mind
me checking a fix, so I did so.

- Volodya
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sebastian Nowozin | 1 Mar 2009 09:51
Picon

Re: [graph] kolmogorov_max_flow color map, gray state


Hello Andrew,

Andrew Sutton wrote:

>> The difficulty is that the boost graph library does not seem to provide
>> a way to easily obtain an edge cut set from the max flow solution.  This
>> is not trivial, because the edge cut set might not be unique.  (That is,
>> just taking all edges with zero residual capacity does not work.)

> This isn't particularly surprising. The people that write the algorithms
> tend to have a specific set of needs and they don't often generalize to
> tasks that should be easy. Consider the task of tracing the edges from one
> vertex to another along the shortest path. It should be easy, but its not,
> nor is there a clear example that demonstrates how its done.

This makes sense.  However, I believe, obtaining a minimum edge cut set
for a linear s-t min-cut problem is one of the most basic graph-related
problems one could think of.  It shouldn't be hard.

Sebastian
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Claudio La Rosa | 1 Mar 2009 07:31
Picon
Favicon

Spirit, semantic actions and C++ classes


I am writing a class that implements a simple parser.

In the costructor I created the rule and the parser...and I recall the
functions for the semantic actions.
I have implemented this function as member funcions and, for recalled it, I
use a pointer to my member function in this manner:

#include <boost/spirit.hpp>
using namespace boost::spirit;

class MYParser
{
 private:
  //main rules
  rule<const char*> rLine, rComment;

  //This are the “semantic action”
  void AnnounceComment(char const*, char const*);

  // ...and this is the pointer to my “semantic action”
  void (SQLParser::*ptrAnnounceComment)(char const*, char const*);

 public:
   MYParser(void);
  //distuttore
  ͠ MYParser();
};

MYParser::MYParser()
(Continue reading)

Permalink | Reply | 0 comments |
headers
John Maddock | 1 Mar 2009 11:13
Picon

Re: rule cpp-pch unknown inJamfile</D:/boost/trunk/libs/math/build>?

> Ok.  I see what's going on.
> the Jamfile actually ought to have an
>  import pch ;
> but this hasn't been detected before because it works
> as long as some other module does the import.

Thanks for tracking that one down!

John.
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Joã‹o Abecasis | 1 Mar 2009 12:19
Picon
Gravatar

Re: [thread] static thread_specific_ptr?

Roland Schwarz wrote:
> Does this mean you have solved the initialization  problem for
> local statics? i.e. you made this thread-safe for every compiler?
> 
> (I remeber a very nasty bug in spirit because of the cited pattern.)

This was fixed in Spirit by solving the said problem. You can find the 
solution here:

     <boost/spirit/home/classic/core/non_terminal/impl/static.hpp>
     http://tinyurl.com/byve27

with usage illustrated here, around line 238 (look for 
get_definition_static_data_tag):

     <boost/spirit/home/classic/core/non_terminal/impl/grammar.ipp>
     http://tinyurl.com/cbnuca

Admittedly it can be cumbersome, but it works.

A performance hit has been reported for repeatedly callling call_once, 
that can be solved with double-checked locking. This is not implemented 
in the repository version.

Cheers,

João
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Phil Endecott | 1 Mar 2009 14:26

RangeEx review

My RangeEx review follows.  I'm afraid that I have not been following 
much of the ongoing discussion of this library on the list so apologies 
if I simply repeat what other people are saying.

Algorithms
----------

I have always found the verbosity of things like 
std::sort(container.begin(),container.end()) to be an embarrassing 
misfeature of the std library so it's good to be able to now write the 
much more sensible sort(container).  Just a couple of comments:

- It would be good if the docs were explicit about this being a thin 
wrapper around your existing std::sort, and identifying those 
algorithms that are not so thin.

- Do we really want this in the top-level boost:: namespace?  There 
have been discussions about sorting libraries for Boost who might also 
want boost::sort.  Would it not be better to put these algorithms in a 
boost::range namespace?

Then we move on to the algorithms where you can select what is returned 
using a template parameter.  This is an interesting idea, but it's a 
little verbose and I can't think of any precedent for it in the std 
library or elsewhere in Boost.  Being unfamiliar increases the learning 
curve for a feature.  I was wondering if it would be possible to have 
something more like:

   boost::unique(rng).found  instead of  boost::unique<boost::return_found>(rng)
(Continue reading)

Permalink | Reply | 3 comments |
headers
Beman Dawes | 1 Mar 2009 15:11
Picon
Favicon
Gravatar

[config] borland/codegear problems with C++0x macros

* trunk/boost/config/compiler/borland.hpp: It looks like John Maddock
and I independently added C++0x macros. The resulting inconsistencies
need to be reconciled. The BOOST_CODEGEAR_0X_SUPPORT macro doesn't
appear to be documented, by the way.

John, do you want to take a whack at this?

* trunk/boost/config/compiler/codegear.hpp: Doesn't have the negative
C++ macros yet. I'd like to borland.hpp finished before trying to do
codegear.hpp.

Thanks,

--Beman
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 2 comments |

Gmane