- Boost - lists.boost.org

[python] Please apply and merge 2208
by Steve M. Robbins 07 Nov '11

07 Nov '11

Hi, The patch has been used in Debian since August 2008 so it should be safe to apply. Thanks, -Steve

1 0

[units] spatial coordinates, vectors, x, y, z, something like that
by Janek Kozicki 06 Nov '11

06 Nov '11

Hi, I want to use boost::units to calculate diffraction & interference patterns and wave propagation in 3D. I need some way to represent points in spatial 3D space with 'length' dimension. What do you guys use for that? I need them to work with 'frequency' & 'speed' dimensions also. Don't tell me that I need to write my own 'vector' class ? best regards -- Janek Kozicki http://janek.kozicki.pl/ |

2 2

Interest in bounded (Top-Bounded) Range adaptor.
by Fernando Pelliccioni 06 Nov '11

06 Nov '11

Is there interest in adding a Top-Bounded adaptor into Boost.Range ? Example: using namespace boost::adaptors; using namespace boost::assign; std::vector<int> input; input += 1,2,3,4,5,6,7,8,9; boost::copy( input | bounded(0), std::ostream_iterator<int>(std::cout, ",")); // prints nothing boost::copy( input | bounded(1), std::ostream_iterator<int>(std::cout, ",")); // prints 1, boost::copy( input | bounded(2), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2, boost::copy( input | bounded(8), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8, The above example is similar in behavior to ... boost::copy_n( input, 0, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 1, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 2, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 8, std::ostream_iterator<int>(std::cout, ",")); The difference is that *copy_n* algorithm doesn't check for begin(range) != end(range) In the following line, an error occurs at runtime... boost::copy_n( input, 9, std::ostream_iterator<int>(std::cout, ",")); Unlike the following that runs ok... boost::copy( input | bounded(9), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8,9, This behavior could be equated using *sliced(0, X)*, but sliced requires *RandomAccessRange*, unlike bounded that requires *SinglePassRange*. *bounded* code is based on *indexed* adaptor code, I think it is more efficient than *sliced* ( that uses *make_iterator_range* --> std::advance ). I don't know if this behavior can be achieved using other adapters, if so, please let me know. Is there interest in this for Boost? Regards, Fernando.

5 12

[parameter] aux_/void.hpp: potential undefined behavior
by Krzysztof Czainski 05 Nov '11

05 Nov '11

Hello, Here's boost/aux_/void.hpp contents, without include quards and license note, where I marked a line with a comment to refer to it below. [code] namespace boost { namespace parameter { // A placemarker for "no argument passed." // MAINTAINER NOTE: Do not make this into a metafunction struct void_ {}; namespace aux { inline void_& void_reference() { static void_ instance; // (1) return instance; } } // namespace aux }} // namespace boost::parameter [/code] My question is: is it allowed to use an instance of an uninitialized empty struct? The struct void_ is empty. On line (1) a static uninitialized instance of struct void_ is defined, and it is then returned. Does the standard allow this? I can't imagine any real problems with this, but I'm curious if this has defined behavior according to the standard. A natural and simple solution to my concern is of course to change the line (1) to: static void_ instance = {}; I'd be happy to create a ticket with a patch, if my concern is valid. Regards, Kris

3 5

[lockfree] review
by Gordon Woodhull 05 Nov '11

05 Nov '11

