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