November 2009 - Boost - lists.preview.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 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

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

[1.41.0] Release candidate 3
by Beman Dawes 18 Nov '09

18 Nov '09

The third, and hopefully final, release candidate is now available. The VC++ build problems are resolved, at least on my system. http://boost.cowic.de/rc/boost_1_41_0.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.tar.gz - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.7z - Windows line endings http://boost.cowic.de/rc/boost_1_41_0.zip - Windows line endings Please download and do a test build, reporting successes as well as failures. The release procedures have been updated so that in the future the release manager will do at least one build locally, to try to head off repeats of today's fiasco. --Beman

6 14

The Bug sprint has begun!
by Marshall Clow 18 Nov '09

18 Nov '09

The bug sprint will from today until Sunday, November 29th. For those in the USA, that includes the long Thanksgiving weekend. As of 8:00 AM PST today, there are currently have 859 open tickets. The goal is to classify and fix bugs, and to close resolve Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the last bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 (Note that there are 10 tickets that have no owner!) Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (Many old milestones here, including 62 tickets w/o a milestone) and, of course, the main report at https://svn.boost.org/trac/boost/report/1 -- Marshall

1 0

2nd try, New library proposal: PolicyLoader
by Rob Meijer 18 Nov '09

18 Nov '09

I posted this to this list ones before (as the site sugests), and didn't get any response, possibly becource it is simply to useless for you guys to reply to, but I'm not sure. If it is indeed useless please let me know, so I know not to put any effort in it. The Open Computer Forensics Architecture Library (OcfaLib) hides a litle piece of template code for loading a class from a dynamically loaded library. Although this code is currently bound to OcfaLib and usage on *NIX systems, I wondered if the concept used would not be extendable to a generically usable library for this purpose. I've tried to strip the OCFA specific code to show the simple templating concept of this library. I would like to know if it is a good idea to work on this code in order to make it a powerfull cross-platform boost library that addresses this issue in an even more generic way. If it is useless, please also let me know. First lets show an example of usage: typedef SinglePointerConstructor<AbstractRepository,const char> CRepositoryType; PolicyLoader<CRepositoryType> pl(myLib,"createRepository"); CRepositoryType *constructor=pl.constructor(); _instance = (*constructor)(repRoot.c_str()); Here the 'AbstractRepository *' type _instance gets assigned a new object of a class that implements AbstractRepository to it, that is created with the "createRepository" function in the so file designated by myLib. Here is the stripped down template code: ---------------------------------- template <class T,class U> class SinglePointerConstructor { public: typedef T * (*fp)(U *); SinglePointerConstructor (fp func) : mFunction(func) {} T *operator() (U *val) { return (mFunction)(val); } private: fp mFunction; }; template <class T> class VoidToFunction { public: static T *cast(void *p) { #ifdef VOID_FP_CAST_WORKAROUND #ifdef POINTERS_64BIT return new T(reinterpret_cast<typename T::fp>(reinterpret_cast<long long>(p))); #else return new T(reinterpret_cast<typename T::fp>(reinterpret_cast<int>(p))); #endif #else return new T(reinterpret_cast<typename T::fp>(p)); #endif }; }; class PolicyLoader: { public: PolicyLoader(std::string myLib,std::string loadername):mLibHandle(0),mConstructor(0) { mLibHandle=dlopen(myLib.c_str(),RTLD_NOW|RTLD_GLOBAL); if (mLibHandle == 0) { throw std::runtime_error( std::string("Problem loading library '") + myLib + std::string("' (") + std::string(dlerror()) + std::string(")") ); } mConstructor = VoidToFunction<TConstructor>::cast(dlsym(mLibHandle,loadername.c_str())); if (mConstructor == 0) { std::string errString=std::string("Problem looking up symbol '") + loadername + std::string("' in library '") + myLib + std::string("' (") + std::string(dlerror()) + std::string(")"); dlclose(mLibHandle); throw std::runtime_error(errString); } } ~PolicyLoader() { delete mConstructor; } void closeLib() { if (mLibHandle) { dlclose(mLibHandle); } mLibHandle=0; } TConstructor *constructor() { return mConstructor; } private: void *mLibHandle; TConstructor *mConstructor; }; -----------------

