December 2010 - Boost - lists.preview.boost.org

[SQL-Connectivity] Is Boost interested in CppDB?
by Artyom 25 Jan '11

25 Jan '11

Hello, I have recently released a new SQL Connectivity library: General ------- Documentation : http://art-blog.no-ip.info/sql/cppdb/ Mirror Docs. : http://cppcms.sourceforge.net/sql/cppdb/ Download : https://sourceforge.net/projects/cppcms/files/cppdb/ Features -------- - Performance is the primary goal - make fastest possible SQL connectivity as possible - Transparent connection pooling support - Transparent prepared statements caching - Dynamic DB modules loading and optional static linking - Full and high priority support of FOSS RDBMS: MySQL, PostgreSQL, Sqlite3 - Support as many RDBMSs as possible via cppdb-odbc bridge - Simplicity in use - Locale safety - Support of both explicit verbose API and brief and nice syntactic sugar What it is not: --------------- This is not ORM library and not supposed to be so. This is something similar to what JDBC gives to JDK and QtSql gives to Qt and more. Boost Interest -------------- Currently I'm think whether should I boostify it, release it under BSL (currently it is LGPLv3) and submit it for formal review in boost or shouldn't I? Why do I ask, not because I'm thinking it is not good enough but rather because I feel that the "boostification" effort would be wasted at this point. For about half a year ago I had submitted a Boost.Locale for formal review, I use it under other namespace as part of CppCMS project all the time and in fact I receive most request and bug reports for Boost.Locale via CppCMS project and not via CppCMS.Locale so basically I have to handle two projects and synchronize between them all the time, and Boost.Locale is still stuck in review queue. So does it worth the effort? So before I do any steps forward may be it is better to make sure it gets (or even passes the review) and then boostify the library (which can be done very easily). Regards, Artyom

22 53

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

geometry moved to trunk
by Barend Gehrels 21 Jan '11

21 Jan '11

hi, Boost.Geometry is moved from sandbox to trunk yesterday. Questions: 1) Will I update the two files libraries.htm and maintainers.txt within $/trunk/libs to add geometry there? 2) How will geometry appear in the trunk regression overviews? There are already many unit tests using Boost.Test and jamfiles handling them. Thanks, Barend

4 6

[context] new version - support for Win64
by Oliver Kowalke 20 Jan '11

20 Jan '11

I've uploaded boost.context-0.3.0.zip to boost vault. The new version supports the context-/stack- swapping provided by the OS (ucontext ABI on UNIX, Fiber ABI on Windows) as well a fast context swapping (using assembler). supported platforms: i386, x86_64, arm, mips, ppc OS: UNIX, Windows (32 bit/64 bit) More details can be found in the documentation (included in the archive).

7 28

review request: addition to type_traits library of has_operator_xxx
by Frédéric Bron 19 Jan '11

19 Jan '11

I would like to propose to your review the following addition to the type_traits library, available at the following addresses: https://svn.boost.org/trac/boost/browser/sandbox/type_traits http://dl.free.fr/lRm4VL6WP/type_traits.tar.bz2 The purpose of the addition is to add type traits to detect if unary and binary operators can be applied to given types. For example, is "x<y" or "!x" or "x+y" meaningful? If required, the return type of such an expression is checked to know if it is convertible to a given type. Default behaviour is to not check the return type. The following traits are added: // binary operators: template < typename LHS, typename RHS=LHS, typename RET=void > == has_operator_equal_to != has_operator_not_equal_to > has_operator_greater >= has_operator_greater_equal < has_operator_less <= has_operator_less_equal + has_operator_plus - has_operator_minus * has_operator_multiplies / has_operator_divides % has_operator_modulus && has_operator_logical_and || has_operator_logical_or & has_operator_bit_and | has_operator_bit_or ^ has_operator_bit_xor // unary operators: template < typename RHS, typename RET=void > + has_operator_unary_plus - has_operator_unary_minus ! has_operator_logical_not This new version reflects the discussions we had on the list: http://thread.gmane.org/gmane.comp.lib.boost.devel/194625 In particular about the check or not of the return type. All operators are now included and not only comparison binary operators. Example: has_operator_less<LHS, RHS, RET>::value_type is the type bool. has_operator_less<int> inherits from true_type. has_operator_less<int, int, std::string> inherits from false_type. has_operator_unary_minus<int, long> inherits from true_type. has_operator_unary_minus<double, int> inherits from true_type. has_operator_unary_minus<int, std::string> inherits from false_type. Documentation is accessible at libs/type_traits/doc/html/index.html in the archive. Regards, Frédéric PS: tested with g++ 4.4.5 on i686-linux.

