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

[mpl] zero argument member template detection
by Daniel Walker 07 Jul '10

07 Jul '10

Hello, Following up on Steven's question from a few weeks ago (sorry for delay) about has_xxx_template, there is a bug in msvc 9 and 10 that causes ICE. I filed a bug against msvc here. https://connect.microsoft.com/VisualStudio/feedback/details/571720 Here is code to reproduce the bug. struct S { template<class T = int> struct X {}; }; template<class T> // The following line causes ICE void f(typename T::template X<>*) {} // The following alternative line compiles cleanly //void f(typename S::template X<>*) {} // The following line also compiles cleanly //void f(typename T::template X<int>*) {} int main() { f<S>(0); } Incidentally, the code above is accepted by msvc 8 and gcc... and clang! :) I do not know of a work around. Moreover, while looking for a work around, I found another bug in has_xxx_template that may render zero argument detection unreliable on any compiler. Rethinking some of my original design choices, I now believe that it is a bad idea to conflate member template detection and template arity detection. It would be better if BOOST_MPL_HAS_XXX_TEMPLATE_DEF defined a metafunction to detect member templates of any arity (up to some configurable limit). So I made the appropriate changes to effect this and updated the tests and documentation. The changes did not cause errors running the MPL test suite on gcc 3.4, 4.3, 4.4, 4.5 and msvc 7.1, 8, 9, 10. So, in sum, the interface is now cleaner and works consitently across compilers. Since this is the first release of has_xxx_template, I went ahead and checked the changes into trunk. Hopefully, I got this committed in time for the 1.44 code freeze... Do I still need to merge to release? Further discussion of some details follows for those who are interested. First, regarding the general problem of template arity detection, perhaps this is a motivating need for a seperate template_arity metafunction. There's already one in mpl/aux_ that's not part of the external library API. If there's interest, I'll post more on this later in a seperate thread. Regarding the specific problem of zero member template argument detection for has_xxx_template, the issue is that while you can instantiate a template with zero arguments, you do not actually declare a template with zero arguments, obviously. For example, struct S { template<class T = int> struct xxx {}; }; So, S::xxx is actually a one argument template that can be instatiated with zero args; e.g. S::xxx<>(). Originally, I was trying to detect how many arguments a template can be instatiated with, but I think this is the wrong approach. The technique I'm using in BOOST_MPL_HAS_XXX_TEMPLATE_DEF can only reliably detect the declared arity of the tempate. Here's a brief outline of how it works. BOOST_MPL_HAS_XXX_TEMPLATE_DEF defines a metafunction that uses SFINAE to detect member templates in the following way. template<template<class> class> struct substitute {}; template<class T> long has_xxx_test(substitute< T::template xxx >*); template<class> short has_xxx_test(...); const bool result = sizeof(has_xxx_test<S>(0)) == sizeof(long); However, to detect zero arguments, the following would be invalid, since you cannot declare a template with zero parameters. template<template<> class> struct substitute {}; So instead the zero arg test was performed using template<class T> long has_xxx_test(typename T::template xxx<>*); Unfortunately, this test causes ICE on msvc, and really, it doesn't completely work on any compiler, since it is invalid if T's xxx member template does not have default parameters; i.e. it cannot properly reject member templates requiring one or more arguments. The new BOOST_MPL_HAS_XXX_TEMPLATE_DEF on trunk resolves these issues by removing the requirement that users specify the template arity and arguments. Instead, it generates a metafunction that detects member templates of any arity. It does so by providing several overloads of the internal test function, one for each arity, up to a user configurable maximum (BOOST_MPL_LIMIT_METAFUNCTION_ARITY) as illustrated by the following simplified code. #include <boost/mpl/assert.hpp> #include <boost/mpl/bool.hpp> template<class T> class has_xxx { template<template<class> class> struct substitute1 {}; template<template<class,class> class> struct substitute2 {}; template<class U> static long has_xxx_test(substitute1<U::template xxx>*); template<class U> static long has_xxx_test(substitute2<U::template xxx>*); template<class> static short has_xxx_test(...); public: static const bool value = sizeof(has_xxx_test<T>(0)) == sizeof(long); typedef boost::mpl::bool_<value> type; }; struct S1 { template<class> struct xxx {}; }; struct S2 { template<class,class> struct xxx {}; }; int main() { BOOST_MPL_ASSERT(( has_xxx<S1> )); BOOST_MPL_ASSERT(( has_xxx<S2> )); BOOST_MPL_ASSERT_NOT(( has_xxx<int> )); } Daniel Walker

1 0

Re: [boost] auto-link with gcc/windows
by Jürgen Hunold 07 Jul '10

07 Jul '10

