- Boost - lists.boost.org

[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