3 3

[foreach] Request for auto type deduction
by Andrzej Krzemienski 18 Nov '09

18 Nov '09

Hi, Boost already provides a tool for emulating C++0x auto syntax: auto iter = map_of_strings.begin(); // C++0x BOOST_AUTO( iter, map_of_strings.begin() ); // boost It even works in more complex contexts like: if( BOOST_AUTO(ptr, get_pointer()) ) { ptr->run(); } or: BOOST_AUTO( const& val, vect.front() ); It already provides a tool for emulating C++0x range-based for syntax: for( int & x : vect ) { ...} // C++0x BOOST_FOREACH( int & x, vect ) { ... }; // boost However currently it is impossible to emulate the following C++0x syntax: for( auto & x : collection ) { ... } // C++0x Therefore, I would like to request a new tool in Boost.Foreach that would emulate the above construct, and would look something like: BOOST_FOREACH_AUTO( const& x, collection ) {...} I do not anticipate any technical difficulties with implementing this, as it can already be achiever with a verbose: BOOST_FOREACH( BOOST_TYPEOF( boost::begin(collection) ) const& x, collection ) {..} Regards, &rzej

3 2

[datetime] feature request
by Sean Farrow 17 Nov '09

17 Nov '09

Hi; I'm currently working with a company who have locked there systems down to such an extent that users can only write to/read from certain areas. I am using the date/time library. What i need to be able to do is to load the date_time_zonespec.csv file from an rc file under windows. I can write the rc loading stuff, but how do I then go about submitting this, and more importantly only compiling this .cpp file under windows within the build framework. Chances are the code will be apart of the timeZoneDatabase class. Any help appreciated. Sean.

1 0

[1.41.0] Release candidate 2
by Beman Dawes 17 Nov '09

17 Nov '09

1.41.0 release candidate 2 packages are available. The only change from RC1 is the fix for the serialization snafu. http://boost.cowic.de/rc/boost_1_41_0.tar.bz2 - Unix line endings http://boost.cowic.de/rc/boost_1_41_0.tar.gz<http://boost.cowic.de/rc/boost_1_41_1_beta1.tar.gz>- Unix line endings http://boost.cowic.de/rc/boost_1_41_0.7z<http://boost.cowic.de/rc/boost_1_41_1_beta1.7z>- Windows line endings http://boost.cowic.de/rc/boost_1_41_0.zip<http://boost.cowic.de/rc/boost_1_41_1_beta1.zip>- Windows line endings Before pushing the release out to SourceForge, I'd appreciate it if several people would try the release candidate and report success, failure, or any problems encountered. Thanks, --Beman

3 7

[program_options] Feature request for untyped variables
by Dave Johnson 17 Nov '09

17 Nov '09

I usually store option values in a global structure so that I can access them by field name rather than by doing a map lookup with a string. This has the benefit that typos in option names are caught at compile time rather than run time. For example, I can use Options.input instead of vm["input"]. For untyped options, typically used as boolean flags (i.e. --help, --verbose), there is no way to specify where to store a value (or a count). This means I need to access them by map lookup or manually copy them to my global options structure. I'm not happy with either one. Ideally I'd like some way to specify that this option does not have a value, but I'd like to give the parser a pointer to where I want it to put a count of its instances in the command line or maybe a pointer to a bool instead. Example: // Global struct for command line options struct { bool help; bool verbose; string inputFile; ... } Options; // Parse command line options_description desc("Allowed options"); desc.add_options() ("help" , "produce help message") ("verbose" , "create more detailed output") ("input", po::value<string>(&Options.inputFile), "Name of the input file") ... ; variables_map vm; store(po::parse_command_line(argc, argv, desc), vm); notify(vm); // Hack! Need to manually assign bool options! // Options.input is automatically assigned Options.help = vm.count("help"); Options.verbose = vm.count("verbose");

2 2

[iterator] Interest check in specialized reproduction_iterator
by Christoph Heindl 17 Nov '09

17 Nov '09

