November 2009 - Boost - lists.boost.org

[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 19 Nov '09

19 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 19 Nov '09

19 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

Re: [boost] [Boost.Locale] For Preliminary Review of Boost Community (with Full documentation)
by Fabio Fracassi 18 Nov '09

18 Nov '09

Hi, just wanted to send a short note of appreciation for your library (http://cppcms.sourceforge.net/boost_locale/docs/) From glancing at the documentation there will finally be a good localization lib in boost. (Where I think it is sorely needed, since localization should be a standard feature IMHO) I have used QT's localization features before, and really liked them. This was something I really missed since I am working with std strings, but it seems that your locale lib is au-par with what Qt has to offer. Maybe one could even make it compatible with QT .ts/.qm files one day, so that one could use the fine QtLinguist Tools. (I have never used the gettext tools) Regards, and keep up the good work Fabio Fracassi P.S. Sorry that I messed up threading, but I didn't find the original message.

2 2

Bug sprint suggestions
by Marshall Clow 18 Nov '09

18 Nov '09

If you would like to participate in the bug sprint but don't know where to begin, here are some suggestions. Here are a list of open issues that aren't connected to any milestone: <https://svn.boost.org/trac/boost/query?status=assigned&status=new&status=re…> Some of these are feature requests, and don't really have a milestone where they will be provided, but sometimes the bugs tend to get missed. -- Marshall

1 0