Hi Tim, Hopefully I'll have at least a partial review. I only know enough about the subject to be a little dangerous. (One course in concurrent data structures, one successfully implemented lockfree hash table - except for the memory reclamation. Unspecified barriers and ABA problems. :p ) Considering the difficulty of the subject, you seem to have carefully chosen a small set of algorithms where at least there is consensus that the sources you are using have solved the problem correctly. I apologize if this has already been covered, but I don't see anything in the documentation about which platforms and compilers this has been tested on. These algorithms are extremely susceptible to compiler and processor optimizations. Anyway, I thought I would try to run the tests, and maybe try changing the testing methodology a little, but I got a few compiler errors, below. Defining uint fixed most of these, but bench_1.cpp also appears to be out of date? Of course I also have my lack of understanding of boost build library linking to contend with. Hope to try again later. Cheers, Gordon ~/lib/boost_lockfree/libs/lockfree/test ~/src/boost-trunk grodo-mcwoohu:test gordon$ bjam ...found 141 targets... ...updating 21 targets... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o g++: unrecognized option '-no-cpp-precomp' bench_1.cpp: In function 'void test_fifo_pop()': bench_1.cpp:67:23: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue(long int*)' ../../../boost/lockfree/fifo.hpp:214:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_fifo_pop_unsafe()': bench_1.cpp:77:30: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue_unsafe(long int*)' ../../../boost/lockfree/fifo.hpp:255:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop()': bench_1.cpp:87:19: error: no matching function for call to 'boost::lockfree::stack<long int>::pop(long int*)' ../../../boost/lockfree/stack.hpp:179:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop_unsafe()': bench_1.cpp:97:26: error: no matching function for call to 'boost::lockfree::stack<long int>::pop_unsafe(long int*)' ../../../boost/lockfree/stack.hpp:207:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o" "bench_1.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1 for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.run for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o g++: unrecognized option '-no-cpp-precomp' fifo_test.cpp:103:18: error: 'uint' does not name a type fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::add()': fifo_test.cpp:116:14: error: 'uint' was not declared in this scope fifo_test.cpp:116:19: error: expected ';' before 'i' fifo_test.cpp:116:26: error: 'i' was not declared in this scope fifo_test.cpp:116:31: error: 'nodes_per_thread' was not declared in this scope fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::run()': fifo_test.cpp:187:1: error: 'nodes_per_thread' was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o" "fifo_test.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.run for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test... darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test ld: library not found for -lboost_thread collect2: ld returned 1 exit status "g++" -o "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test" "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test.o" -lboost_thread -lboost_unit_test_framework -g ...failed darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test... ...skipped <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test.run for lack of <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/ringbuffer_test.test/darwin-4.5.3/debug/threading-multi/ringbuffer_test.o g++: unrecognized option '-no-cpp-precomp' ringbuffer_test.cpp:209:14: error: 'uint' does not name a type ringbuffer_test.cpp: In member function 'void ringbuffer_tester::add()': ringbuffer_test.cpp:225:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:225:19: error: expected ';' before 'i' ringbuffer_test.cpp:225:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:225:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester::run()': ringbuffer_test.cpp:284:1: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::add()': ringbuffer_test.cpp:315:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:315:19: error: expected ';' before 'i' ringbuffer_test.cpp:315:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:315:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::run()': ringbuffer_test.cpp:386:1: error: 'nodes_per_thread' was not declared in this scope

8 63

Re: [boost] [lockfree] review
by Boehm, Hans 05 Nov '11

05 Nov '11

[Dave Abrahams pointed me at this thread.] Alexander Terekhov <terekhov <at> web.de> writes: > > Dave Abrahams wrote: > > > > on Thu Aug 25 2011, Alexander Terekhov <terekhov-AT-web.de> wrote: > > > > > Ilya Sokolov wrote: > > >> > > >> > > >> AFAIK, in the example above another thread can't observe reordering > > >> without introducing UB. > > > > > > I meant "observed" as in "check the sequence of writes in the generated > > > code". > > > > Do we care about what the generated code looks like? IIUC what counts > > is the sequence of memory states that another another thread can see. > > > > > But int can be simply changed to relaxed atomic<int> so that another > > > thread can observe reordering without UB. > > > > Sure. > > I meant that for the example upthread, with an int instead of relaxed > atomic<int>, another thread's code triggering UB does not prevent us > from observing reordered writes in the writing thread's code (in > generated code), by looking at it. > > Changing int to relaxed atomic<int> simply removes UB but does not > change the relevant code in the writing thread. > > regards, > alexander. > I agree with Alexander and most of the recent postings. If I write mx.lock(); x = 1; mx.unlock(); my.lock(); y = 1; my.unlock(); There is nothing to prevent the stores to x and y from becoming visible out of order at the hardware level. Enforcing ordering here would add needless and substantial cost. But a data-race-free program cannot observe such reordering. (One reference for that is Sarita Adve's and my PLDI 08 paper. Unofficial TR version at http://www.hpl.hp.com/techreports/2008/HPL-2008- 56.html. I believe Mark Batty et al have a much more complete and formal proof.) If we change x and y to be atomic variables, and the stores to be memory_order_relaxed, then an observer can tell the difference. I.e. if x and y are initially zero, and another thread does r1 = y; r2 = x; (or the acquire versions), it can see r1 = 1 and r2 = 0, since there are no synchronizes-with relationships between threads, and thus nothing to enforce ordering. If you use memory_order_relaxed, or even the acquire/release forms, things do get MUCH more complicated. The equivalent rules for other languages are an interesting story. I believe Posix implentors assume the above rules. I have a PPoPP 2007 paper that explains why that's not exactly what Posix actually states. OpenMP 3.0 has stricter rules which are also not consistently obeyed, and are somewhat fixed in OpenMP 3.1. (See my MSPC 11 paper for some details.) Java has arguably the same rules as C++ in this respect. In my mind, the main way in which sequential consistency differs from the cheaper acquire/release semantics that Alexander wants is that a) Dekker's algorithm (which by itself isn't that practically interesting), plus a number of real lock-free algorithms (which do matter) don't work. b) In my mind, acquire/release is a far more difficult model to explain to non- experts than the model for C++ with only sequentially consistent atomics. You can no longer reason about interleaving thread actions, either for purposes of determining the existence of a data-race, nor when defining what data-race- free programs mean. This was extensively discussed in C++ meetings starting in about 2005. The current solution with default-sequentially-consistent atomics, but explicit support for weaker ordering, was the resulting committee compromise. Hans