Good afternoon, Would there be interest in adding a specialized iterator, called reproduction_iterator, that allows specifying a single element which is iterated n-times. Example: const std::vector<int> values = boost::assign::list_of(1)(2)(3)(5); const int c = 3; std::vector<int> result; std::transform( extboost::make_reproduction_iterator(c), extboost::make_reproduction_iterator(c, values.size()), values.begin(), std::back_inserter(result), std::multiplies<int>() ); // result contains 3, 6, 9, 15 The rationale for implementing the iterator is to provide a mechanism for the cheap iteration over a 'sequence' of equal objects. This is used (in my case) for adaption of functions that otherwise take two ranges and where I can bind one range to a single object. In the example above one can achieve the same effect by using a binder and std::transform that takes a single range. This is IMHO not always possible. 'reproduction_iterator' is implemented as random access iterator using boost::iterator_facade. Best regards, Christoph

1 0

[BGL] [variant] problem (and perhaps solution?) with strong_components.hpp and variant
by Nil Geisweiller 17 Nov '09

17 Nov '09

Hi, it seems the problem is indeed a conflict between the get function of variant.hpp and the get function of two_bit_color_map. After renaming get by getTEST in 1) two_bit_color_map.hpp line 61 2) breadth_first_search.hpp line 78 3) property_map.hpp line 164 the compiling error has disappeared. Of course it is certainly not the right way to fix that bug, maybe wrapping two_bit_color_map get (and alike) function name under some namespace... but I'm not confident enough to take such decision. Maybe there is a better way. Please if someone is more knowledgeable could help me fix that bug. Thanks for your help Nil On Tue, Oct 27, 2009 at 7:31 AM, Nil Geisweiller <ngeiswei(a)googlemail.com> wrote: > Hi, > > I resend that email with the right title header. > > ---------- Forwarded message ---------- > From: Nil Geisweiller <ngeiswei(a)googlemail.com> > Date: Sun, Oct 25, 2009 at 6:11 PM > Subject: [Graph] problem with strong_components.hpp and variant > To: boost(a)lists.boost.org > > > Hi, > > it seems there is a conflict between strong_components.hpp and > variant, maybe the method boost::get is wrongly overloaded. > > The problem occurs with 1.40 but not with 1.37, and it is still occurs > with the last svn. > > I attach a minimal code to reproduce the bug + compile error > > ###### > test.cpp > ###### > > //uncomment the line below to get the bug > #include <boost/graph/strong_components.hpp> > #include <boost/variant.hpp> > > typedef boost::variant < int, float > intorfloat; > > int main() { > int i(2); > intorfloat iof(i); > return boost::get<int>(iof); //problem is here > } > > ########### > compile error > ########### > > a-lin@a-lin-desktop:~/OpenCog/test/bin$ make > [100%] Building CXX object CMakeFiles/test.dir/test.cpp.o > In file included from /usr/include/boost/graph/graph_concepts.hpp:17, > from /usr/include/boost/graph/depth_first_search.hpp:18, > from /usr/include/boost/graph/strong_components.hpp:17, > from /home/a-lin/OpenCog/test/test.cpp:2: > /usr/include/boost/property_map/property_map.hpp: In instantiation of > ‘boost::property_traits<int>’: > /usr/include/boost/graph/two_bit_color_map.hpp:46: instantiated from > ‘boost::two_bit_color_map<int>’ > /home/a-lin/OpenCog/test/test.cpp:10: instantiated from here > /usr/include/boost/property_map/property_map.hpp:31: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:32: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:33: error: ‘int’ is > not a class, struct, or union type > /usr/include/boost/property_map/property_map.hpp:34: error: ‘int’ is > not a class, struct, or union type > make[2]: *** [CMakeFiles/test.dir/test.cpp.o] Error 1 > make[1]: *** [CMakeFiles/test.dir/all] Error 2 > make: *** [all] Error 2 > > Is it a bug? Thanks a lot! > Nil >

4 5

Fall bug sprint starts tomorrow! (Assuming that the release happens today)
by Marshall Clow 17 Nov '09

17 Nov '09

