December 2010 - Boost - lists.boost.org

[signals] failure to build with recent gcc
by Patrick Horgan 18 Jan '11

18 Jan '11

I get a number of the same failures when doing a clean build of boost trunk with a recent gcc (4.6.0). libs/signals/src/named_slot_map.cpp:105:23: instantiated from here /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_map.h:626:9: error: call of overloaded ‘erase(std::map<boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair>, boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group> >::iterator&)’ is ambiguous /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_map.h:626:9: note: candidates are: /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:763:7: note: void std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::erase(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator) [with _Key = boost::signals::detail::stored_group, _Val = std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> >, _KeyOfValue = std::_Select1st<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, _Compare = boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group>, _Alloc = std::allocator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::const_iterator = std::_Rb_tree_const_iterator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >] /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/bits/stl_tree.h:1490:5: note: std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::size_type std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::erase(const _Key&) [with _Key = boost::signals::detail::stored_group, _Val = std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> >, _KeyOfValue = std::_Select1st<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, _Compare = boost::function2<bool, boost::signals::detail::stored_group, boost::signals::detail::stored_group>, _Alloc = std::allocator<std::pair<const boost::signals::detail::stored_group, std::list<boost::signals::detail::connection_slot_pair> > >, std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::size_type = unsigned int] Patrick

2 1

[Boost Graph Library] Having trouble constructing necessary parameters for the isomorphism algorithm
by Alexander Bock 18 Jan '11

18 Jan '11

Hi all, First of all, I new to the mailing list, so please excuse me for any beginner's mistakes I may make :) I am also new to the Boost Graph Library. I am having some trouble implementing the Boost Graph Library isomorphism algorithm under MSVC++ 2008 Express Edition. Since I am using MSVC++, I cannot use the named parameter method, as specified in the docs. I am not entirely sure, but I think my problem is the vertex invariants that I pass to the algorithm. I am using Boost 1.43. My graph and relevant typedefs look like this: typedef adjacency_list<listS, listS, undirectedS, VertexProperty, EdgeProperty, no_property, listS> UndirectedGraph; typedef graph_traits<UndirectedGraph>::vertex_descriptor VertexDescriptor; I am using bundled properties: struct VertexProperty { string id; int index; }; struct EdgeProperty { string id; int weight; }; Here's my code that tries to call the isomorphism algorithm: bool BoostGraph::Compare(BoostGraph& comparableGraph) { vector<VertexDescriptor> f(GetNoVertices()); property_map<UndirectedGraph, int VertexProperty::*>::type indexMap1 = get(&VertexProperty::index, uGraph); property_map<UndirectedGraph, int VertexProperty::*>::type indexMap2 = get(&VertexProperty::index, comparableGraph.GetGraph()); return isomorphism(uGraph, comparableGraph.GetGraph(), isomorphism_map(make_iterator_property_map(f.begin(), indexMap1, f[0])), ???, ???, vertex_invariant2.max(), indexMap1, indexMap2); } The two '???' are where I need to pass the vertex degree invariants, but I do not know how to construct them. I hope I have supplied sufficient information for you. Thanks in advance!

2 13

[Boost][BGL] New isomorphism test algorithm contribution
by Carlos Cardeñosa Pérez 17 Jan '11

17 Jan '11

Hi, I have been developing a new implementation for test graphs isomorphism, named conauto <http://sites.google.com/site/giconauto/> algorithm (based on José Luis López Presa thesis). I would like to contribute it to BGL. This is a more efficient algorithm than the current one. You can study all its details from conauto thesis at here<http://www.diatel.upm.es/jllopez/tesis/thesis.pdf> . Once developed the first conauto BGL-style version, I am sure that there are many advises and comments that could help to enhance it and eventually will be acceptable for BGL maintainers. Find attached both the source code and some measurements graphics. Please, do not hesitate ask me for any additional information. Best regards, Carlos Cardeñosa.

2 7

GIL io_new review
by Lubomir Bourdev 16 Jan '11

16 Jan '11

