- Boost - lists.preview.boost.org

[quickbook] Question about macros and templates
by Andrey Semashev 09 Jul '10

09 Jul '10

Hi, I'm writing docs in quickbook and stumbled upon a problem. I have this document structure: main.qbk [include a.qbk] [include b.qbk] [include c.qbk] [include x.qbk] [include y.qbk] [include z.qbk] [xinclude r.xml] In files a, b and c I define macros that would unfold into headerref, classref, etc. for the items described in the auto-generated r.xml Reference. I want to use these macros in x, y and z, both in text and code samples. The problem is that, it seems, quickbook doesn't unfold these macros in x, y and z. My guess is that the scope of the macros is limited to the files they are defined in. Is that true? I tried to do the same with templates. It seems that templates are visible in x, y and z, but still are not unfolded in code samples. Is there a way around this problem? Thanks.

2 2

Python port development
by Vladimir Prus 09 Jul '10

09 Jul '10

Hi, as many here probably know, the strategic direction for Boost.Build is the use of Python as implementation language, which should bring a lot of benefits. For more detailed rationale, see: https://trac.lvk.cs.msu.su/boost.build/wiki/PythonPort The port has got so far as to build "hello, world" with gcc, but then stalled. Fortunately, my employer, CodeSourcery, has a sabbatical program, and completing a Python port of Boost.Build was approved as the goal of my own sabbatical. I'll have 4 almost-full-time weeks, starting next Monday, Jule 12. Of course, I'll be asking for feedback, so don't be surprised when I start to post design questions. Thanks, -- Vladimir Prus http://vladimir_prus.blogspot.com Boost.Build: http://boost.org/boost-build2

3 2

Vault: `BGL` directory
by Daniel Trebbien 08 Jul '10

08 Jul '10

Would someone please delete the `BGL` directory on the Vault? I created it before I found the more-suitable `Algorithms/graph` directory.

1 0

[python] boost-1.44 apply patch br#3843
by Neal Becker 08 Jul '10

08 Jul '10

I'd like to see this patch applied for 1.44. Seems pretty harmless. The purpose is so that BOOST_PYTHON_MODULE macro will expand it's arguments, so that this code will work: #define MY_NAME BOOST_PP_CAT(ldpc_,SIMCASE) BOOST_PYTHON_MODULE(MY_NAME) {... https://svn.boost.org/trac/boost/attachment/ticket/3843/boost_python_module…

2 1

Re: [boost] Maintenance NOT suspended
by Christophe Henry 08 Jul '10

08 Jul '10

>I hereby apologize to the community for my earlier announcement and request that you accept a retraction Thanks for taking this courageous decision! >> So, concretely, what is the problem? Do you have no time handling the >> feature requests or is svn the problem? > >I'll prepare a proper response to these questions in a separate message, but I wanted to head off any damage immediately. As I made the suggestion, count me in. After you explain what you need, hopefully more will volunteer. Regards, Christophe

1 0

[thread][VS2010] shared_mutex woo's
by Hartmut Kaiser 08 Jul '10

08 Jul '10

This: #include <boost/thread.hpp> int main() { boost::shared_mutex mtx; boost::upgrade_lock<boost::shared_mutex> l(mtx); boost::upgrade_to_unique_lock<boost::shared_mutex> ul(l); return 0; } still fails on VC21010. Defining BOOST_NO_RVALUE_REFERENCES makes this compile, though. Regards Hartmut --------------- Meet me at BoostCon www.boostcon.com

3 3

[Fusion] Permission to update release branch and roll in dependencies
by Tobias Schwinger 08 Jul '10

08 Jul '10

Dear release team, we're about to freeze the next release. I'd like to kindly ask for your permission to address the issues discussed in this thread http://thread.gmane.org/gmane.comp.lib.boost.devel/198532/ before it's too late, again. Reportedly the outdated files do - other than hoped in that thread - NOT work anymore - and neither do the new and documented ones for the lack of dependencies. So, what I'd like to do is: o merge trunk changes into the Functional module of Fusion o add Forward o optionally add Factory Please check the new mini libraries for "release compliance" and give me a go on the fix. Would be too bad to go with a partially defunct Fusion in two releases for bureaucratic reasons. Please also note that rolling back to a proper previous version might involve more changes and will complicate future merges for us. Regards, Tobias

6 8

Name conflict: boost/range/adaptor/replaced.hpp and boost/algorithm/string/replace.hpp
by Jeremy Maitin-Shepard 08 Jul '10

08 Jul '10

I found that these two header files (the second one being required indirectly by including boost/exception/all.hpp) cannot be used together, because they both attempt to bring a definition of replace_range into the boost namespace. This is with boost-1.43.

1 0

boost.atomic library works on Linux but not on Windows -- please help
by Anqing Xu 07 Jul '10

07 Jul '10

Hi, In search of a std:atomic<T> implementation, I decided to give boost.atomic library a try. My initial investigation found it worked fine under linux. However it does not work on Windows. Here is a little test program to demonstrate: #include <iostream> #include <boost/atomic.hpp> #include <boost/lockfree/detail/tagged_ptr.hpp> #include <boost/lockfree/detail/freelist.hpp> int main() { boost::lockfree::caching_freelist<int> pool(3); int* pInt1 = pool.allocate(); *pInt1 = 1; int* pInt2 = pool.allocate(); *pInt2 = 2; int* pInt3 = pool.allocate(); *pInt3 = 3; pool.deallocate(pInt1); pool.deallocate(pInt2); pool.deallocate(pInt3); int* pInt4 = pool.allocate(); int* pInt5 = pool.allocate(); int* pInt6 = pool.allocate(); } The test uses boost.lockfree library, which you can download from http://tim.klingt.org/git?p=boost_lockfree.git If you set a break point, say in fallback.hpp, you will see that on Windows it falls back to spinlock. Can somebody please suggest how to fix this? I suspect the issue has something to do with intptr_t type. I looked into the code but quickly started to have headache. Atomic library uses template metaprogramming and is not easy to understand. -Anqing

1 0

[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