Here's the deal on the bug sprint: It will run until Sunday, November 29th. For those in the USA, that includes the long Thanksgiving weekend. The goal is to classify and fix bugs, and to close resolve Trac tickets. For those just joining in, the tickets live at https://svn.boost.org The instructions (mostly repeated here) for the last bug sprint are at https://svn.boost.org/trac/boost/wiki/BugSprintJune2009 General information about the ticket process is at What can you do? You can fix bugs • If you are a library maintainer, you can commit your fixes. • If you are not a library maintainer, you can fix a problem on your local machine (and test it!!), and then attach your fix as a patch to the Trac ticket for the library maintainer to commit. If you do this, please provide a test case that exercises the problem; i.e, one that fails w/o your patch, and succeeds afterwards. You can characterize bugs • You can attempt to replicate the bug on your system(s), and attach information that you discover to the Trac ticket. This will make it easier for other people to solve the problem, even if you cannot. • You can write test cases demonstrating the problem, and attach them to the Trac ticket. • You can determine if the bug still exists; sometimes they get fixed, and the ticket never gets closed. In this case, try to identify a checkin that addresses the bug; it's always suspicious when bugs go away "by accident." You can test patches • Some of the tickets in the Trac system contain patches - some are quite old. You can install these patches on your system, and determine if they (a) build, and (b) work. If you do this, please provide detail. Don't just say "works for me" - say "I installed this over revision XXX on system YYY with compiler ZZZ. The patch installed and compiled successfully, and passed all the tests." • You can write test cases for the patches, and attach them to the ticket. You can help implement new features • There are a whole set of "feature requests" in the Trac system. If you have an idea about one of these, you can add comments to the Trac system. You can attempt to implement these new features, and attach the patch to the ticket. (Don't forget the test cases!!). There are several Trac reports that I find helpful for looking at the bugs: Open ticket count by owner: https://svn.boost.org/trac/boost/report/18 (Note that there are 10 tickets that have no owner!) Open ticket count by component: https://svn.boost.org/trac/boost/report/19 Open ticket count by type https://svn.boost.org/trac/boost/report/20 (Overwhelmingly, these are 'bugs') Open ticket count by milestone: https://svn.boost.org/trac/boost/report/21 (Many old milestones here, including 62 tickets w/o a milestone) and, of course, the main report at https://svn.boost.org/trac/boost/report/1 which shows that we currently have 856 open tickets. As soon as the release is final, I will be posting the "release branch" vs. "trunk" comparison as well, so we can find things that need to be merged. -- Marshall

1 0

[GGL] performance
by Barend Gehrels 17 Nov '09

17 Nov '09

Hi list, As there were doubts expressed on this list regarding performance in more challenging environments, an additional test is provided. The resulting figures of GGL are still good, sometimes the best, sometimes the second best. For example, for a union on polygons with many diagonals, holes, and many points on both inputs: ggl 3.6 seconds b.p. 7.8 seconds terralib 8.2 seconds geos 35.9 seconds cgal 77.8 seconds (a cgal-intersection (instead of union) is the fastest in these tests) Polygons have large diagonals, holes are tested, and the number of vertices of both input polygons can be varied in the tests. More information: http://trac.osgeo.org/ggl/wiki/IntersectionStarComb, including references to sources for reproducing the figures, everyone is invited to do that. Regards, Barend

2 4

[serialization] warnings in debug build
by Christoph Duelli 17 Nov '09

17 Nov '09

building vs trunk I got (only in my debug build): boost/archive/basic_binary_oarchive.hpp:89: warning: comparison is always true due to limited range of data type boost/archive/basic_binary_oarchive.hpp:95: warning: comparison is always true due to limited range of data type boost/archive/basic_binary_oprimitive.hpp:163: warning: comparison between signed and unsigned integer expressions boost/archive/basic_binary_iprimitive.hpp:154: warning: comparison between signed and unsigned integer expressions Best regards Christoph

4 7

[Boost.Locale] For Preliminary Review of Boost Community (with Full documentation)
by Artyom 17 Nov '09

17 Nov '09

