- Boost-users - lists.boost.org

RE: [Boost-Users] mpl::for_each
by Aleksey Gurtovoy 30 Dec '02

30 Dec '02

Oleg Grunin wrote: > It would be useful IMHO if mpl::for_each took its functor argument by > reference or better yet, became aware of boost::reference_wrapper. Done, the latter, check out the CVS. Thanks for the suggestion! Aleksey

1 0

Error when I tried to compile an example
by g9news02 <g9news02＠yahoo.com.au> 30 Dec '02

30 Dec '02

Hi all, I tried to compile an example provided with the Boost date time library but kept getting the following error message: "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 23: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 23: Error: BOOST_PP_LIST_FOR_EACH_I_M is not defined. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 23: Error: Use ";" to terminate declarations. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 23: Error: Use ";" to terminate declarations. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 26: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 26: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 26: Warning: Too few arguments in macro BOOST_PP_CHECK_2. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 26: Error: BOOST_PP_LIST_FOR_EACH_I_M is not defined. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 26: Error: Use ";" to terminate declarations. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 26: Error: Use ";" to terminate declarations. "/pssource/current/thirdparty/boost/boost_1_29_0/boost/type_traits/is_void.hpp", line 27: Warning: Too few arguments in macro BOOST_PP_CHECK_2. Does anyone know how to fix the problem. Thanks in advance.

1 0

type_traits/is_convertible crashes Forte 6.2u2 and Forte 7.0
by Robert A. Reece 30 Dec '02

30 Dec '02

