- Boost - lists.boost.org

[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

[random] Compilation errors in linear_congruential.hpp because of min()/max()
by Hartmut Kaiser 17 Nov '09

17 Nov '09

Hi, I'm getting compilations errors against Boost trunk from inside linear_congruential.hpp:+89 on VS2010 because of min()/max() being used without safeguarding them against accidental macro substitution: assert(_x >= min()); assert(_x <= max()); if I replace this with assert(_x >= (min)()); assert(_x <= (max)()); the compiler errors go away. Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

2 2

[Function] Interest in boost::functions that take and return references to self-type?
by Tony Astolfi 16 Nov '09

16 Nov '09

Would there be interest in adding a feature to boost::function that allows a function to accept as input and return values of the same type as itself? I think this would be useful for implementing state machines. Something like: typedef boost::function< boost::function_self_type (event const&) > state_transition_fcn; state_transition_fcn initial_state (event const& e); state_transition_fcn second_state (event const& e); state_transition_fcn initial_state (event const& e) { if (/* some predicate on e*/) { // go to new state return &second_state; } else { // stay in old state return &initial_state; } } state_transition_fcn current_state = &initial_state; while (more_events) { current_state = current_state( next_event ); } -Tony Astolfi ps. Please point me in the right direction if such a thing already exists! Thanks!

2 1

[Review] We're halfway through the GGL review
by Hartmut Kaiser 16 Nov '09

16 Nov '09

Hey all, We're halfway through the GGL review (see attached review announcement) it is planned to end November 15th. Now would be a good time to send in your reviews! Regards Hartmut ------------------- Meet me at BoostCon http://boostcon.com

4 6