Hello All, I had written a Boost.Locale library that provides high quality localization facilities in C++ way. This library uses internally ICU library to provide all facilities: - Correct case conversion, case folding and normalization - Collation including support of 4 Unicode collation levels. - Date and time formatting and parsing - Number formatting, spelling and parsing - Monetary formatting and parsing - Powerful message formatting including support plural forms, using GNU catalogs. - Character, word, sentence and line-break boundary analysis. - Codepage conversion - Support of 8-bit character sets like Latin1 and UTF–8 encoded text. - Support of char, wchar_t and C++0x char16_t, char32_t strings and streams. I've tested it with: - Linux GCC 4.1, 4.3. with ICU 3.6 and 3.8 - Windows MSVC-9 (VC 2008), with ICU 4.2 - Windows MingW with ICU 4.2 - Windows Cygwin with ICU 3.8 Documentation: ============== Full tutorials: http://cppcms.sourceforge.net/boost_locale/docs/ Doxygen reference documentation: http://cppcms.sourceforge.net/boost_locale/docs/doxy/html/ Source Code: ============ https://cppcms.svn.sourceforge.net/svnroot/cppcms/boost_locale/trunk Building: ========= At this point I hand't written any JAM files yet and I use CMake. So checkout the code, and run cmake /path/to/boost_locale/libs/locale You need to have ICU 3.6 or above installed on your system. 4.2 and above recommended It is mandatory dependency. Notes for MSVC Users ==================== In many examples I write: wstring tmp=L"שלום עולם!"; // Unicode string In order to make these examples work correctly source code should include BOM to let MSVC know that the text is UTF-8 and not ASCII... So when you try to compile examples convert files in order to make them work correctly. Todo List ========= - Create a good set of unit tests - More boostification (Jam, etc) I'm waiting for your inputs Artyom Beilis

3 4

[Boost] [GGL] Bost.Polygon (GTL) vs GGL - rationale
by Jose 17 Nov '09

17 Nov '09

Hi, I am trying to understand the goemetry libraries. I find the currently under review GGL very useful for non-cartesian geometries (and maybe cartesian too!) but I don't understand what was the rationale for accepting GTL, which is a library mainly used in chip design. The reviews for GTL clearly stated that the library was not appropiate for GIS-like applications as its focus is mainly 2D. So, can anybody explain how these two libraries fit together. I see in which cases GGL will be useful but I am rather confused with Boost.Polygon, as it's optimized for VLSI design (as stated in the BoostCon paper and by some of the reviewers) Did someone decide that it was not possible to have a single GENERIC GEOMETRY library and we should have two ? thanks

5 7

[move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)
by Ion Gaztañaga 17 Nov '09

17 Nov '09

Hi to all, I've just uploaded to boost sandbox... http://svn.boost.org/svn/boost/sandbox/move/) and Boost.Vault... http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… ...new versions of libraries Boost.Move and Boost.Container. Online documentation can be found here: Boost.Move http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html Boost.Container http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… I would like to request a review for both libraries. Boost.Move is quite small (just one header). Boost.Container depends on Boost.Move and Boost.Intrusive so you must download also the post-1.40 version of Intrusive placed in the same package (Boost.Container uses new features from Intrusive not included in Boost 1.40). Just take fresh Boost 1.39 folder and overwrite it with package contents. ************************ What's new in Boost.Move: ************************ ->The library has been modified to support moving rvalues of copyable AND movable types, a limitation of the previous version. This changes where proposed by Klaus Triendl in this thread: http://lists.boost.org/Archives/boost/2009/06/153266.php The library has now new macros to declare copyable and movable types and movable only types. Old macros are still there for backwards compatibility (specially unordered library which was also ported to this move sandbox) but I expect to remove them if current approach is considered better. ->Updated documentation and tests. ************************ What's new in Boost.Container: ************************ -> Added tests and documentation -> Updated the library to the new Boost.Move macros * * * I've tested both libraries in Windows XP using the following compilers: Visual 7.1, Visual 8.0, Visual 9.0, Intel 10.0, Mingw-gcc 4.3 and Mingw-gcc 4.3 in C++0x mode. The library should work on any C++03 conforming compiler Best, Ion

19 95