April 2011 - Boost-users - lists.preview.boost.org

Polygon, accessing Points_Data
by AmandaLind 12 May '11

12 May '11

Greetings, This is my first post here. Please help me as I am stuck on how to access the points defining the new polygon generated with two other polygons and a boolean operation. I am having a hard time with using the iterators properly. The code runs well up to that point. Thanks in advance, ~Amanda namespace gtl = boost::polygon; using namespace boost::polygon::operators; using namespace gtl; //lets construct the two polygons typedef gtl::polygon_data Polygon; typedef gtl::polygon_traits::point_type Point; //Polygon1 Point pts1[numcorners1]; for (int index=0; index<numcorners1; index++) { pts1[index]=gtl::construct<Point>(rotated_corners1[index].x*1000, rotated_corners1[index].y*1000); } Polygon poly1; gtl::set_points(poly1, pts1, pts1+numcorners1); //Polygon 2 Point pts2[numcorners2]; for (int index=0; index<numcorners2; index++) { pts2[index]=gtl::construct<Point>(rotated_corners2[index].x*1000, rotated_corners2[index].y*1000); //mult by 1000 because it rounds to integers. } Polygon poly2; gtl::set_points(poly2, pts2, pts2+numcorners2); using namespace boost::polygon::operators; Polygon poly3; poly3 = poly1 & poly2; Point pts3[poly3.size()]; //how does one use iterators ?! std::vector<point_data<int> >::iterator itr ; itr= poly3.begin(); int index=0 for(itr; itr != ploy3.end(); ++itr) { pts3(index)=*itr; index++; } -- View this message in context: http://boost.2283326.n4.nabble.com/Polygon-accessing-Points-Data-tp3446015p… Sent from the Boost - Users mailing list archive at Nabble.com.

3 10

Boost Install on Mac OS X using GCC
by Andrew 07 May '11

07 May '11

Hello, I'm trying to install boost on mac using the gcc compiler. I encounter these errors during installation for all libraries: "g++" -Wl,-R -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.6/lib" -Wl,-R -Wl,"/System/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/config" -o "stage/lib/libboost_prg_exec_monitor.dylib" -Wl,-h -Wl,libboost_prg_exec_monitor.dylib -shared -Wl,--start-group "/Users/andrew/boost/boost/bin.v2/libs/test/build/gcc-4.2.1/release/threading-multi/execution_monitor.o" "/Users/andrew/boost/boost/bin.v2/libs/test/build/gcc-4.2.1/release/threading-multi/debug.o" "/Users/andrew/boost/boost/bin.v2/libs/test/build/gcc-4.2.1/release/threading-multi/cpp_main.o" -Wl,-Bstatic -Wl,-Bdynamic -Wl,--end-group ...failed gcc.link.dll stage/lib/libboost_prg_exec_monitor.dylib... gcc.link.dll stage/lib/libboost_unit_test_framework.dylib ld: unknown option: -R collect2: ld returned 1 exit status I have no experience at all using boost in mac, and it is necessary that I use gcc. I am wondering if anyone could point me to a solution regarding this. Thanks, Andrew

6 7

[boost] [xint] Formal Review Result
by Vladimir Prus 06 May '11

06 May '11