6 19

Determining interest in Delegates submission
by Jared McKee 05 Nov '11

05 Nov '11

I would like to determine interest in a possible library submission. I have written some code which converts a member function and object pointer combination to a free function for use in C style callbacks. It has some limitations which I will describe shortly. The basic idea is to be able to convert: R (B::*)(T0,T1,…) and B* to R (*)(T0,T1,…) Here's an example usage: class foo { int x; int test(int v) {return x + v;} }; foo* a = new foo; a->x = 3; int (*f)(int) = delegate(a, &foo::inc); cout << f(4) << endl; // outputs "7" When I first attempted this I used a technique where I allocated some executable memory in the heap and dynamically created a free function to call the member function for the instance. It was fun attempting that but, as you can imagine, as soon as I used the optimizer flags on my compiler I would get segment faults :) My second approach was to use templates and the Boost Preprocessor library to create appropriate static arrays of pointers to free functions matching the required signatures and then hand those pointers out each time the delegate() function is called. The two downsides to this are: you can only call delegate() for a certain function signature a limited number of times, and it adds a lot of potentially unused code to your executable. Here's the code (I've stripped out error checking for the sake of illustration): #include <boost/preprocessor.hpp> #ifndef _delegate_h_ #define _delegate_h_ #define MAX_DELEGATES 256 #define DELEGATE_PARAMS 0 #include "delegate_template.hpp" #undef DELEGATE_PARAMS #define DELEGATE_PARAMS 1 #include "delegate_template.hpp" #undef DELEGATE_PARAMS // … #endif // delegate_template.hpp #define DELEGATE_STORE BOOST_PP_CAT(DELEGATE_STORE,**DELEGATE_PARAMS) template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > struct DELEGATE_STORE { typedef B* objectPointer; typedef R (B::*memberFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); typedef R (*freeFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); static int delegateCount; static int delegateMax; static objectPointer delegateObjectPointer[MAX_**DELEGATES]; static memberFunction delegateMemberFunction[MAX_**DELEGATES]; template <int i> static R func( BOOST_PP_ENUM_BINARY_PARAMS(**DELEGATE_PARAMS, T, v) ) { return (delegateObjectPointer[i]->***delegateMemberFunction[i])( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, v) ); } static const freeFunction delegateFreeFunction[MAX_**DELEGATES]; static freeFunction getDelegate(objectPointer o, memberFunction m) { int delegateIndex = delegateCount++; delegateObjectPointer[**delegateIndex] = o; delegateMemberFunction[**delegateIndex] = m; return delegateFreeFunction[**delegateIndex]; } }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateCount = 0; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateMax = MAX_DELEGATES; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::memberFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateMemberFunction[MAX_**DELEGATES] = {0}; > template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::objectPointer DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateObjectPointer[MAX_**DELEGATES] = {0}; > #define FUNC_POINTER(z, n, params) &DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::template func< n >, template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > const typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::freeFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateFreeFunction[MAX_**DELEGATES] = { > BOOST_PP_REPEAT(MAX_DELEGATES, FUNC_POINTER,) }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > R (*delegate( B* b, R (B::*f)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) ))( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) { return DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::getDelegate(b, f); } // end Thankyou very much if you managed to read all the way to here! By the way, this is my first active participation in any open source project :) Jared

3 5

[BGL] map_as_graph.hpp
by Shaun Jackman 04 Nov '11

04 Nov '11

Hi, In the spirit of vector_as_graph.hpp, I created map_as_graph.hpp. One useful feature is that the vertex_descriptor can be any user-defined type, such as a string or an arbitrary object. It's not in a form that's ready to be included in Boost, but I have found it occasionally useful. I though I'd post it in the case that someone else found it useful. If someone found it useful enough that he or she where interested in further developing to the point where it could be included in Boost, please be my guest. Cheers, Shaun #ifndef MAP_AS_GRAPH_HPP #define MAP_AS_GRAPH_HPP 1 #include <boost/graph/graph_traits.hpp> #include <cassert> #include <map> #include <utility> // for make_pair namespace boost { /** * A std::map is a model of a directed graph. * @author Shaun Jackman <sjackman(a)gmail.com> */ template <typename V, typename T> struct graph_traits<std::map<V, T> > { // Graph typedef V vertex_descriptor; typedef boost::directed_tag directed_category; struct traversal_category : boost::adjacency_graph_tag, boost::vertex_list_graph_tag { }; typedef boost::disallow_parallel_edge_tag edge_parallel_category; // IncidenceGraph typedef std::pair<vertex_descriptor, vertex_descriptor> edge_descriptor; typedef size_t degree_size_type; /** Iterate through the out edges of a vertex. */ struct out_edge_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; out_edge_iterator(const It& it, vertex_descriptor src) : It(it), m_src(src) { } edge_descriptor operator*() const { return edge_descriptor(m_src, It::operator*().first); } private: vertex_descriptor m_src; }; // BidirectionalGraph typedef void in_edge_iterator; // AdjacencyGraph /** Iterate through the adjacent vertices of a vertex. */ struct adjacency_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; adjacency_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; // VertexListGraph /** Iterate through the vertices of this graph. */ struct vertex_iterator : std::map<V, T>::const_iterator { typedef typename std::map<V, T>::const_iterator It; vertex_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; typedef size_t vertices_size_type; // EdgeListGraph typedef void edge_iterator; typedef void edges_size_type; }; // graph_traits<std::map> // IncidenceGraph template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::out_edge_iterator, typename graph_traits<std::map<V, T> >::out_edge_iterator> out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typedef typename graph_traits<std::map<V, T> >::out_edge_iterator out_edge_iterator; typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair( out_edge_iterator(it->second.begin(), u), out_edge_iterator(it->second.end(), u)); } template <typename V, typename T> typename graph_traits<std::map<V, T> >::degree_size_type out_degree( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return it->second.size(); } // AdjacencyGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::adjacency_iterator, typename graph_traits<std::map<V, T> >::adjacency_iterator> adjacent_vertices( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair(it->second.begin(), it->second.end()); } // VertexListGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::vertex_iterator, typename graph_traits<std::map<V, T> >::vertex_iterator> vertices(const std::map<V, T>& g) { return make_pair(g.begin(), g.end()); } // AdjacencyMatrix template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); return std::make_pair(make_pair(u, v), it == g.end() ? false : it->second.count(v) > 0); } // VertexMutableGraph template <typename V, typename T> void remove_vertex( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { size_t n = g.erase(u); assert(n == 1); (void)n; } // EdgeMutableGraph template <typename V, typename T> void clear_out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { typename std::map<V, T>::iterator it = g.find(u); assert(it != g.end()); it->second.clear(); } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename edge_property<std::map<V, T> >::type ep; return make_pair(std::make_pair(u, v), g[u].insert(make_pair(v, ep)).second); } template <typename V, typename T> void remove_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { size_t n = g[u].erase(v); assert(n == 1); (void)n; } // PropertyGraph template <typename V, typename T> no_property get(vertex_bundle_t, const std::map<V, T>&, typename graph_traits<std::map<V, T> >::vertex_descriptor) { return no_property(); } template <typename V, typename T> const typename T::mapped_type& get(edge_bundle_t, const std::map<V, T>& g, typename graph_traits<std::map<V, T> >::edge_descriptor e) { typename std::map<V, T>::const_iterator u = g.find(source(e, g)); assert(u != g.end()); typename T::const_iterator v = u->second.find(target(e, g)); assert(v != u->second.end()); return v->second; } // MutablePropertyGraph namespace boost { template <typename V, typename T> class vertex_property<std::map<V, T> > { public: typedef no_property type; }; template <typename V, typename T> class edge_property<std::map<V, T> > { public: typedef typename T::mapped_type type; }; } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, typename edge_property<std::map<V, T> >::type ep, std::map<V, T>& g) { return make_pair(std::make_pair(u, v), g[u].insert(std::make_pair(v, ep)).second); } } // namespace boost #endif

1 0

Remembering that T(a) can cause dangerous conversion like a C-style cast
by Kazutoshi Satoda 04 Nov '11

04 Nov '11

An essential question: Should boost::lambda::constructor<int>()("") compiles? It does compile with Boost 1.47.0 . But I think it shouldn't. I have crafted a general replacement of T(a) as a workaround for dangerous conversions caused by T(a) which may happen in some kinds of templates. http://ideone.com/iZE1Z unary_initialized<T>(a).value And I thought of that the above workaround (or something similar) may be suitable to be provided within boost::initialized . Now I want to share the idea and to hear interests or evaluations in the community about such extension and underlying issues, before starting further acts. Here is the background story: A while ago, I had a conversation about dangerous conversion that can be caused by the following expression with variadic templates in C++11. T(std::forward<Args>(args)...) This expression is meant to obtain a prvalue of type T which is direct initialized from any given argument list. But if a single argument was given, this becomes T(std::forward<Arg>(arg)) and further, for example, may become int("") and compiles as reinterpret_cast which is likely unexpected. Here is a relevant quote from the standard 5.2.3 p1: > ... If the expression list is a single expression, the type conversion > expression is equivalent (in definedness, and if defined in meaning) to > the corresponding cast expression (5.4). ... (Note: 5.2.3 describes the behavior of T(a), and 5.4 describes the behavior of (T)a.) To avoid the unexpected conversion, I first proposed use of T{...} . But it is not a perfect solution because it changes the meaning in some cases like std::vector<int> . After that, I crafted a tricky workaround. http://ideone.com/FLoDk pack_initialized<T>(std::forward<Args>(args)...).value The above story was about C++11. But it revealed that similar dangerous conversion can be also formed in C++98, C++03 as T(a) in some kinds of templates. Searching in the boost directory (trunk r75213), I found some occurrences of the problem: boost/lambda/construct.hpp:37: http://www.boost.org/doc/libs/1_47_0/boost/lambda/construct.hpp return T(a1); boost/xpressive/regex_actions.hpp:632: http://www.boost.org/doc/libs/1_47_0/boost/xpressive/regex_actions.hpp return T(a0); As shown in the top of this message, I picked boost::lambda::constructor as a concrete example, and verified that the problem really exists in the wild. Thinking more, I wonder why such dangerous conversion was explicitly injected to T(a) in the first place. I first thought of some C-compatibility issues. But now I think it cannot be, because T(a) is a new construct in C++. Is it possible to remove this dangerous conversion path in a future revision of the standard? Perhaps I should go to comp.std.c++ about the last question. -- k_satoda

2 2

[release][1.48] Several merge requests
by Daniel James 04 Nov '11

04 Nov '11

Hi, Please can I merge the following changes: This prevents standard containers from being forward declared for gcc's 'profile' mode: https://svn.boost.org/trac/boost/changeset/75016 Trivial change to improve a couple of quickbook warnings (obviously not vital, but simple enough): https://svn.boost.org/trac/boost/changeset/75088 In unordered, avoid using a name that clashes with a macro defined by a header included from ASIO: https://svn.boost.org/trac/boost/changeset/75123 Missing html redirect, fixes some links to Boost.Move (documentation change): https://svn.boost.org/trac/boost/changeset/75141 Unordered wasn't working on gcc 4.7 in c++0x mode because of changes to std::pair's constructor. Unfortunately, the gcc 4.7 tester hasn't run since this change and I don't have access to it, so I haven't verified that it fixes the problem. But it does work fine on everything it has been tested with. https://svn.boost.org/trac/boost/changeset/75158 This stops using a hack on Visual C++ which was breaking for certain versions (although it didn't show up on any tester). But this is moving from a hacky implementation to a slightly less capable but more reliable implementation, so I think it's a good change regardless. https://svn.boost.org/trac/boost/changeset/75167 thanks, Daniel

2 1