Hi Robert ! On Monday, 5. July 2010 19:35:02 you wrote: > In my code I use BOOST_HAS_DECLSPEC but I'm having problems with > mingw. I'm not sure it has anything to do with this, but it's not at clear > to me > what the differing meanings are of BOOST_HAS_DECLTYPE and > BOOST_HAS_DECLSPEC. BOOST_HAS_DECLSPEC is the interesting one. Please find a patch adding two more "#define BOOST_SERIALIZATION_SOURCE" to the sources. This fixed compilation for me when using gcc's symbol visibility and might help here as mingw uses symbol visibility "under the hood" for __declspec(dllimport/-export). Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! * voice: ++49 4257 300 ! Fährstraße 1 * fax : ++49 4257 300 ! 31609 Balge/Sebbenhausen * juergen.hunold(a)gmx.de ! -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

8 23

Parsing boost 1.43 with gcc-xml (bug #4324 - fixed in trunk)
by Benoît Leveau 07 Jul '10

07 Jul '10

Hello, I have problems parsing boost 1.43 with gcc-xml, due to the lack of several preprocessor flags in /boost/config/compiler/gcc_xml.hpp. I saw this problem has been fixed in the trunk 4 weeks ago: /trunk/boost/config/compiler/gcc_xml.hpp Revision 62666: Disable all C++0x features in GCC-XML for now. Fixes #4324. I am not familiar with the details of the release process, so I'm wondering if a patched 1.43 version will be released? This bug is quite serious as it prevents boost from being parsed by gccxml (which, I guess, is listed as a supported compiler), and 1.44 hasn't been released yet, which leaves no option other than patching my local copy with the fix from the trunk. I would prefer to use an official release as it's not for a personal project, but will do the patch if I have to. Thanks for your help! Benoit

2 1

[thread] more generic future?
by Oliver Kowalke 07 Jul '10

07 Jul '10

The future implementation of boost.thread uses boost.mutex, condition and condition_any. What about renaming future to future_base or put it into namespace boost::detail and pass the sync. primitves (mutex, condition) as template args? This would provide the way that other libs could use the future impl with their own sync. primitives. namespace boost { namespace detail { template< typename MutexT, typename ConditionT > future {...}; }} namespace boost { typedef detail::future< mutex, condition > future; namespace fibers { class mutex {}; class condition {}; typedef detail::future< mutex, condition > future; }} boost::future -> uses pthreads/Win32 threads boost::fibers::future -> used for fibers Oliver

1 0

Boost Graph Library: Dijkstra Shortest Path ignores color_map in named parameters?
by Alex Hagen-Zanker 07 Jul '10

07 Jul '10

I am trying to use the dijkstra_shortest_path algorithm with named parameters. It worked well, until I wanted to pass the color map as an argument. Despite providing my own color_map, the algorithm ends up creating its own two_bit_color_map. I am using the following code: template<class TGraph, class TVisitor> int myDijkstra(TGraph& graph, TVisitor& visitor, int source) { bool earlyExit = false; const int nVertices =boost::num_vertices(graph); std::vector<double> distances(nVertices); std::vector<typename TGraph::vertex_descriptor> predecessors(nVertices); std::vector<boost::default_color_type> colors(nVertices); try { boost::dijkstra_shortest_paths<TSubGraph, TVisitor >( graph, source, boost::predecessor_map( &predecessors[0] ) .distance_map( &distances[0] ) .visitor( visitor ) .color_map( &colors[0] ) ); } catch( EarlyExitByVisitor ) { earlyExit = true; } return earlyExit ? CountBlackVertices(colors) : nVertices; } The code compiles and runs, but the vector of colors is never modified (I can initialize it with different colors, makes no difference). The predecessor and distance maps are fine. Tracing what happens in the source code (boost version 1.43). I notice that the Named Parameter Variant (line 466) gets the distance, weight and index from the named parameter object. It then passes on to the dijkstra_dispatch1 (line 443) that adds the default for the distance map. It passes on to dijkstra_dispatch2 (line 413) that sets even more parameters, but not the color map. Finally it calls dijkstra_shortest_paths variant with default color_map (line 342), which ignores the named parameter object and provides its own color map. (all of the line numbers are in file dijkstra_shortest_paths.hpp). My question is: is this a bug? Can I use named parameters if I want to provide my own color_map? How? Any help is appreciated. -- Alex Hagen-Zanker

2 7

Unicode and codecvt facets
by Mathias Gaunard 06 Jul '10

06 Jul '10

As some may know, I am working on a Unicode library that I plan to submit to Boost fairly soon. The codecs in that library are based around iterators and ranges, but since there was some demand for support for codecvt facets I am working on adapting those into that form as well. Unfortunately, it seems it is only possible to subclass std::codecvt<char, char, mbstate_t> and std::codecvt<wchar_t, char, mbstate_t>. I personally don't know and understand that much about iostreams/locales, but I have looked quickly at libstdc++'s implementation and it doesn't seem like it is possible for std::locale to contain any other instance of codecvt. What I wonder is if there is really a point to facets, then. std::codecvt<wchar_t, char, mbstate_t> means that the in-memory charset would be UTF-16 or UTF-32 (depending on the size of wchar_t) while the file would be UTF-8. The problem is that wchar_t is platform-dependent and not really reliable, so it's not really something I'd recommend to use as the in-memory representation to deal with Unicode. Why do people even use utf8_codecvt_facet anyway? What's wrong with dealing with UTF-8 rather than maybe UTF-16 or UTF-32?

4 10

auto-link with gcc/windows
by Robert Ramey 06 Jul '10

06 Jul '10

I've been seeing a problem in building MinGW version of he serializationalization library. This is related to auto-link. Now I notice that in config/compiler/gcc.hpp we've got: #if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)) && defined(__GXX_EXPERIMENTAL_CXX0X__) # define BOOST_HAS_DECLTYPE ... # define BOOST_NO_DECLTYPE Also in another part of the same file I find: #if __GNUC__ >= 4 # if defined(_WIN32) || defined(__WIN32__) || defined(WIN32) // All Win32 development environments, including 64-bit Windows and MinGW, define // _WIN32 or one of its variant spellings. Note that Cygwin is a POSIX environment, // so does not define _WIN32 or its variants. # define BOOST_HAS_DECLSPEC In my code I use BOOST_HAS_DECLSPEC but I'm having problems with mingw. I'm not sure it has anything to do with this, but it's not at clear to me what the differing meanings are of BOOST_HAS_DECLTYPE and BOOST_HAS_DECLSPEC. Robert Ramey

3 2

Complexity of Goldberg's push_relabel max flow algorithm used in BOOST
by Dan Jiang 06 Jul '10

06 Jul '10

Anyone knows the time complexity of the Goldberg's push_relabel max flow algorithm used in BOOST? The BOOST documentation says O(n^3). But since the code seems to use highest label, global and gap relabeling and hence the complexity should be O(n^2 * m^1/2). According to literature, the complexity would be O(n^3) if FIFO is used in implementation. Please correct if I am wrong. Dan _________________________________________________________________ Look 'em in the eye: FREE Messenger video chat http://go.microsoft.com/?linkid=9734386

1 0

[function_types] is there an equivalent for functors?
by Edd Dawson 06 Jul '10

06 Jul '10

Hi all, I'm looking for code that does what boost::function_types::parameter_types does but for functors. Support for things such as boost::bind/lambda/function/signals(1&2)/etc and the standard binders and adaptors would be nice. I specifically want to be able to do something like: template<typename Functor> void f(const Functor &f) { typedef typename functor_params<Functor>::type params; // an mpl sequence const std::size_t arity = functor_arity<Functor>::value; // ... } I started writing code for this but I've come to the point where I can't see a way to support libraries such as boost::bind without relying on their implementation details. But perhaps something like this already exists? Thanks, Edd

6 19

[BGL] trunk@63671: `detail/adjacency_list.hpp` needs to include <algorithm>
by Daniel Trebbien 05 Jul '10

05 Jul '10

I get a compilation error in `boost/graph/detail/adjacency_list.hpp` that is fixed by adding `#include <algorithm>` to the top: /usr/local/include/boost/graph/detail/adjacency_list.hpp:1653: error: `equal_range` is not a member of `boost::graph_detail` A patch is attached.

2 3

Coming up on 1.44 code freeze
by Marshall Clow 05 Jul '10

05 Jul '10

I've been looking at the trunk and release branch, I've noticed that there are a lot of files that exist only in one or the other. My suspicion is that this is a result of work not getting merged to the release branch. The last day for "major code changes" for the 1.44 release is Monday, July 5th, Here's a list of what I found: Only in 'release/' boost/fusion/adapted/class/class_iterator.hpp boost/fusion/adapted/class/detail/at_impl.hpp boost/fusion/adapted/class/detail/at_key_impl.hpp boost/fusion/adapted/class/detail/begin_impl.hpp boost/fusion/adapted/class/detail/category_of_impl.hpp boost/fusion/adapted/class/detail/end_impl.hpp boost/fusion/adapted/class/detail/has_key_impl.hpp boost/fusion/adapted/class/detail/is_sequence_impl.hpp boost/fusion/adapted/class/detail/is_view_impl.hpp boost/fusion/adapted/class/detail/size_impl.hpp boost/fusion/adapted/class/detail/value_at_impl.hpp boost/fusion/adapted/class/detail/value_at_key_impl.hpp boost/fusion/adapted/class/extension.hpp boost/lambda/detail/control_structures_impl.hpp boost/numeric/ublas/tempfile.2.tmp boost/numeric/ublas/tempfile.3.tmp boost/numeric/ublas/tempfile.4.tmp boost/numeric/ublas/tempfile.tmp boost/smart_ptr/enable_shared_from_this2.hpp doc/test/accumulators.tag doc/test/dvips.version doc/test/gs.version doc/test/html/images/accumulators doc/test/latex.version libs/filesystem/doc libs/filesystem/example libs/filesystem/src libs/filesystem/test/convenience_test.cpp libs/filesystem/test/deprecated_test.cpp libs/filesystem/test/equivalent.cpp libs/filesystem/test/fstream_test.cpp libs/filesystem/test/large_file_support_test.cpp libs/filesystem/test/lpath.hpp libs/filesystem/test/msvc libs/filesystem/test/operations_test.cpp libs/filesystem/test/path_test.cpp libs/filesystem/test/wide_test.cpp libs/fusion/test/functional/make_unfused_generic.cpp libs/fusion/test/functional/make_unfused_lvalue_args.cpp libs/fusion/test/functional/make_unfused_rvalue_args.cpp libs/fusion/test/functional/unfused_generic.cpp libs/fusion/test/functional/unfused_lvalue_args.cpp libs/fusion/test/functional/unfused_rvalue_args.cpp libs/graph/example/kolmogorov-eg.cpp libs/graph/test/kolmogorov_max_flow_test.cpp libs/math/doc/html/standalone_HTML.manifest libs/range/doc/html/range/reference/adaptors/adaptors_reference.html libs/range/doc/reference/adaptors/adjacent_filtered.html libs/range/doc/reference/adaptors/copied.html libs/range/doc/reference/adaptors/filtered.html libs/range/doc/reference/adaptors/indexed.html libs/range/doc/reference/adaptors/indirected.html libs/range/doc/reference/adaptors/map_keys.html libs/range/doc/reference/adaptors/map_values.html libs/range/doc/reference/adaptors/replaced.html libs/range/doc/reference/adaptors/replaced_if.html libs/range/doc/reference/adaptors/reversed.html libs/range/doc/reference/adaptors/sliced.html libs/range/doc/reference/adaptors/strided.html libs/range/doc/reference/adaptors/tokenized.html libs/range/doc/reference/adaptors/transformed.html libs/range/doc/reference/adaptors/uniqued.html libs/test/example/cla/Jamfile libs/test/example/est_example1.cpp libs/test/example/est_example2.cpp libs/test/example/unit_test_example_011.cpp libs/test/example/unit_test_example_012.cpp libs/test/test/CMakeLists.txt Only in 'trunk/' boost/detail/extended_integer.hpp boost/filesystem/detail boost/filesystem/v2 boost/filesystem/v3 boost/fusion/algorithm/iteration/iter_fold.hpp boost/fusion/algorithm/iteration/reverse_fold.hpp boost/fusion/algorithm/iteration/reverse_iter_fold.hpp boost/fusion/include/iter_fold.hpp boost/fusion/include/reverse_fold.hpp boost/fusion/include/reverse_iter_fold.hpp boost/graph/boykov_kolmogorov_max_flow.hpp boost/graph/loop_erased_random_walk.hpp boost/graph/random_spanning_tree.hpp boost/io/detail boost/iterator/function_input_iterator.hpp boost/numeric/ublas/assignment.hpp boost/numeric/ublas/functional.hpp-0 boost/random/detail/operators.hpp boost/random/discrete_distribution.hpp boost/random/extreme_value_distribution.hpp boost/random/seed_seq.hpp boost/random/shuffle_order.hpp boost/random/weibull_distribution.hpp boost/serialization/item_version_type.hpp boost/signals2/detail/foreign_ptr.hpp boost/smart_ptr/enable_shared_from_raw.hpp boost/spirit/home/karma/detail/attributes.hpp boost/spirit/home/karma/detail/get_stricttag.hpp boost/spirit/home/karma/directive/strict_relaxed.hpp boost/spirit/home/karma/nonterminal/debug_handler.hpp boost/spirit/home/karma/nonterminal/debug_handler_state.hpp boost/spirit/home/karma/nonterminal/simple_trace.hpp boost/spirit/home/qi/detail/attributes.hpp boost/spirit/home/qi/nonterminal/debug_handler_state.hpp boost/spirit/include/karma_strict_relaxed.hpp boost/system/api_config.hpp boost/test/included/execution_monitor.hpp boost/test/prod_tools.hpp boost/test/utils/setcolor.hpp boost/type_traits/is_lvalue_reference.hpp boost/type_traits/is_rvalue_reference.hpp boost/typeof/unsupported.hpp libs/algorithm/string/test/find_format_test.cpp libs/exception/doc/source libs/filesystem/test/resize_file_test.txt libs/filesystem/test/xx libs/filesystem/v2 libs/filesystem/v3 libs/format/test/format_test_enum.cpp libs/fusion/test/algorithm/fold.hpp libs/fusion/test/algorithm/fold2.cpp libs/fusion/test/algorithm/iter_fold.cpp libs/fusion/test/algorithm/reverse_fold.cpp libs/fusion/test/algorithm/reverse_iter_fold.cpp libs/graph/doc/boykov_kolmogorov_max_flow.html libs/graph/doc/figs/bk_max_flow.gif libs/graph/doc/figs/warning.png libs/graph/example/boykov_kolmogorov-eg.cpp libs/graph/quickbook libs/graph/test/boykov_kolmogorov_max_flow_test.cpp libs/graph/test/random_spanning_tree_test.cpp libs/interprocess/proj/vc7ide/intermodule_singleton_test.vcproj libs/interprocess/test/intermodule_singleton_test.cpp libs/io/doc/quoted_manip.html libs/io/test/quoted_manip_test.cpp libs/iostreams/test/deprecated_file_descriptor_test.cpp libs/iostreams/test/detail/file_handle.hpp libs/iterator/doc/function_input_iterator.html libs/iterator/doc/function_input_iterator.rst libs/iterator/test/function_input_iterator_test.cpp libs/lambda/test/result_of_tests.cpp libs/multi_array/example/resize_from_other.cpp libs/multi_array/test/reverse_view.cpp libs/numeric/ublas/bench5 libs/numeric/ublas/doc/samples/assignment_examples.cpp libs/numeric/ublas/test/sparse_view_test.cpp libs/numeric/ublas/test/test_assignment.cpp libs/parameter/doc/README.txt libs/parameter/test/literate libs/ptr_container/test/const_element_containers.cpp libs/python/example/quickstart/bin libs/random/example/password.cpp libs/random/test/chi_squared_test.hpp libs/random/test/test_binomial.cpp libs/random/test/test_binomial_distribution.cpp libs/random/test/test_discrete.cpp libs/random/test/test_discrete_distribution.cpp libs/random/test/test_extreme_value.cpp libs/random/test/test_extreme_value_distribution.cpp libs/random/test/test_gamma.cpp libs/random/test/test_gamma_distribution.cpp libs/random/test/test_poisson.cpp libs/random/test/test_poisson_distribution.cpp libs/random/test/test_seed_seq.cpp libs/random/test/test_weibull.cpp libs/random/test/test_weibull_distribution.cpp libs/range/doc/html/range/reference/algorithms/range_algorithm_introduction.html libs/range/doc/html/range/reference/overview.html libs/range/test/algorithm_test/copy_n.cpp libs/range/test/algorithm_test/remove_copy.cpp libs/range/test/algorithm_test/remove_copy_if.cpp libs/range/test/algorithm_test/replace_copy.cpp libs/range/test/algorithm_test/replace_copy_if.cpp libs/range/test/algorithm_test/reverse_copy.cpp libs/range/test/algorithm_test/rotate_copy.cpp libs/range/test/algorithm_test/search_n.cpp libs/range/test/algorithm_test/swap_ranges.cpp libs/range/test/algorithm_test/unique_copy.cpp libs/range/test/replace_copy.cpp libs/serialization/test/test_diamond_complex.cpp libs/serialization/vc7ide/test_diamond_complex.vcproj libs/smart_ptr/test/enable_shared_from_raw_test.cpp libs/smart_ptr/test/make_shared_fp_test.cpp libs/spirit/doc/Missing.txt libs/spirit/doc/html/spirit/lex/reference/concepts libs/spirit/doc/html/spirit/what_s_new/spirit_2_4.html libs/spirit/example/scheme libs/spirit/test/karma/debug.cpp libs/spirit/test/karma/karma_optional_double.cpp libs/spirit/test/karma/semantic_action_attribute.cpp libs/spirit/test/lex/regression006.cpp libs/spirit/test/qi/attr_with_action.cpp libs/system/src/local_free_on_destruction.hpp libs/system/test/dynamic_link_test.cpp libs/system/test/throw_test.cpp libs/test/doc/Jamfile.v2 libs/test/doc/html/utf/user-guide/test-output/FPT.html libs/test/doc/src/Jamfile.v2 libs/test/doc/src/btl-toc.xml libs/test/doc/src/btl.xml libs/test/doc/src/execution-monitor.xml libs/test/doc/src/faq.xml libs/test/doc/src/minimal-testing.xml libs/test/doc/src/program-execution-monitor.xml libs/test/doc/src/snippet libs/test/doc/src/tutorial.hello-the-testing-world.xml libs/test/doc/src/tutorial.intro-in-testing.xml libs/test/doc/src/tutorial.new-year-resolution.xml libs/test/doc/src/utf.testing-tools.xml libs/test/doc/src/utf.tutorials.xml libs/test/doc/src/utf.usage-recommendations.xml libs/test/doc/src/utf.user-guide.runtime-config.xml libs/test/doc/src/utf.users-guide.fixture.xml libs/test/doc/src/utf.users-guide.test-organization.xml libs/test/doc/src/utf.users-guide.test-output.xml libs/test/doc/src/utf.users-guide.xml libs/test/doc/src/utf.xml libs/test/doc/src/xsl libs/test/doc/utf-boostbook.jam libs/test/example/test_example1.cpp libs/test/example/test_example2.cpp libs/test/example/unit_test_example_13.cpp libs/type_traits/doc/html/boost_typetraits/reference/is_lvalue_reference.html libs/type_traits/doc/html/boost_typetraits/reference/is_rvalue_reference.html libs/type_traits/doc/is_lvalue_reference.qbk libs/type_traits/doc/is_rvalue_reference.qbk libs/type_traits/test/is_lvalue_reference_test.cpp libs/type_traits/test/is_rvalue_reference_test.cpp libs/type_traits/test/tricky_rvalue_test.cpp libs/units/example/autoprefixes.cpp libs/utility/initialized_test.cpp libs/utility/initialized_test_fail1.cpp libs/utility/initialized_test_fail2.cpp libs/utility/value_init_workaround_test.cpp tools/boostbook/xsl/html-base.xsl tools/build/v2/test/exit_status.py tools/build/v2/tools/doxygen tools/build/v2/tools/xsltproc tools/release/merge2release.bat -- Marshall

5 5

[BGL] all_clustering_coefficients
by Barend Gehrels 05 Jul '10

05 Jul '10

Hi, Is the function all_clustering_coefficients documented in 1.44, or can it be documented in a new version? It has this functionality (?): <http://hosho.ees.hokudai.ac.jp/~kubo/Rdoc/library/RBGL/html/clusteringCoef.…> (taken from RBGL, "An interface to the BOOST graph library" for R) I tried it and it is a fast and probably useful algorithm, assigning a value between 0 and 1 (both included) to each vertex. Actually I'm looking for a way to find remote corners in a graph, and the vertices with 0 calculated by this algorithm are remote (but these can probably also be found other wise) Thanks, Barend

1 0

[Fusion][Parameter] Some unused parameters warning in gcc
by Joel Falcou 05 Jul '10

05 Jul '10

Following files have obnoxious warnings due to unused parameters. Fix is trivial. trunk/boost/fusion/sequence/intrinsic/has_key.hpp line 70 trunk/boost/fusion/algorithm/query/detail/any.hpp line 112 trunk/boost/parameter/aux_/tagged_argument.hpp trunk/boost/parameter/parameters.hpp Will put up trac item+patches soon

1 0

[thread] A few submissions
by Andrey Semashev 05 Jul '10

05 Jul '10

Hi, I would like to propose the following components for inclusion into Boost.Thread: 1. Once-blocks. This is a flavor of the "once" concept. One can define a block of code that should be executed only once, like that: void foo() { BOOST_LOG_ONCE_BLOCK() { puts("Hello, world once!"); } } The code within the block can access names (e.g. variables) as if it was a usual code block. Why not call_once: * The once-code is defined in-place, which greatly simplifies usage in many cases. One of the main goals of the "once" concept is the dynamic initialization, which involves the variables being initialized. With once-blocks there is no need bind these variables into a functor. Once-blocks are also easier to be used within a macro. * The resulting code is much shorter since the thread synchronization code is separated from the once-code. call_once is instantiated with each once-functor, although the synchronization code is the same. * The once-flag is smaller on Windows. In fact, unlike call_once, the behavior on Windows is equivalent to POSIX. * It has ticket #4225 fixed. If this component is accepted, I would also like to port call_once to once-blocks. Source code: <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/libs/…> 2. Lightweight read/write mutex. Basically, I want a portable analogue for pthread_rwlock_t, with minimum dependencies, code size and memory footprint. Naturally, it is compatible with Boost.Thread locks. Why not shared_mutex: * shared_mutex.hpp depends on a lot of other headers. It brings in a great deal of Boost.DateTime, although I don't need the timed methods at all. * It offers more than I ever use. I don't need upgradeability. * It is larger than pthread_rwlock_t on POSIX systems (on Linux x64 it's 192 bytes vs 56). On Windows NT 6 it can be implemented through SRWLOCK, which is of size of one pointer. * I remember there were reports that shared_mutex is slower than pthread_rwlock_t. But I haven't done testing, so I won't press it. Source code: <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/libs/…> 3. Lightweight thread-local storage for small POD values. Allows to store POD values of size up to sizeof(void*) with least possible overhead, memory and performance-vise. thread_specific< int > tls; Why not thread_specific_ptr: * thread_specific_ptr performance depends on the total number of ptrs within the application as it involves an additional lookup among them on access. thread_local does nothing more than abstracting away the native API for TLS, so it provides better performance. * thread_specific_ptr requires to dynamically allocate memory even for tiniest things, like bool or int. This is inconvenient and awkward, especially when memory and exception safety matters. <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/libs/…> A few notes up-front. There are extensions in some compilers for TLS support. It offers even better performance and easier to use. Also, C++0x will bring this feature into the language. But: * It is known to have problems with dynamically-loaded modules. * It is not portable. Even when C++0x it out, not all compilers will support it right away. * thread_specific does not require the variable to have a static storage duration. 4. shared_lock_guard. A light analogue to shared_lock, which allows to generate a more efficient code. Ticket #3567. Source code: <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> As a part of this addition I would like to improve segregation of boost/thread/locks.hpp by extracting every component within it into a separate header in a new "locks" directory. 5. The strictest_lock metafunction. Given the list of lock types, it selects the one that offers the strictest concurrency guarantees (i.e. shared lock is stricter than no lock at all, exclusive lock is stricter than shared lock). This metafunction can be useful in generic code, where the final lock type must be deduced. Source code: <http://boost-log.svn.sourceforge.net/viewvc/boost-log/trunk/boost-log/boost…> I understand that some of these tools might seem specific to my case, but I think they could be useful in general. If any of these tools is accepted into Boost.Thread, the code is not set in stone - namings and implementation details can be changed, if needed. I can do the code transition, write docs and a few tests, if needed. Just let me know if either of these is of interest and whether I am allowed to do so. PS: If you want SVN access to all these things, it is available on the SourceForge: <http://sourceforge.net/scm/?type=svn&group_id=199644>

3 14

Bug Sprint merge from trunk to release branche
by vicente.botet 05 Jul '10

05 Jul '10

Hi maintainers, have you merged the tickets solved in trunk branch during the last Bug Sprint? If not, it will be very kind of you to do this before the release branche is frozen. Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

1 0

Changelog
by David Bellot 04 Jul '10

04 Jul '10

Hi everybody, I'm a new maintainer for ublas and before the deadline on monday, I still have a last question: we made a few changes in ublas for 1.44 and I would like to report them to the boost official changes. However, I don't know where to write my information ? Is there a file or do I have to send an email to the boost release managers ? Cheers, David -- David Bellot, PhD david.bellot(a)gmail.com http://david.bellot.free.fr

2 1

[Docs] Should remove_pointer doc make mention of and link to pointee doc?
by Mostafa 03 Jul '10

03 Jul '10

Hi all, Shouldn't the remove_pointer doc [tinyurl.com/336cmlp] under type_traits library make mention of and link to the pointee doc [http://tinyurl.com/339n3f4]? (I must say that I've been wholly ignorant of the latter in the couple of years that I've been using boost, since I always expected it to be under type_traits.) Additionally, it would be great if it was explained why it's not part of the type_traits library, since, at least I believe, it's not very obvious. One last question, why is pointee under the iterator library docs, when it also deals with shared_ptrs? Shouldn't it fall under the utility doc? (The iterator doc would be the last place I would look if I wanted to find something on shared_ptrs.) Thanks, -Mostafa

2 2

[mpi] Boost.MPI broken
by Jeremiah Willcock 03 Jul '10

03 Jul '10

Almost all of the regression tests for Boost.MPI on the Boost trunk are failing, and this is leading to failures in Boost.Graph.Parallel as well. Is this a known problem? Could someone please work on fixing it? Thank you. -- Jeremiah Willcock

8 15

[BGL] BGL named parameters - how to proceed?
by Daniel Trebbien 02 Jul '10

02 Jul '10

Hello all, I am writing documentation for my implementation of the Stoer–Wagner min-cut algorithm. Attached is an HTML file of what I have so far, which also outlines how I would like the interface of `stoer_wagner_mincut` using named parameters to be. How do I proceed in adding support for BGL named parameters `weight_map`, `parity_map`, `vertex_index_map`, `assignment_map`, `index_in_heap_map`, and `wA_map`? I have looked through sources of other BGL algorithms and am not sure how the named parameters functionality works, let alone how to add it to my code. Daniel

2 2

Query on the Boost Library Support
by Alapkumar Sinha 02 Jul '10

02 Jul '10

Hi, I am analyzing the different IPC mechanism of Boost. Can someone help me with the following queries? 1. Is there something available in boost similar to windows "events". I mean where one thread can wait on one event and another thread signals the event. I was going through Boost.signals2, but it seems more of a function call back. 2. Is there support for FIFO, PIPE & POSIX signals Thanks, Alap ________________________________ This Email may contain confidential or privileged information for the intended recipient (s) If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. ______________________________________________________________________

3 2

spirit mini_c example 1 broken
by Dirk Griffioen 02 Jul '10

02 Jul '10

Hi, (Sorry if this is the wrong list) The mini_c example 1 in Boost.Spirit v2.3 seems to be broken: all I get is a Error! Expecting <statement-list> here: " int a = 2; And with some debugging added it says: <statement-list> <try>\n int a = 2;\n </try> <statement> <try>\n int a = 2;\n </try> <variable-declaration> <try>\n int a = 2;\n </try> <fail/> </variable-declaration> <assignment> <try>\n int a = 2;\n </try> <variable-reference> <try>\n int a = 2;\n </try> <fail/> </variable-reference> <fail/> </assignment> <fail/> </statement> <fail/> </statement-list> Error! Expecting <statement-list> here: " int a = 2; I am a bit confused now, as it is straight from the examples ... and my guess is it should work. Any hints? Best, Dirk

1 0

svn-commit mail failing
by Thomas Heller 02 Jul '10

02 Jul '10

Hi, I just noticed that the svn commit mailing list seems to have some problems. The last commit notification I got was from revision 63466. The current revision is 63522. Can someone confirm?

1 0

[intro] Preview: Introspection library
by Stefan Strasser 02 Jul '10

02 Jul '10

Hi, I'd be interested in comments on an introspection library I've been developing. there has been no "Is there any interest..."-e-mail yet, as it was started out of necessity in "namespace detail" of another library, so you're also welcome to express interest/disinterest in a library like this, without any specific comments. source code: https://svn.boost.org/trac/boost/browser/sandbox/intro/boost/intro/ the library defines a concept that exposes the members of a class, for introspection algorithms to work with. e.g. the "print" algorithm applied to a simple object implementing the concept yields the following results: intro::print(a,std::cout); ---- { A_base = { int member_of_base = 789; }; int a = 123; float b = 456.7; vector<int,class std::allocator<int> > vec = {2, 4, 6, 8, 10}; } --- other algorithms that are currently implemented: - apply_members[_binary]: apply a user-supplied functor to each member - apply_recursive: follow pointers, references, STL container elements, etc. - serialize: serialization of an object tree of 1M objects: 80 ms. Boost.Serialization: 330 ms. serialization of an object graph of 1M objects: 410 ms. Boost.Serialization: 2700 ms. - move: move-construct an object - reset_shared planned or not yet in the sandbox are deserialize, print_recursive, copy_deep, copy_shallow, equal_deep, equal_shallow. an implementation of the concept looks like this: template<class Mapping> friend void introspect(Mapping mapping,type<A>){ mapping (base_class<A_base>() ) (member<A,int ,&A::m_a>() ) (member<A,float ,&A::m_b>() ) (member<A,std::vector<int>,&A::m_vec>()) (); } members can also be associated with tags or data, and can be assigned semantics (e.g. polymorphic, shared/unique for pointers), but I won't go into too much detail for now. Best, Stefan

8 21

[RFC] string inserter/extractor "q u o t i n g"
by Beman Dawes 01 Jul '10

01 Jul '10

This is a request for comments on a delimited string inserter/extractor facility for Boost. The initial motivation is a need for Boost.Filesystem class path inserters and extractors to handle paths with embedded spaces. The problems stems from standard library stream I/O not round-tripping strings with embedded spaces, so a general solution might be of interest. It is a bit surprising that Boost doesn't seem to already have such a utility. The general solution presented here follows very common practice as to the format: strings are enclosed in delimiters on output and the delimiters (if present) are stripped on input. In the external format, an escape character precedes itself or the delimiter character should either be present in the string. The default delimiter character is the double-quote (") and the default escape character is the backslash (\). These defaults can be overridden. Example: const std::string expected("foo\\bar, \" *"); std::cout << delimit(expected); std::string actual; std::stringstream ss; ss << delimit(expected); ss >> undelimit(actual); assert(expected == actual); The output to cout is "foo\\bar, \" *" A prototype is available at http://svn.boost.org/svn/boost/branches/filesystem3/boost/delimit_string.hpp. It is a header only implementation. Do you think this component, with suitable documentation, tests, etc., should become a part of Boost? If so, What library should it be part of? Seems too small to be a library all of its own. Where should the header live? What namespace should it be in? Are delimit() and undelimit() suitable names for the functions? Any other comments? Thanks, --Beman

9 36

Regression tests machines
by Joel Falcou 01 Jul '10

01 Jul '10

I am managing some spare machine with reasonable performances and compiler selection that are basically underused at the moment (including various i64, AMD and PowerPC server blade) with both gcc and icc. I guessed they could be used to run the boost regression test on a dialy or weekly basis. I found out about the : http://www.boost.org/development/running_regression_tests.html page but I wanted to know if there is any speficic need in term of paltofrm/compiler coverage or if I can just run whatever and push the regression result up ?

10 17