First I apologize for not being active in the past several years in the Boost community due to time constraints. I only had a few hours to do this review, but I also reviewed Christian's code a couple of years ago. When we introduced GIL to Boost I was hesitant to include the I/O extension in the Boost submission. I felt that doing the I/O right is a major project and it is better to do it right or not at all. However, without any I/O support it would be very hard to use GIL, so we had to include some I/O extension that provides reasonable support for common formats. Christian has been (and still is) very passionate to make the next generation I/O. He started working on this at least four years ago and have been improving and polishing the code ever since. The problem with I/O is that you can never declare success. There are an unlimited number of file formats, back-ends, ways to read and write the image, image representations, compression settings, etc. For each of these one needs to deal with completeness, performance, test cases, failure modes, platform dependencies... All we can hope for is push the boundary as much as we can, and leave the rest for the next update. What is important in the first release is to get the design right. Once we have a solid foundation we can add a lot of functionality quickly and transparently. Domagoj had some constructive criticism so I will start with that. On the issue of using classes vs free functions, I don't think there is a huge difference either way. The the new_io code borrows the style from GIL, which uses free functions as algorithms (if you call I/O "algorithms"). GIL in turn borrows this style from the STL. Using functions one can extend functionality with overloading (but there are ways to do this with classes too) and it is nicer to be able to read/write a file with one line, without having to first construct a reader/writer and then call it. But these are minor quibbles. On the issue of performance, I don't think one test with one file format being 30% slower proves that there are serious performance issues. My guess is that Christian has been focusing on adding functionality and never got around to work on performance improvements, which usually means that we can get a lot of speedup by doing some simple optimizations in the inner loops. On the issue of using/not using streams, I don't have a strong opinion, except that stream support for I/O was one of the highest requested functionalities in GIL's review. Domagoj, you should have been more vocal at that time. Christian simply responds to the wishlist of the Boost community. In general, I feel that performance might be a bit overhyped in recent discussions. The image I/O operations are often dominated by disk access and by compression, etc. I don't think avoiding a copy of the pixels would make much of a difference in the majority of uses. That said, we do want to make sure GIL I/O is as fast as it can be. On the issue of supporting different backends, I agree with Domagoj that this is important and we should make sure to support it. In Christian's design everything is done in reader and writer classes, which are currently specialized for a specific file format and backend. One could imagine creating classes for other backend+file format combinations without much (any?) changes to the current design. The reader/writer files from the same backend could have common base classes or share functionality in other ways as appropriate. - What is your evaluation of the design? The design is fine, but I would like the requirements for adding new file formats / backends to be made more explicit. Specifically we want a concept for a file format reader/writer/etc and adding new file formats would constitute providing models for these concepts. - What is your evaluation of the implementation? It looks fine but haven't played with it much. - What is your evaluation of the documentation? The documentation is adequate, but requires cleanup and fixing of lots of typos. - What is your evaluation of the potential usefulness of the extensions? Very useful. However, there is some missing functinality which in my opinion is important to have: 1. The ability to read an image without specifying the file format at compile time 2. The ability to support multiple back-ends 3. The ability to efficiently read/write an image in parts - Did you try to use the extensions? With what compiler? Did you have any problems? I did not do anything non-trivial with them. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? About 3 hours looking at the code (but I reviewed a verion about 3 years ago) - Are you knowledgeable about the problem domain? I am familiar with GIL but not very much with file format libraries. - Do you think the extensions should be accepted as a part of Boost.GIL library? Let us consider our options carefully. We could do a "reject" on the basis that there is another alternative libarary (Domagoj's library). I don't think this is a good idea. I looked briefly at his library; there are things I like about it but also things I don't. There are certainly a lot of things that are missing. I will refrain from discussing it because it is not under review but the point is that in its current state it is not superior to what Christian has. Domagoj can improve his library further, but so can Christian, and Christian has been working on this for four years now and had submitted his library for review long time ago. This is a huge effort on behalf of Christian, he produced some great and very useful work and a reject will be demoralizing after so many years of work, and is unjustified given that fundamentally he has the right design. We could do an "accept". I would be ok with this, but there is some important functionality that is missing and adding it will require moderate work and some changes to the interface So my recommendation is "conditional accept" after the above identified must-have functionality has been added, specifically: - Support for reading images whose file format is unknown at compile time. That involves the ability to register file formats / backends, associate them with given extensions and then call the appropriate reader based on the extension of the filename. - Support for different backends. It appears that this can be done simply the same way a file format can be extended, i.e. have "png_libpng" and "png_lodepng" tags. It is not immediately obvious to me why this would be a bad design choice; if someone disagrees they should elaborate. - Support for efficient reading/writing of parts of images that are too large to fit in memory. There are two ways to proceed: one is to have an input/output iterator that enforces sequential access, and another is to allow for user-driven access at the cost of sometimes severe performance. I'd like to hear the opinion of people who would use this more advanced options. My preference is that Christian joins forces with Domagoj to collaborate on these and take the best of their libraries to gil.io. Looks like Domagoj also spent a lot of time and effort on this problem and has gained a lot of valuable intuition. I don't want to see his efforts go to waste either. Other todo items: - Improve the language in the documentation section. - Make sure the test images are license-free. If the license status is unknown, change them to other license-free images. - Do some profiling and performance optimization of the most common formats. Add some test cases to measure speed of common scenarios. - Make sure the test cases provide complete coverage. For example, set a breakpoint in every method, every switch statement and branch. Run your tests and remove any breakpoints that are encountered. Look at the breakpoints that were not hit and add tests for them. Finally, here is an idea that I like, but may be too much work to do in the current release: I would like to have a GIL virtual image view associated with a given file. That would allow reading/writing to simply be copy_pixels, and reading into a different format to be copy_and_convert_pixels. Reading a given ROI could simply be done by creating a subimage_view. The cool thing about this is one could in theory make changes to images without even loading them in memory. The caviat is that doing this right and efficiently is very hard, requires clever caching, plus a wrong access pattern can result in horribly bad performance. Lubomir

5 20

Re: [boost] [context] new version - support for Win64
by Andrzej Krzemienski 15 Jan '11

15 Jan '11

> I've uploaded boost.context-0.3.0.zip to boost vault. Hi, I am new to the idea of context switching, and the idea seams very interesting. I have gotone question regarding the interface. The two arguments that are passed when creating a new context, of type void(*)(void*) and void* look like a way of providing a callback. I am used to, in Boost libraries and C++0x threads, to see function<void()> as a type of callbcak. Is there a reason for not using it in case of context switching? Regards, &rzej

3 3

[ratio][mpl] static metafunctions
by vicente.botet 14 Jan '11

14 Jan '11

Hi, during the Boost.Ratio review as requested to push some of the static integer metafunctions as static_abs, static_sign, static_gcd, static_lcm to a public library. At the begining I has the impression that these functions should be added to Boost.Integer or Boost.Math, but after reflexion I think that these static metafunctions could be better integrated into Boost.MPL with the existing integral functions. I have prepared a patch for 3 of them. Do you think that these can be added to Boost.MPL if I provide the needed documentation and tests? Best regards, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 7

[QuickBook] missing prev/next
by Lorenzo Caminiti 10 Jan '11

10 Jan '11

Hello all, I have generate the Boost.Units documentatiom using Boost.QuickBook from the latest Boost release 1.45.0 but the HTML pages are missing the prev and next page links. I only have the up and home links in the navbar. How can I get the prev and next links to show? Do I need to enable some XLS configuration in the Jamfile? Thank you very much. -- Sent from my mobile device Lorenzo

4 21

[wiki] Warning Guidelines for VC
by Michael Caisse 08 Jan '11

08 Jan '11

A question just came up on IRC concerning the use of the /Za ("disable language extensions") and it not working. While searching for a previous post from STL on the subject [1] Google offered this link: <https://svn.boost.org/trac/boost/wiki/Guidelines/WarningsGuidelines> STL's (Stephan Lavavej's) advice on the subject was to *not* use /Za because it has "an extremely nasty bug". Unfortunately our guidelines suggest it should be used. I began to edit the wiki page but considering the amount of text and an example on the subject I thought it might be best to ask permission first. Should I edit the page to be in-line with STL's suggestion or just leave it as-is? [1] <http://lists.boost.org/Archives/boost/2010/04/165531.php > michael -- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

5 13

[system][chrono] header-only libs
by vicente.botet 06 Jan '11

06 Jan '11

Hi, after discussion with Ion about whether Boost.Interprocess could use Boost.Chrono and Boost.System he has found as major drawback that both are not header-only libs. I have implemented Boost.Chrono as a header only lib. If the user wants Boost.Chrono be a header-only lib s/he needs to define the BOOST_CHRONO_INLINED macro. While this could be useful, there is a problem as Boost.Chrono depends on Boost.System that is not a header-only lib. * I have added this on the configuration file #ifdef BOOST_CHRONO_INLINED #define BOOST_CHRONO_INLINE inline #define BOOST_CHRONO_DECL #else #define BOOST_CHRONO_INLINE // as before #endif * Copied all the .cpp files to the detail/inlined directory. * Renamed the .cpp file by .hpp files * Included in the old .cpp files the corresponding .hpp file in the detail/inlined directory * I've replaced the prefix suffix as follows: #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_prefix.hpp> // must be the last #include #endif #ifndef BOOST_CHRONO_INLINED #include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas #else #include <boost/chrono/detail/inlined/file_name.hpp> #endif * prefixed the definitions of the function in the .cpp files by BOOST_CHRONO_INLINE While doing this I have found a minor issue on Windows platform. I hve nedeed to sorrounded by () all the use of min and max functions on the test files to avoid the macros defined on the windows.h file. That means that a header-only lib could break user sources as it will include implicitly some platform files. Another drawback that I have no inspected yet could be the increase in size and compilation time of the user code. Beman do you mind if I try to make your library configurable as header-only, so Ion could use Boost.System and Boost.Chrono and preserve Boost.Interprocess as a header-only lib? Best, Vicente P.S. You can see the sandbox for the last modifications _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

8 23

[BGL] problem w/ push_relabel_max_flow and floating point capacities
by Marc Schafer 05 Jan '11

05 Jan '11

Using the push_relabel_max_flow feature on graphs that have edge capacities in double or single precision often results in a failed assertion (line 706 push_relabel_max_flow.hpp) on debug builds although the answer provided is correct for builds with assertions disabled. The is_flow() method (line 564, push_relabel_max_flow.hpp) performs some consistency checking after the algorithm completes and there is an assertion that it returns true. The comparisons inside is_flow are done using ==, !=, >, and <. Using a locally modified version, I was able to see that all the cases where is_flow returns false are caused by errors on the order of machine precision. I believe the error is a faulty comparison mechanism inside is_flow rather than a problem with my graphs or the push_relabel_max_flow algorithm. -Marc

2 1