14 53

[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

[Review] Formal Review of Proposed Boost.Chrono Library Starts TOMORROW
by Anthony Williams 05 Jan '11

05 Jan '11

Hi everyone, The review of Vicente Botet's Chrono library starts TOMORROW (November 6th) and lasts until November 15th unless an extension occurs. What is it? ======== Boost.Chrono aims to implement the new time facilities in C++0x, as proposed in N2661 - A Foundation to Sleep On (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2661.htm) That document provides background and motivation for key design decisions and is the source of a good deal of information in this documentation. See the current C++0x working draft at http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3126.pdf for details of what was accepted. The Boost.Chrono library provides: * A means to represent time durations: managed by the generic duration class . Examples of time durations include days, minutes, seconds and nanoseconds, which can be represented with a fixed number of clock ticks per unit. All of these units of time duration are united with a generic interface by the duration facility. * A type for representing points in time: time_point. A time_point represents an epoch plus or minus a duration. The library leaves epochs unspecified. A time_point is associated with a clock. * Several clocks, some of which may not be available on a particular platform: system_clock, monotonic_clock and high_resolution_clock. A clock is a pairing of a time_point and duration, and a function which returns a time_point representing now. * To make the timing facilities more generally useful, Boost.Chrono provides a number of additional clocks that are thin wrappers around the operating system's time APIs, thereby allowing the extraction of read (wall clock) time, user CPU time, system CPU time, - process_real_cpu_clock, captures real (wall clock) CPU times. - process_user_cpu_clock, captures user-CPU times. - process_system_cpu_clock, captures system-CPU times. - A tuple-like class __process_cpuclock_, that captures real, user-CPU, and system-CPU times together. - A thread_clock thread monotonic clock, when supported by a platform. * Boost.Chrono also includes typeof registration for duration and time_point to permit using emulated auto with C++03 compilers. * Boost.Chrono also provides I/O for duration and time_point. It builds on <boost/ratio/ratio_io.hpp> to provide readable and flexible formatting and parsing for types in <boost/chrono.hpp>. The duration unit names can be customized through a new facet: duration_punct. Getting the library ============= The latest version of this library may be downloaded from vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=chrono… SVN: http://svn.boost.org/svn/boost/sandbox/chrono Boost.Chrono depends on Boost.Ratio http://www.boostpro.com/vault/index.php?action=downloadfile&filename=ratio.… and optionaly Boost.System Header Only http://www.boostpro.com/vault/index.php?action=downloadfile&filename=system…. and the docs may be viewed here HTML: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/html/index.ht… PDF: http://svn.boost.org/svn/boost/sandbox/chrono/libs/chrono/doc/chrono.pdf You can get all these information also (which should avoid some long links) from http://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Chrono Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick - reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Anthony Review Manager for the proposed Boost.Chrono library -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

9 32

compiling Boost boost_1_45_0 regex with icu (redhat).
by Candid Shot 05 Jan '11

05 Jan '11

Greetings. I am trying to compile boost regex with icu. The icu library is placed in a non-standard place, so I have set the appropriate environment variable. However everytime I run bjam, console output (amongst many thing) says - has_icu builds : no I have invoked bjam with -sBOOST_HAS_ICU=1. No luck picking icu. I have invoked bjam with -sICU_PATH=/home/xxx/yyy, and no luck either. OTOH, if I go to the subdirectory : libs/regex/build and do 'make -f gcc.mak' It builds with -DBOOST_HAVE_ICU=1 and with the right icu include directory in the compile line. I am new to compiling boost, and would love to find out what is going on. And how can I rectify it. Thanks, CD.

3 6

[Range] begin/end ADL issues in C++0x range-based for
by Michel MORIN 04 Jan '11

04 Jan '11

[Range] begin/end ADL issues in C++0x range-based for Hi, I recently played around with C++0x range-based for (available on GCC 4.6 Pre-Release). It turned out that some codes using Boost libraries do not compile. Compiler errors (ambiguous calls to begin/end) are generated, when ADL finds both std::begin/end and boost::begin/end in range-based for and there is no single best match. Remarkably, boost::iterator_range (and adapted ranges in Boost.Range) cannot be used in range-based for. First let us recall range-based for. A range-based for for (auto x : range_expr) { // do something } is equivalent to { // Special rule: namespace std is added to rng's associated namespaces auto&& rng = range_expr; for ( auto it = begin(rng), it_end = end(rng); it != it_end; ++it ) { auto x = *it; // do something } } Note that rng has namespace std as its associated namespaces and the unqualified begin/end function call triggers ADL. In C++0x, there are std::begin functions (for simplicity, let's ignore end): template <typename Range> auto begin(Range& r) -> decltype(r.begin()); template <typename Range> auto begin(Range const& r) -> decltype(r.begin()); And Boost.Range has boost::begin functions: template <typename Range> inline typename boost::range_iterator<Range >::type begin(Range& r); template <typename Range> inline typename boost::range_iterator<Range const>::type begin(Range const& r); So, if - rng has namespace boost as its associated namespaces, - the header file boost/range/begin.hpp is included, and - there is no single best match between std::begin and boost::begin, then unqualified begin function call becomes ambiguous. For example, all the following codes fail to be compiled: // code 1 #include <boost/range/iterator_range.hpp> for (auto x : boost::iterator_range<int*>(nullptr, nullptr)) {} // error // code 2 #include <boost/ptr_container/ptr_vector.hpp> for (auto x : boost::ptr_vector<int>()) {} // error // code 3 #include <vector> #include <boost/range/adaptor/reversed.hpp> for (auto x : std::vector<int>() | boost::adaptors::reversed) {} // error // code 4 #include <boost/algorithm/string.hpp> #include <boost/array.hpp> for (auto x : boost::array<int, 2>()) {} // error // code 5 #include <vector> #include <boost/shared_ptr.hpp> #include <boost/range/algorithm.hpp> for (auto x : std::vector<boost::shared_ptr<int> >()) {} // error These errors can be resolved by fixing boost/range/begin.hpp. The fix uses a using-declaration ("using std::begin;") and SFINAE (disable_if with "has_begin" metafunction). A summary of range-based-for-compatible <boost/range/begin.hpp> is the following: #ifndef BOOST_NO_RANGE_BASED_FOR namespace boost { using std::begin; // has_begin metafunction... template <typename Range> inline typename boost::range_iterator<Range>::type begin(Range& rng, typename disable_if<range_detail::has_begin<Range>>::type* = 0) { return range_begin(rng); } // const version ... } #else // existing code... For details, see the attached. I also attach a patch for Boost.Config to add BOOST_NO_RANGE_BASED_FOR. Any comments or thoughs? Regards, Michel

4 7

[smart_ptr] enable_shared_from_this and multiple inheritance solution
by Philippe Cayouette 03 Jan '11

03 Jan '11

Fellow boosters, A little while ago I found a pernicious problem with enable_shared_from_this when used with multiple inheritance. Here is an example: #include <boost/smart_ptr.hpp> #include <boost/enable_shared_from_this.hpp> class Base1 : public boost::enable_shared_from_this< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return shared_from_this(); } }; class Base2 : public boost::enable_shared_from_this< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return shared_from_this(); } }; class Derived : public Base1, public Base2 { }; int main() { boost::shared_ptr< Derived > wDerived(new Derived()); // Either of the following lines crashes with GCC, but the first one // passes on VS2005 boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } Since Derived inherits from two bases that each inherits from enable_shared_from_this, it has two internal weak_ptr. These weak_ptr are usualy initialised in the constructor of the shared_ptr and I have observed two different behavior with the above code depending if I build it with VS2005 or GCC. With VS2005, the first base class in the inheritance list of Derived (here Base1) get its internal weak_ptr initialized, but not the second one, thus it crashes when we try to access the Base2 weak_ptr via shared_from_this. On GCC, neither base classes get their internal weak_ptr initialized and both base classes access to their internal weak_ptr provokes a crash. To prevent that kind of problem, I created a SmartPtrBuilder and a (very) slightly modified EnabledSharedFromThis (only one assert was removed). Here is the same program with the modifications: #include <boost/smart_ptr.hpp> #include "EnableSharedFromThis.h" #include "SmartPtrBuilder.h" class Base1 : public Generic::EnableSharedFromThis< Base1 > { public: Base1() {} virtual ~Base1() {} boost::shared_ptr< Base1 > GetBase1() { return SharedFromThis(); } }; class Base2 : public Generic::EnableSharedFromThis< Base2 > { public: Base2() {} virtual ~Base2() {} boost::shared_ptr< Base2 > GetBase2() { return SharedFromThis(); } }; class Derived : public Base1, public Base2 { public: // Factory method static boost::shared_ptr< Derived > Create() { return Generic::SmartPtrBuilder::CreateSharedPtr< Base1, Base2 >(new Derived()); } private: Derived() {} }; int main() { boost::shared_ptr< Derived > wDerived = Derived::Create(); // No more crashes boost::shared_ptr< Base1 > wBase1 = wDerived->GetBase1(); boost::shared_ptr< Base2 > wBase2 = wDerived->GetBase2(); return 0; } As you can see, Derived has now a factory method that uses the SmartPtrBuilder to create the shared_ptr. Two template arguments are used on CreateSharedPtr, allowing it to initialize the internal weak_ptr of each base classes. The SmartPtrBuilder I did can support up to 10 base classes as template arguments and I also did a variadic template version which has no limit. By using the factory method, the users of Derived don't need to know which of its base classes need its internal weak_ptr need to be initialized. Source code for the SmartPtrBuilder and the modified EnableSharedFromThis: http://spoluck.ca:8000/boost/EnableSharedFromThis.h http://spoluck.ca:8000/boost/SmartPtrBuilder.h That builder might be incorporated to the boost smart pointer library so that anyone could use its facilities to prevent the problem mentioned earlier. No modification to the mighty shared_ptr class required, only the addition of a builder. What do you think? Philippe

3 7

[SoC] BGL project idea
by Gautam Sewani 03 Jan '11

03 Jan '11

Hi, I am a Computer Science student hoping to contribute to Boost for this year's summer of code. I had a few questions regarding the BGL project idea (https://svn.boost.org/trac/boost/wiki/SoC2010#Boost.Graph) for SOC 2010. 1. I can think of only a few places where the suggested algorithms will be used. Does the community think that these algorithms are used frequently enough to put them in a library? How important does the community consider this project? 2. Will the project proposal be expected to include the API design? Thanks and Regards Gautam

5 29

[BGL] Get properties from an out_edge_iterator efficiently
by Shaun Jackman 03 Jan '11

03 Jan '11

Hi, I have a graph implementation where get(tag, graph, out_edge_iterator) is much more efficient than get(tag, graph, edge_descriptor) which is probably not an usual case. Would it make sense for BGL to provide a default implementation of the former that dereferences the iterator and calls the latter? Graphs for which the former is more efficient could then specialize this function template. Cheers, Shaun

2 3

[thread] boost::this_thread::sleep broken?
by Jamie Allsop 02 Jan '11

02 Jan '11

From the docs I'd expect to be able to write this: std::cout << "Time Before Sleep: " << boost::posix_time::microsec_clock::local_time() << std::endl; boost::this_thread::sleep( boost::posix_time::seconds(10) ); std::cout << "Time After Sleep : " << boost::posix_time::microsec_clock::local_time() << std::endl; and have the 'this' thread sleep for approximately 10 seconds. Instead sleep returns instantaneously: Time Before Sleep: 2010-Dec-25 01:38:50.949160000 Time After Sleep : 2010-Dec-25 01:38:50.949436000 I've tried this with boost 1.45 and boost 1.43 using gcc 4.4 on debian x86_64. Am I missing something obvious? Jamie

2 2

Respecting a projects toolchain decisions (was Re: [context] new version - support for Win64)
by Lars Viklund 02 Jan '11

02 Jan '11

>>> On Fri, Dec 17, 2010 at 9:34 PM, Lars Viklund<zao(a)acc.umu.se> wrote: >>>> Maybe you can adapt to the conventions of the real world, or use >>>> git-svn? >> On Fri, Dec 17, 2010 at 22:19, Dean Michael Berris >> <mikhailberis(a)gmail.com> wrote: >>> Which real world are you talking about, the one that I live in where >>> nobody uses SVN anymore and instead use Git for large open source >>> development projects? :) >Am 18.12.2010 09:47, schrieb Scott McMurray: >> Probably the "large commercial software company" world where the >> source control is so bad that branches get merged once every two weeks >> at best, and all checkins are blocked for over 24 hours when they do, >> so multiple releases get worked on in the same branch just to avoid >> the merging headaches. On Sat, Dec 18, 2010 at 03:46:30PM +0100, Oliver Kowalke wrote: >I think we should stop this talk - if desired you can start a new thread >with this topic. I apologise if the term "real world" was misunderstood, but I'm rather tired of when people come in from the outside, implying or demanding that a project should change their version control, build system or favourite bikeshed colour, just because they are used to something else (possibly "better") from elsewhere. As for version control, what does it matter if Boost uses Subversion, when you as a DVCS user can trivially use git-svn [1] to interop against the repository (in this case, the sandbox). You get to use your favourite toy, without affecting the existing infrastructure in any way. In the end, the version control you choose is rather tangential. As long as it's sufficiently competent (which Subversion in my eyes is), you'll survive. Of course, you may propose constructive criticism and suggest migration plans to other toolchains, with good arguments for why this is a good thing. See the mythical 'Ryppl' project, which aims to componentise Boost into a pile of Git repositories and some magical combination of scripts and CMake, aimed at letting you track exactly the versions of components you need. Remember that no tool is isolated. Changing from Subversion to <whatever> would result in many changes propagating to how test runners are set up, rewriting of commit hooks, modifying Trac (if possible) (although the SVN functionality is disabled there for now), requiring adaptation of any entity out there that use Boost's repositories in any way, including externals, build scripts, CI environments, etc. And of course, having to have the mirrored Subversion repositories up for years, as you can't really 'flag day' such things. -- Lars Viklund | zao(a)acc.umu.se

28 102

[Review][Ratio] Boost.Ratio has been ACCEPTED
by Anthony Williams 01 Jan '11

01 Jan '11

Hi, I am pleased to announce that Boost.Ratio has been ACCEPTED into Boost. There were not as many reviews for Boost.Ratio as for some libraries, but they were overwhelmingly positive. Boost.Ratio is an important building block for other upcoming submissions, and provides an implementation of the C++0x rational arithmetic facilities. A few changes were requested by the reviewers, which I will list below. I know that Vicente has already started working on some of these. These changes should be addressed before the library appears in a Boost release. * Some of the macros had names with RATIO_RATIO in. These should be changed to just RATIO * The ratio_add, ratio_sub, ratio_multiply and ratio_divide templates should derive from the resulting ratio type as well as providing the nested ::type member, in order to closely emulate the template alias facility from C++0x * The typos in the documentation should be fixed, and the documentation reviewed for correctness and clarity (though several of the reviewers made positive comments on the quality of the documentation). * The library needs more tests under the Boost Software License. * All references to names from the boost namespace should be qualified with boost:: to avoid potential name clashes and ambiguity with names from the global namespace. * Sections commented out with #if 0 should be removed * The extensions beyond the facilities required by the C++0x draft should be able to be enabled or disabled through use of a configuration macro. * References to the tests, examples and documentation from within the code should be checked for correctness. I would like to thank Vicente for submitting the library and those that took the time to write a review. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

2 2

[fiber] new version
by Oliver Kowalke 01 Jan '11

01 Jan '11

boost.fiber has been refactored - most of the code has moved to another lib. The new version allows directly to run and yield the fiber. class jumpable is an example how a fiber can be used.

2 3