I apologize for the delay in producing the final summary and result of the Boost.Xint review, but here it is. Votes ===== YES: - Christian Henning - Steven Watanabe - Jarrad Waterloo - Edward Diener - Paul A. Bristow NO : - Mathias Gaunard - Joel Falcou - Anders Dalvander - Joachim Faulhaber - Phil Endecott - Domagoj Saric - Gordon Woodhull ("fraction of a vote") I might have missed somebody inside the 454 messages I have as result of the review, but the overall picture is clear -- the votes are split. High-level issues ================= - The claim that the library is "fast" is not necessary true. Phil has did some checking against hand-written assembler that don't look too good. - It is not clear whether the design allows for improving performance of fixed-size integers using specialization (again, see Phil's comments) - There were concerns about COW. In particular, it was very clearly stated that if COW is used, it should work fine in multi-threaded programs. - It was suggested to use ET. - Some folks suggested better separation between algorithms and data representation. Specific issues =============== - It was pointed out that "a + b + c" creates a pile of temporaries, and this can be improved without using ET. - Joachim's review raised a lot of valid points. Section 3 of his reviews in something that should be addressed, more or less entirely. Note that while we normally don't force specific coding style, some of formatting pointed out is simply unacceptable if this code is to be read by anybody. - 'Secure' flag is probably not so much of it. Future directions ================= I think that reviews by Phil and Joachim are most important in specying evolutionary directions for Boost.XInt. Chad made several comments about what he plans to do, in particular: - http://article.gmane.org/gmane.comp.lib.boost.devel/216935 Conclusion ========== I think there's no doubt that (i) this domain is important and (ii) Chad has put a lot of work into this library, producing several iterations. It was pointed out that we have many arbitrary-precision libraries skeletons all around Boost, and providing such a solid offering for review is a significant accomplishment. And it everybody learned a lot during the review. There was a couple of important meta-points raised during review -- whether review should focus on external interface only, and what is the scope of the library. Some reviewers argued that only external interface matters. However, it seems to me (as review manager), that concerns about internal design are valid, and may not be rejected offhand. After all, external interface of an integer library is more or less defined by mathematics, and internal design plays a key role in successfull evolution of the library. There was also heated discussion about the scope of the library, in particular support for fixed-width integers. I think that it's abstractly OK for this library to treat fixed-width integers as second-class citizens. However, I am having hard time determining the intended scope of the library. If I'm doing cryptography, would I really want to implement cryptography algorithms from the books with Boost.XInt, only to introduce bugs that are probably fixed in existing implementations (often, included in the OS). And if I'm really intent on doing that, I probably want raw performance, including a way to plug in optimized backends using SSE 2011, CUDA, and whatever fancy technology is there. If I'm doing general programming, then I'm most likely interested in not too big integers. They might be fixed-width 128-bit integers, or they might be something larger-than-64, but not necessary fixed. However, such integers are not the scope of the library, and they were found to have suboptimal performance. It is certainly possible to refine/define the scope, optimize everything for that scope, accomodate the proposals made during review, and obtain an excellent Boost library. However, there are some many suggestions, and so many planned redesigns and changes, that we need a second look at the library. Further, because of the global nature of the changes, it would be very hard to identify a specific subset that must be improved and then go through mini-review. For that reason, I've arrived at the the following result: Boost.Xint library is not accepted at this time. We'll be happy to have another full review of the library when the next version is ready. Thanks to Chad for the submission and for everybody who participated in the review! - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[Boost.Spirit] RFC: bin_float parser
by Vitaly Budovski 06 May '11

06 May '11

Hello, Please see the attached headers and test case for a bin_float parser. Please provide comments/suggestions/criticisms. Regards, Vitaly Budovski

3 3

[BGL] Extending Floyd Warshall (was: All-pairs SP algorithms -> Determine the path)
by Nicholas Mario Wardhana 04 May '11

04 May '11

On 16 April 2011 02:42, Jeremiah Willcock <jewillco(a)osl.iu.edu> wrote: > Hi Jeremiah, My apology for digging up an old post. I'd like to ask how Boost's Floyd Warshall can extended to provide further functionality. I cannot find any notion of visitor for Floyd Warshall, unlike Dijkstra and A*, and I am a bit confused about the types of the arguments that have to be passed to the function. > One thing you can do in BGL is to compute the paths using the distances; > look for edges where the source and target distances from a particular > starting node differ by the edge's weight, and that will be in the SSSP tree > for that starting node. You can also change the distances to <distance, > predecessor> pairs (just by changing the types being passed into the > algorithm); Will that be a variable of type std::vector<std::vector<std::pair<float, boost::vertex_descriptor>>> ? I tried this and the code failed to compile. > you would still compare just the distances, and the weight of an > edge would be a pair <actual_weight, source>. Will that be a std::pair<float, vertex_descriptor> variable? Additionally, is it also possible to know the number of nodes in a shortest path between two vertices in the graph by using Boost's Floyd-Warshall implementation? > > -- Jeremiah Willcock Thank you. Best regards, Nicholas

2 3

distributed breadth first search doesn't work properly?
by Mattia Lambertini 04 May '11

04 May '11