I put the following line in a file (it's the only line...) #include <boost/type_traits/is_convertible.hpp> And compiled as such: CC -I$BOOST temp.cpp Under both Forte 6.2u2 (running under Solaris 8) and Forte 7.0 (solaris 9), it produces the following: /hades02/pega/pegdevlcl/work> CC -I$PEGDEV3RD/boost/1.29.0 temp.cpp >> Assertion: (../links/init.cc, line 957) while processing /tsgnt1/pegdevsrc/3rd/src/boost/1.29.0/boost/type_traits/is_convertible.hpp at line 118. Has anybody else seen this? I checked the latest CVS archive and didn't see any updates to this file. The odd thing is that line 118 is blank. Thanks -Rob

2 1

mpl::for_each
by Oleg Grunin 29 Dec '02

29 Dec '02

It would be useful IMHO if mpl::for_each took its functor argument by reference or better yet, became aware of boost::reference_wrapper.

2 1

mpl begin end
by Oleg Grunin 29 Dec '02

29 Dec '02

Since mpl algorithms unlike their stl counterparts take sequences not iterators how does one run them on a subset of a container.

2 1

boost::date_time : iterator model
by klapshin <klapshin＠yahoo.com> 29 Dec '02

29 Dec '02

Hello, I am an a process of adapting our codebase to boost date_time library, and one quite annoying problem I encountered is that date iterators conform to InputIterator model, rather then Random Access Iterator. By the nature of application I have to calculate quite often something like current date plus N months. The only way I see so far is doing something like date d(2002,Dec,26); month_iterator mi(d); for( size_t i=0; i < 5; ++i) ++mi; d = *mi; This is rather awkward, not to mention inefficient. I was trying to search both User and Developers mailing lists for "date InputIterator" hoping to find out what was the reason to use InputIterators, but no luck. BTW, how am I supposed to roll few months back? It is a forward iterator not even a bidirectional. Even more critique: the iterator is not exactly InputIterator, since it has only prefix increment, and no postfix one. Best regards, Kirill Lapshin.

6 8

RE: [Boost-Users] Re: boost::date_time : iterator model
by Jeff Garland 28 Dec '02

28 Dec '02

>However I will try to give it a shot. What is the right >place to take latest source code from? Regular Boost CVS >repository on SourceForge? Yes, the boost CVS repository on sourceforge has the latest source. Jeff

1 0

Property maps / Graph library
by rradh <rradh＠yahoo.com> 25 Dec '02

25 Dec '02

Hi, The examples in libs/graph/example have property_map like vertex_name that associates a 'vertex -> user-defined name' (usually a std::string). Without having to use an external std::map, is there any way to create a property_map that provides the reverse association 'user-defined name -> vertex', so that I can retreive the vertex based on the user-defined name and without iterating thru each vertex. Thanks Rajesh

1 0

[BGL] Simplest way to implement bool isReachable(Vertex src, Vert ex target, Graph g) was: [Boost-Users] Re: Extended use of BGL File Depen dency Example
by Tom Matelich 24 Dec '02

24 Dec '02

> From: Tom Matelich [mailto:tmatelich@zetec.com] > > From: Tom Matelich [mailto:tmatelich@zetec.com] > > From: David Abrahams [mailto:dave@boost-consulting.com] > > > Tom Matelich <tmatelich(a)zetec.com> writes: > > > > From: David Abrahams [mailto:dave@boost-consulting.com] > > > >> Tom Matelich <tmatelich(a)zetec.com> writes: > > > >> > > > >> > trying to make my graphviz representation look nicer and I > > > >> was wondering if > > > >> > there is an algorithm already for simplifying: > > > > > > > > -----B\ > > > > A--< \ > > > > --------C > > > > D----------/ > > > > > > > > to: > > > > > > > > A---B---C > > > > D------/ > > > > > > > > This eliminated the A-C edge. <snip discussion of minimum spanning tree. It won't work because I require all reachability to be maintained. > so here's my psuedo-algorithm: for each vertex V for each out-edge E for each out-edge E_prime (double loop) if(isReachable(target(E_prime), target(E)) remove_edge(E) In other words if one of V's children can reach the target vertex of a given edge, then that edge can be removed. If someone could let me know how to implement bool isReachable(Vertex src, Vertex target, Graph g); I would really appreciate it. Or if you have a better algorithm, I'd love to hear it. Thanks, Tom ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0

RE: [Boost-Users] Re: Extended use of BGL File Dependency Example
by Tom Matelich 23 Dec '02

23 Dec '02

> From: Tom Matelich [mailto:tmatelich@zetec.com] > Sent: Sunday, December 01, 2002 9:11 PM > > From: David Abrahams [mailto:dave@boost-consulting.com] > > Tom Matelich <tmatelich(a)zetec.com> writes: > > > > > From: David Abrahams [mailto:dave@boost-consulting.com] > > > Sent: Sunday, December 01, 2002 5:58 AM > > >> Tom Matelich <tmatelich(a)zetec.com> writes: > > >> > > >> > trying to make my graphviz representation look nicer and I > > >> was wondering if > > >> > there is an algorithm already for simplifying: > > > > > > -----B\ > > > A--< \ > > > --------C > > > D----------/ > > > > > > to: > > > > > > A---B---C > > > D------/ > > > > > > This eliminated the A-C edge. > > > > > > Thanks for considering my problem. > > > > Maybe you want a minimum spanning tree, where the weight of > > each edge in the tree is determined by the distance between its > > vertices in some topological sort? > > > > That seems to solve the cases shown above pretty nicely. > > I had looked at the minimum spanning tree docs a bit, I > thought it looked pretty good. The docs say undirected graph though. I'm > currently using a directed graph. I suppose I could create a separate graph. > Oh, I see, create an undirected graph with weights as you said, and use > the minimum spanning algorithm to choose the useful edges. I like it, > hope it works. > Well, I finally got back to this and it almost worked. Things look a lot nicer, the only problem is some edges were lost that I would want to keep. I'll give a list of edges rather than try to draw ascii graphs. So I start out with edges: [1,0], [2,0], [3,0], [4,0], [3,1], [4,2], [4,3] Ideally I want this reduced to: [1,0], [2,0], [3,1], [4,2], [4,3] What I'm getting is: [1,0], [3,1], [4,2], [4,3] Of course my graph is bigger and I have a lot more dead ends than just at 2. 0 is a place holder I have for a "Valid System", so every thing should hit that eventually. I implemented this in the following manner: [create typedefs for undirected graph to be minimized] [get the order from the topological sort in a vector] [create the undirected graph with all edges from dependency graph, assigning weight to be the distance between source and target in the topological sort] [create a vector of edges called spanning_tree] [call kruskal_minimum_spanning_tree(undirected_graph, std::back_inserter(spanning_tree)); ] [then I recreated the directed graph out of the edges in spanning_tree, so I could have my arrows in graphviz] I'm going to try using prim_minimum_spanning_tree, I assume I should expect the same results, but I'll see. Thanks for any advice, Tom ----------------------------------------------------------------------- DISCLAIMER: Information contained in this message and/or attachment(s) may contain confidential information of Zetec, Inc. If you have received this transmission in error, please notify the sender by return email. -----------------------------------------------------------------------

1 0