Hi, i am new to boost and i'm using the PBGL to write a software that compute some graph analysis. I've installed boost 1.44.0 and openmpi 1.5 I tried to run the breadth first search example located in $BOOST_ROOT/libs/graph_parallel/example with the graph $BOOST_ROOT/libs/graph/test/weighted_graph.gr All went well since i figure out that the result is different if i run the algorithm with a different number of processors. Only with one processor the values are corrected. here's what happens: mpirun -np 1 ./breadth_first_search.out graph g { subgraph cluster_0 { label="p0"; n0[label=0]; n1[label=2]; n2[label=1]; n3[label=2]; n4[label=1]; } n0 -- n2; n1 -- n1; n1 -- n3; n1 -- n4; n2 -- n1; n2 -- n3; n3 -- n4; n4 -- n0; n4 -- n1; } --------------------- mpirun -np 2 ./breadth_first_search.out graph g { subgraph cluster_0 { label="p0"; n0[label=0]; n1[label=1]; n2[label=1]; } n0 -- n2; n1 -- n1; n1 -- n3; n1 -- n4; n2 -- n1; n2 -- n3; subgraph cluster_1 { label="p1"; n3[label=1]; n4[label=0]; } n3 -- n4; n4 -- n0; n4 -- n1; } Is that correct? From the doc i can't figure out why.. -- Cordiali saluti, Mattia Lambertini

2 11

[PBGL] Results of distributed BFS on multiple processors vs. on a single processor
by Cedric Laczny 04 May '11

04 May '11

Hi, it recently came to my mind again that the distributed BFS in the PBGL seems to produce different results when applied to multiple processors as to when applied to a single processor (s. http://lists.boost.org/boost- users/2010/12/64783.php) If this is true, I really would like to know what the reasoning is behind this and it should be noted in the documentation of course to help prevent surprises as in the discussion above. Unfortunately, at that time, no definite answer was given and this question puzzled me again now... Any ideas on that? Best, Cedric

3 6

[wave] Custom I/O handling (include paths, etc.)?
by Anteru 03 May '11

03 May '11

Hi, I'm trying to adopt Wave as my custom preprocessor for a project. So far, things work fine, but there is one problem with Wave: I need to override all I/O functions, in particular, reading from files and opening files. Reading is easily changed by the input policy, but I couldn't find a way to register an include handler hook. There's found_include_directive, but nothing that allows me to get in-between wave and the filesystem. In my case, I on-demand construct some data which I want to be able to #include (i.e. #include <generated>) and some files are stored in resources/compressed files (#include <zip/file.h>). My include handler can open them, but how can I tell Wave to ask my include handler whether it can find a file instead of using boost::filesystem? Cheers, Anteru

2 4

Pass data to states, in boost state chart
by jusva2010 03 May '11

03 May '11

Hi All, Is there any way I can pass data to state event handler? Any pointers really appreciated. Thanks in advance Justin -- View this message in context: http://boost.2283326.n4.nabble.com/Pass-data-to-states-in-boost-state-chart… Sent from the Boost - Users mailing list archive at Nabble.com.

2 5

[Test] Compiling libraries for Windows Mobile 6 ARMV4I
by Paul Heil 02 May '11

02 May '11

I would like to be able to use the Boost.Test library for Windows Mobile 6 ARMV4I projects compiled by Visual Studio 2008. I can successfully compile the Boost.Signals, Boost.Thread, Boost.System, and Boost.Random libraries; but Boost.Test uses several functions that aren't available under Windows Mobile even with STLPort 5.2.1. Specifically, these are strerror() and getenv(). The actual compile errors I receive are: /test/impl/cpp_main.ipp(38) : error C2039: 'getenv' : is not a member of '`global namespace'' /test/impl/cpp_main.ipp(38) : error C2873: 'getenv' : symbol cannot be used in a using-declaration /test/impl/cpp_main.ipp(38) : error C2039: 'strerror' : is not a member of '`global namespace'' /test/impl/cpp_main.ipp(38) : error C2873: 'strerror' : symbol cannot be used in a using-declaration /test/impl/execution_monitor.ipp(1306) : error C2039: 'strerror' : is not a member of 'stlpd_std' /test/impl/execution_monitor.ipp(1306) : error C3861: 'strerror': identifier not found /test/impl/cpp_main.ipp(106) : error C2039: 'getenv' : is not a member of 'stlp_std' /test/impl/cpp_main.ipp(106) : error C3861: 'getenv': identifier not found I have seen past postings by other users that have suggested they have supplemented STLPort with these functions (particularly posts relating to VeetoFTC), but I have yet to see an actual example of the code changes necessary to do that. Can anybody suggest the least intrusive way to add this functionality so that I can compile the rest of Boost? Thanks, PaulH

2 2