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

Re: [boost] Please don't define a fake"operator<"just for ordered containers
by Sean Parent 15 Jul '06

15 Jul '06

> I think I have a basic understanding of your logic, but let's think > about > practicality for a moment. I'm not saying logical and philosophical > reasons > are not appropriate for this discussion, but let's try and not > think about > them for a second. I haven't heard mathematics described as "philosophical reasons" but okay. > The ordering defined by the operator< overload for shared_ptr has the > following important property: it is independent of shared_ptr's > template > parameter. You can order shared_ptr<void> objects, if you like. Or, a > shared_ptr<void> and a shared_ptr<int>. I understand, total ordering is important and useful. The question is, what are the semantics of operator < ? If we fail to establish such principals then generic programming is a futile exercise. A generic algorithm is a theorem - it's correctness depends on a collection of semantic requirements (Concepts), these are the axioms for the theorem. Does it matter if share_ptr provides an operator <? No, but it isn't useful for generic code unless such an operation is tied to semantics which are generally accepted. T* does not provide such an operator < and I see no semantic difference between the two. The two should be consistent - I don't really much care which way we go but there are important semantics at play here for operator <. Specifically we're pinning down whether operator < should or should not guarantee a stable ordering across executions of the application. We can say that the C and C++ standard got the rules for T* wrong and lobby to change them, or that shared_ptr<> shouldn't have a less than operator. We might even still provide it under the claim that it shouldn't be defined but is so that std::less<> will work consistently with T* (assuming you don't want to just specialize std::less<> - which I think would be a better solution). Since we can't reasonably check semantic requirements, it is important for code correctness that we associate the requirements with the name of the operation. The signature is the only thing I can check. > Can you think of any problems that operator< could cause, in its > current > definition? In my mind, since you can't use T in your ordering > semantics, > you have no reasons to define your own ordering for shared_ptr. > Therefore, > you have no other use for operator<, and therefore if the one > defined by the > library causes no problems, we should keep it because it is practical. Not any realistic one - in general providing such an operator only breaks concept checks (when we are able to check if a function exists). But without consistent semantics it also doesn't allow me to develop any useful algorithms which rely on this. ----- > > Christoph Ludwig posted the correct reason why std::complex should > > not have an operator < () defined - sorry, my follow up using > > addition was poorly constructed. > > > > What I am proposing is that std::less should be defined for > > std::complex. > > Disagree. That could potentially break other template programming > using std::less, to support std::unary_negate etc. Suddenly this would > "work" for std::complex, when it shouldn't. Allowing code which otherwise would not be allowed is hardly breaking anything. I can see the argument that std::less<> should also be consistent with other operators. I think it is then important to define a general total order operation for this case and develop the rules. Please propose a set of rules for when operator<() should and should not be defined. > > Why would we have a separate default relation for set/map then > > std::less? std::less is intended to map to operator <() on the type > > _or_ to a total ordering for the type if operator <() is not > > defined. > > No, that's just for pointers. 20.5.7/8 says: > > "For templates greater, less, greater_equal, and less_equal, the > specializations for any pointer type yield a total > order, even if the built-in operators <, >, <=, >= do not." > > It doesn't mention std::complex or any other composite types. That still doesn't answer the question of why have another relation for set/map then std::less? And as for the intent for STL I can assure you that the intent of the designer was std::less was intended to provide a total ordering on all types. That standard also does not prohibit us from specializing std::less for use defined types. > > For pair<shared_ptr<>, int> - what makes shared_ptr special? > > The fact that it is a pointer? I don't care much if it doesn't have an > ordering. Then it shouldn't be different from T*. > > > > std::less is supposed to be operator <, unless operator < is not > > defined in which case std::less provides a total ordering. It isn't > > ambiguous. > > Where does the standard say that? I have the advantage of having Alex Stepanov on my team. I asked him. > If you want to have an ordered collection of otherwise unordered data, > the relation must be an application specific attribute. So define an > appropriate functor, and use that with std::map, etc. If we want to introduce a third (or more) way to define a standard ordering other than operator <, std::less I'm fine with that. Just specify the semantics of them. ---- > That is also how I interpret his intent based on what is currently > in the > standard, and that is why I maintain that *under the current > standard*, the > appropriate way to make a type ordered (even if only for the > associatives) > is via defining operator<. If we do this for shared_ptr it should be with a clear statement that we expect the rules for T* should be changed (or consider T* to be a legacy exception which cannot be changed). > > Why would we have a separate default relation for set/map then > > std::less? > > and: > > > As for what I expect std::greater<> et al. to do - I had that in my > > earlier 6 point note - they _better_ be defined consistently with > > std::less. > > If the standard was written with this in mind, greater<>, > less_equal<> and > greater_equal<> would have been defined in terms of less<>. It is not > reasonable to provide four customization points that the user is > supposed to > keep in sync. For me the fact that less_equal returns x <= y is strong > evidence that it is not supposed to be a customization point, but a > function > object alias of operator<=. You can make the same arguments that operator < is not intended to be a customization point because the compiler doesn't automatically provide a consistent >, >=, <= (and == and !=). The standard is a legacy that must be dealt with - this should be done by providing a consistent set of rules and then lobbying for how the standard should change to be compliant. Ideally the rules should be as consistent with the standard as possible, but the important thing is that we are always striving for a correct solution. > > For pair<shared_ptr<>, int> - what makes shared_ptr special? > > Why should it be special? If a type K is ordered, pair<K, int> > should also > be. That isn't true for T*. I contend that either both should have operator < () defined or neither. I believe for shared_ptr is is probably best to try to be consistent with T* then to lobby to get T* changed. Note that this likely still means that you want to define std::less on pair<> to be less of each of the elements. Either way, the standard is flawed. Sean

3 2

Re: [boost] [BGL] Add edge with vertex' properties instead ofvertex descriptors
by Wang Weiwei 15 Jul '06

15 Jul '06

> >On Jul 14, 2006, at 10:54 AM, Wang Weiwei wrote: > >> Hello, >> >> I have a graph type as follows: >> >> namespace boost >> { >> enum vertex_flag_t { vertex_flag = 111 }; >> BOOST_INSTALL_PROPERTY(vertex, flag); >> } >> >> typedef boost::adjacency_list<boost::vecS, boost::vecS, >> boost::undirectedS, >> property<vertex_name_t, std::string, >> property<vertex_flag_t, bool, >> property<vertex_color_t, default_color_type> > >, >> no_property> graph_t; >> >> graph_t g; >> >> That means I want to associate a string as name, a flag, and a >> default color to each vertex of my graph, >> now I want to add edges to my graph directly using the vertex' >> properties instead of their descriptors, >> e.g. >> >> boost::add_edge("vertex1", "vertex2", g); >> >> How can I accomplish this? > >You'll need to create a separate mapping from vertex names to vertex >descriptors: > > std::map<std::string, graph_t::vertex_descriptor> name_to_vertex; > > Doug I've made the following template function to do the jod I want, as indicated by its name - add vertices using their properties. template<typename InputPropIterator, typename Graph, typename VertexPropMap> //// AddVerticesByProp(InputPropIterator first, InputPropIterator last, Graph& g, VertexPropMap& pmap, //// typename std::map< typename std::iterator_traits<InputPropIterator>::value_type, typename boost::graph_traits<Graph>::vertex_descriptor >& Prop2VertexMap) { typedef boost::graph_traits<Graph>::vertex_descriptor vertex_t; typedef std::iterator_traits<InputPropIterator>::value_type prop_t; typedef std::map<prop_t, vertex_t> prop_vertex_map_t; for(; first != last; ++last) { prop_vertex_map_t::iterator pos; bool inserted; vertex_t v; boost::tie(pos, inserted) = Prop2VertexMap.insert(std::make_pair(*first, vertex_t())); if(inserted) { v = add_vertex(g); pmap[v] = *first; pos->second = v; } else { v = pos->second; } } } I suppose it could more elegant if one can remove the template param 'VertexPropMap' and the corresponding function param 'VertexPropMap& pmap', because the type 'VertexPropMap' is determined and should be derived (I think) if the other 2 types are given. To be clearer, the VertexPropMap is a map from 'typename std::iterator_traits<InputIterator>::value_type' to 'typename boost::graph_traits<Graph>::vertex_descriptor'. Similarly, as far as internal property map is concerned, the function param 'pmap' is also determined and should be derived (I think) from 'g' and type info gien by the InputPropIterator. What I need now is any help that can eliminate these 2 param's to make the funtion interface not so tedious. Thanks. Max

1 0

Interest? Virtual preprocessor functions and more
by Matt Calabrese 15 Jul '06

15 Jul '06

This email actually introduces a few different concepts, so at least skim the following paragraphs if the first couple of topics don't capture your interest. As a summary, I am introducing manipulatable preprocessor function and function template descriptions, a macro which automatically generates a "result" template for use with result_of that does not rely of typeof (based off of such function descriptions), the possibilty of macros which use function descriptions to generate tempalte metafunctions which can yield if a function object call is ambiguous or if there is no match for provided parameter types, and finally an "object" concept for preprocessor metaprogramming which allows for simulation of "virtual" or "overloaded" macros which could potentially be used to join Boost.Preprocessor containers by "overloaded" macros, allowing for fewer named preprocessor macros exposed to the user and opens the possibilty up for more generic preprocessor algorithms. _____ Preprocessor function descriptions: While developing my current library, I had to come up with a way to describe functions, member functions, function templates, and member functions in such away that they could be examined and manipulated easily by the preprocessor, ideally all with the same generic code. Such descriptions contain named template parameters in the case of a template, a specifier, a return type, named function parameters, and a qualifier in the case of member functions. Using macros, programmers can then easily change the name of the function, change the return type, transform paramters in order to change their types and/or name, and automatically generate function headers. First, is there any interest for such macros outside of use from my library. For clarity, usage is as such: // where int isthe return type, test is the name, float left is the first parameter, and float right is the second parameter #define A_FUNCTION BOOST_FUN( (int), test, ((float),left)((double),right) ) BOOST_FUN_IMPL_HEADER( A_FUNCTION ) { return static_cast< int >( left + right ); } Uses for this primarily include things such as automatic creation of forwarding functions which may alter parameter types, but also allow for several more interesting applications. ___________ That brings me to perhaps a more common use. Using this little sublibrary of functions, I am making a result template generator for function objects which allows a user to very easily create a result metafunction which is automatically defined, without the need for typeof. For instance: struct fun_obj { BOOST_RESULT( ( BOOST_MEM_FUN( (int), operator (), ((float),left)((double),right) ) ) ( BOOST_CONST_MEM_FUN( (int), operator (), ((float),left)((double),right) ) ) ( BOOST_MEM_FUN_T( ((typename),L)((typename),R), (float), operator (), ((L),left)((R),right) ) ) ) // rest of object body }; // result is equal to float typedef result_of< fun_obj( float, float ) >::type result; ____________ Going further, a macro could easily be created which also produces a metafunction that tells you if a function object call is ambiguous, and a macro could be created which produces a metafunction which tells you if a function object call has no matches for the provided argument types. Such metafunctions could potentially improve error reporting, particularly for forwarding functions. ___________ Finally, if none of that is of immediate interest, the underlying mechanism for all of this may be. What I do in order to get polymorphic behavior for different kinds of functions (normal functions, member functions, and templates), is I use a form of object system. The concept is simple, but is applicable to a large amount of areas in preprocessor metaprogramming, and I offer it as a potential fundamental change to the way Boost.Preprocessor is interfaced with by simulating macro overloading, allowing for fewer named functions but with the same functionality and for more simple creation of generic preprocessor algorithms. The concept is simply this: An object is represented by the form ( OBJECT_ID, (object_data) ) Where OBJECT_ID is a unique "type" for the object and object_data is the internal implementation fo the container. The way it works is you "construct" an object by calling a macro which takes in the data and assembles it into the object representation just described, then, internally when calling overloaded" macros arguments are forwarded to a macro which internally concatenates the function name to the OBJECT_ID and forwards the arguments once more along with the internal representation of the object. The result is a seemingly "overloaded" or "virtual" macro. As an example of how this could be extremely useful for Boost.Preprocessor is it allows for an easy way to represent consistent container concepts. For instance, as Boost.Preprocessor stands, common container operations for arrays and sequences use different names, making it difficult to work with containers generically as you would in the STL or even in MPL. However, this could all be changed, and done so by merely building on top of code that is already there. As an example, here is a BOOST_PP_FRONT macro that works with either BOOST_PP_ARRAYs or BOOST_PP_SEQs (and could be easily be made to work with lists as well). // Seq constructor #define BOOST_PP_SEQ( seq ) ( BOOST_PP_SEQ_OBJ, (seq) ) // Seq FRONT implementation #define BOOST_PP_SEQ_OBJ_FRONT( seq ) BOOST_PP_SEQ_HEAD( seq ) // Array constructor #define BOOST_PP_ARRAY( size, tuple ) ( BOOST_PP_ARRAY_OBJ, ((size,tuple)) ) // Array FRONT implementation #define BOOST_PP_ARRAY_OBJ_FRONT( array ) BOOST_PP_ARRAY_ELEM( 0, array ) // FRONT implementation #define BOOST_PP_FRONT( obj ) BOOST_PP_NULLARY_VFUN( obj, FRONT ) // And here is how the code is used: #define SOME_ARRAY BOOST_PP_ARRAY( 5, (a,b,c,d,e) ) #define SOME_SEQ BOOST_PP_SEQ( (a)(b)(c)(d)(e) ) int main() { // int a; int BOOST_PP_FRONT( SOME_ARRAY ); // a = 5; BOOST_PP_FRONT( SOME_SEQ ) = 5; } __________ Of course, front is a simple operation, but the same technique can be used to join all common container operations. For instance, a generic BOOST_PP_FOR_ALL macro could be made as well as generic transformation algorithms, etc. No longer would you have to be concerned about which preprocessor container types you are dealing with and you don't have to explicitly append the container name to container macros. With this functionality, Boost.Preprocessor could be described in a much more familiar sense to generic C++ programmers, through concepts, models, and overloaded macros. -- -Matt Calabrese

3 2

Re: [boost] [BGL] Graphviz
by Wang Weiwei 15 Jul '06

15 Jul '06

>On Fri, 14 Jul 2006 11:33:22 -0300, Wang Weiwei <wwwang(a)ccsdl.org> wrote: > >> >>> On Fri, 14 Jul 2006 10:58:00 -0300, Wang Weiwei <wwwang(a)ccsdl.org> >>> wrote: >>> >>>> I know BGL is compatible with Graphviz file format. >>>> and Graphviz is also an open source library. >>>> >>>> Is Graphviz ported to windows platform? >>> >>> Yes. >>> >>> http://www.graphviz.org/Download_windows.php >> >> I have downloaded the .src.tgz file and unzipped it. But can only get a >> .src file >> instead of an organised folder containing the C++ source files, which is >> what I expected. > >I don't know what's wrong. I just downloaded the file and WinRAR opens it >correctly. > >Bruno > Hello Bruno, Mmmm, :-( Whould you mind email a copy to me directly? Thanks Max

1 0

Re: [boost] [BGL] Add edge with vertex' properties instead ofvertex descriptors
by Wang Weiwei 15 Jul '06

15 Jul '06

> >On Jul 14, 2006, at 10:54 AM, Wang Weiwei wrote: > >> Hello, >> >> I have a graph type as follows: >> >> namespace boost >> { >> enum vertex_flag_t { vertex_flag = 111 }; >> BOOST_INSTALL_PROPERTY(vertex, flag); >> } >> >> typedef boost::adjacency_list<boost::vecS, boost::vecS, >> boost::undirectedS, >> property<vertex_name_t, std::string, >> property<vertex_flag_t, bool, >> property<vertex_color_t, default_color_type> > >, >> no_property> graph_t; >> >> graph_t g; >> >> That means I want to associate a string as name, a flag, and a >> default color to each vertex of my graph, >> now I want to add edges to my graph directly using the vertex' >> properties instead of their descriptors, >> e.g. >> >> boost::add_edge("vertex1", "vertex2", g); >> >> How can I accomplish this? > >You'll need to create a separate mapping from vertex names to vertex >descriptors: > > std::map<std::string, graph_t::vertex_descriptor> name_to_vertex; > > Doug Hello, Doug, Yes, I also got the right way from the BGL book. The main reason I ask this question here is that I hope/guess there may be a more BGL-native way to do this, with it in mind that I'm not very familiar with the whole library. Thank you very much. Max

1 0

[date_time] posix_time::ptime assignability
by Gennaro Prota 15 Jul '06

15 Jul '06

Hi, the date_time library docs (posix_time.html) state: "The class boost::posix_time::ptime is the primary interface for time point manipulation. In general, the ptime class is immutable once constructed although it does allow assignment." Looking at the code it doesn't seem to me it allows assignment. Am I missing something? -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

2 3

Re: [boost] Tuples and Bind problem
by Arash Partow 14 Jul '06

14 Jul '06

Hi Peter, thanks for your help, I'm one step closer to what I've been trying to accomplish and that is to be able use bind's within threads, the problem it seems is that bind doesn't like classes that implement the noncopyable interface. Would you have any idea on how to resolve such an issue? My code is as follows: template <typename T,int i> class select { public: typedef typename boost::tuples::element<i,T>::type result_type; template <typename U> result_type operator()(const U& u) const { return u.get(); } }; inline void do_something(const int i, const int j) { for(unsigned int x = 0; x < 1000; x++) { std::cout < param_set; std::vector<param_set> list; list.push_back(param_set(1,2)); list.push_back(param_set(2,3)); list.push_back(param_set(3,4)); boost::thread_group thrd_grp; std::for_each(list.begin(), list.end(), boost::bind(&boost::thread_group::create_thread,thrd_grp, boost::bind(&do_something, boost::bind(select<param_set,0>(),_1), boost::bind(select<param_set,1>(),_1)))); thrd_grp.join_all(); return true; } Arash Partow ________________________________________________________ Be one who knows what they don't know, Instead of being one who knows not what they don't know, Thinking they know everything about all things. http://www.partow.net Peter Dimov wrote: Arash Partow wrote: > > Hi all, > > > > I'm having some difficulties getting the following piece of code to > > compile: > > > > > > #include <iostream> > > #include <vector> > > > > #include <boost/utility.hpp> > > #include <boost/bind.hpp> > > #include <boost/tuple/tuple.hpp> > > > > > > class AClass > > { > > public: > > AClass(){} > > void b(int i, int j, int k) > > { > > std:: cout << "a::b() - " < > std::endl; } > > }; > > > > template <typename T,int i> class select > > { > > public: > > typedef typename boost::tuples::element<i,T>::type result_type; > > > > template <typename U> > > result_type operator()(const U& u) const The simpler result_type operator()(const T& u) const ought to work, too. > > { > > return u.get(); You might need u.template get(); here depending on the compiler. > > } > > > > }; > > > > int main(int argc, char* argv[]) > > { > > typedef boost::tuples::tuple<AClass,int,int,int> param_set; > > > > std::vector<param_set> list; > > list.push_back(param_set(AClass(),1,2,3)); > > list.push_back(param_set(AClass(),2,3,4)); > > list.push_back(param_set(AClass(),3,4,5)); > > list.push_back(param_set(AClass(),4,5,6)); > > list.push_back(param_set(AClass(),5,6,7)); > > > > std::for_each( > > list.begin(), > > list.end(), > > boost::bind(&AClass::b, > > boost::bind(select<param_set,0>(),_0), There is no placeholder named _0, they start at _1. > > boost::bind(select<param_set,0>(),_1), > > boost::bind(select<param_set,0>(),_2), > > boost::bind(select<param_set,0>(),_3))); You don't have enough arguments to use _2 or _3 as for_each only passes one. Instead of trying to get<0> the first element of the four tuples _0.._3, you need to get<0..3> the four elements of the one tuple _1. boost::bind(select<param_set,0>(),_1), boost::bind(select<param_set,1>(),_1), boost::bind(select<param_set,2>(),_1), boost::bind(select<param_set,3>(),_1)));

2 1

[math/staticstics/design] How best to name statistical functions?
by John Maddock 14 Jul '06

14 Jul '06

Paul Bristow has been toiling away producing some statistical functions on top of some of my Math special functions, and we've encountered a bit of a naming dilemma that I hope the ever resourceful Boosters can solve for us :-) For a given cumulative distribution function (I'm going to use the students-t function as an example below) there are two (or maybe three) variations: P: this is the regular cumulative distribution function, and is a rising function in it's argument (rises from 0 to 1). Q: this is 1-P and is also known as the complement of the cumulative distribution function. It falls from 1 to 0 over the range of it's argument. A: this is less well used and is P-Q or 1-2Q depending upon your point of view. Naming scheme 1: ~~~~~~~~~~~~~~~~ We have the reasonably obvious: students_t(df,x) : calculates P students_t_c(df,x) : calculates Q However that varies slightly from the existing practice of erf/erfc which if followed here would lead to: students_t(df,x) : calculates P students_tc(df,x) : calculates Q but the lack of the underscore doesn't look right to me. Naming Scheme 2: ~~~~~~~~~~~~~~~~ How about we call a spade a spade and use: students_t_P(df,x) : calculates P students_t_Q(df,x) : calculates Q Not pretty, but the P and Q notations are universally used in the literature, and of course we could handle the A case as well if that was felt to be needed. It doesn't follow normal Boost all_lower_case_names either, but since lower case "p" and "q" have slightly different meanings in the literature (they're for values of P and Q) I'm less keen on: students_t_p(df,x) : calculates P students_t_q(df,x) : calculates Q Wacky Scheme 3: ~~~~~~~~~~~~~~~ Both of the above suffer from a rather spectacular explosion of function prototypes once you include every variant for each distribution, an alternative using named parameters might be: P(dist=students_t, df=4, x=5.2); // P for 4 degrees freedom and x=5.2 Q(dist=students_t, df=5, x=20.0); // Q for 5 degrees freedom and x=20.0 But of course internally this would have to forward to something like (1) or (2) so it doesn't actually save you any implementation effort, just reduces the number of names. Inverses: ~~~~~~~~~ And if that's not enough, we also have inverses: * Calculate x given degrees of freedom and P. * Calculate x given degrees of freedom and Q. * Calculate degrees of freedom given x and P. * Calculate degrees of freedom given x and Q. At present we're looking at something like: students_t_inv(df,p); // Calculate x given degrees of freedom and P. But the other variants don't have obvious names under this scheme? So I'm hoping some Boosters can work their usual naming magic :-) Many thanks, John.

6 37

Boost regression notification (2006-07-14 [RC_1_34_0])
by Douglas Gregor 14 Jul '06

14 Jul '06

Boost Regression test failures Report time: 2006-07-14T11:10:54Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-RC_1_34_0/developer/i… 540 failures in 31 libraries algorithm/string (2) concept_check (1) conversion (1) date_time (1) filesystem (5) graph (6) integer (3) io (1) iostreams (61) iterator (1) lambda (2) mpl (20) numeric/conversion (4) numeric/interval (2) numeric/ublas (8) optional (2) parameter (33) pool (3) program_options (19) python (92) random (1) rational (5) serialization (179) signals (16) spirit (12) test (8) tr1 (39) typeof (9) utility (2) utility/enable_if (1) wave (1) |algorithm/string| regex: borland-5_6_4 replace: vc-7_1-stlport |concept_check| class_concept_check_test: vc-7_1-stlport |conversion| lexical_cast_test: sun-5.8 |date_time| testgreg_serialize_dll: mingw-3_4_2 |filesystem| fstream_test: sun-5.8 mbcopy: sun-5.8 operations_test: vc-7_1-stlport operations_test_dll: vc-7_1-stlport wide_test: sun-5.8 |graph| adjacency_matrix_test: vc-7_0 bidir_remove_edge: vc-7_0 csr_graph_test: sun-5.8 graphviz_test: msvc-8.0 msvc-8.0 vc-7_1-stlport |integer| integer_traits_test: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |io| ios_state_unit_test: gcc-4.1.0_linux_x86_64 |iostreams| array_test: vc-6_5 auto_close_test: sun-5.8 vc-6_5 buffer_size_test: sun-5.8 vc-6_5 bzip2_test: msvc-7.1 msvc-8.0 sun-5.8 code_converter_test: sun-5.8 vc-6_5 component_access_test: sun-5.8 vc-6_5 compose_test: borland-5_6_4 sun-5.8 vc-6_5 copy_test: vc-6_5 counter_test: sun-5.8 vc-6_5 direct_adapter_test: vc-6_5 example_test: vc-6_5 vc-6_5-stlport file_descriptor_test: vc-6_5 file_test: vc-6_5 filtering_stream_test: sun-5.8 vc-6_5 vc-7_1-stlport finite_state_filter_test: cw-9.4 sun-5.8 flush_test: sun-5.8 vc-6_5 gzip_test: msvc-7.1 msvc-8.0 sun-5.8 invert_test: vc-6_5 line_filter_test: sun-5.8 vc-6_5 mapped_file_test: vc-6_5 newline_test: sun-5.8 vc-6_5 null_test: vc-6_5 pipeline_test: sun-5.8 vc-6_5 positioning_test: vc-6_5 regex_filter_test: sun-5.8 vc-6_5 restrict_test: sun-5.8 vc-6_5 seekable_file_test: sun-5.8 vc-6_5 seekable_filter_test: sun-5.8 vc-6_5 stdio_filter_test: sun-5.8 vc-6_5 symmetric_filter_test: sun-5.8 vc-6_5 tee_test: sun-5.8 vc-6_5 wide_stream_test: sun-5.8 vc-6_5 zlib_test: msvc-7.1 msvc-8.0 |iterator| is_lvalue_iterator: sun-5.8 |lambda| extending_rt_traits: sun-5.8 operator_tests_simple: sun-5.8 |mpl| apply: gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc sun-5.8 count: sun-5.8 count_if: sun-5.8 equal: sun-5.8 erase: sun-5.8 find: sun-5.8 insert: sun-5.8 insert_range: sun-5.8 lambda_args: sun-5.8 multiset: gcc-3.4.5_linux_x86_64 gcc-4.0.3_linux gcc-4.1.0_linux gcc-4.1.0_linux_x86_64 gcc-4.1.1_sunos_i86pc gcc-4_0_3_tru64 partition: sun-5.8 stable_partition: sun-5.8 vector_c: sun-5.8 |numeric/conversion| converter_test: borland-5_8_2 traits_test: borland-5_8_2 udt_example_0: borland-5_8_2 udt_support_test: borland-5_8_2 |numeric/interval| det: sun-5.8 test_float: vc-7_1-stlport |numeric/ublas| concepts: vc-7_1-stlport vc-7_1-stlport test1: msvc-8.0 vc-7_1-stlport test2: vc-7_1-stlport test4: vc-7_1-stlport test5: vc-7_1-stlport vc-7_1-stlport |optional| optional_test: sun-5.8 optional_test_ref: sun-5.8 |parameter| basics: borland-5_6_4 borland-5_8_2 sun-5.8 duplicates: borland-5_6_4 borland-5_8_2 earwicker: borland-5_6_4 borland-5_8_2 macros: borland-5_6_4 borland-5_8_2 sun-5.8 maybe: vc-6_5 vc-6_5-stlport vc-7_0 mpl: borland-5_6_4 borland-5_8_2 preprocessor: borland-5_6_4 borland-5_8_2 sun-5.8 vc-6_5 vc-6_5-stlport python-parameter-test: vc-6_5 vc-6_5-stlport vc-7_0 sfinae: borland-5_6_4 borland-5_8_2 vc-6_5-stlport singular: borland-5_6_4 borland-5_8_2 unnamed: borland-5_6_4 borland-5_8_2 unnamed_fail: vc-6_5 vc-6_5-stlport vc-7_0 |pool| test_pool_alloc: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp |program_options| cmdline_test: sun-5.8 cmdline_test_dll: cw-9.4 sun-5.8 options_description_test: sun-5.8 options_description_test_dll: cw-9.4 sun-5.8 parsers_test: sun-5.8 parsers_test_dll: cw-9.4 sun-5.8 positional_options_test: sun-5.8 positional_options_test_dll: cw-9.4 sun-5.8 unicode_test_dll: borland-5_8_2 cw-9.4 variable_map_test: sun-5.8 variable_map_test_dll: borland-5_8_2 cw-9.4 sun-5.8 winmain_dll: cw-9.4 |python| andreas_beyer: sun-5.8 args: sun-5.8 auto_ptr: sun-5.8 back_reference: sun-5.8 bases: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 ben_scott1: sun-5.8 bienstman1: sun-5.8 bienstman2: sun-5.8 bienstman3: sun-5.8 borrowed: sun-5.8 callbacks: sun-5.8 const_argument: sun-5.8 crossmod_exception: sun-5.8 data_members: sun-5.8 defaults: sun-5.8 dict: sun-5.8 docstring: sun-5.8 enum: sun-5.8 exception_translator: sun-5.8 exec: cw-9.4 darwin-4.0.1 gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux msvc-8.0 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 extract: sun-5.8 implicit: sun-5.8 indirect_traits_test: sun-5.8 injected: sun-5.8 iterator: sun-5.8 keywords: sun-5.8 list: sun-5.8 long: sun-5.8 minimal: sun-5.8 multi_arg_constructor: sun-5.8 nested: sun-5.8 numpy: sun-5.8 object: sun-5.8 object_manager: sun-5.8 opaque: sun-5.8 operators: sun-5.8 pearu1: sun-5.8 pickle1: sun-5.8 pickle2: sun-5.8 pickle3: sun-5.8 pickle4: sun-5.8 pointee: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 pointer_type_id_test: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 pointer_vector: sun-5.8 polymorphism: sun-5.8 polymorphism2: sun-5.8 polymorphism2_auto_ptr: sun-5.8 properties: sun-5.8 raw_ctor: sun-5.8 return_arg: sun-5.8 select_arg_to_python_test: sun-5.8 select_from_python_test: darwin-4.0.1 qcc-3.3.5_cpp qcc-3.3.5_gpp sun-5.8 select_holder: sun-5.8 shared_ptr: sun-5.8 slice: sun-5.8 staticmethod: sun-5.8 stl_iterator: sun-5.8 str: sun-5.8 string_literal: sun-5.8 test_pointer_adoption: sun-5.8 try: sun-5.8 tuple: sun-5.8 upcast: gcc-3.2.3_linux gcc-3.3.6_linux gcc-3.4.5_linux sun-5.8 vector_indexing_suite: sun-5.8 virtual_functions: sun-5.8 voidptr: sun-5.8 wrapper_held_type: sun-5.8 |random| random_test: intel-linux-9.0 |rational| rational_test: borland-5_6_4 sun-5.8 vc-6_5 vc-6_5-stlport vc-7_0 |serialization| test_array_binary_archive_dll: mingw-3_4_2 test_array_text_archive_dll: mingw-3_4_2 test_array_xml_archive_dll: mingw-3_4_2 test_binary_binary_archive_dll: mingw-3_4_2 test_binary_text_archive_dll: mingw-3_4_2 test_binary_xml_archive_dll: mingw-3_4_2 test_class_info_load_binary_archive_dll: mingw-3_4_2 test_class_info_load_text_archive_dll: mingw-3_4_2 test_class_info_load_text_warchive: vc-6_5 test_class_info_load_xml_archive_dll: mingw-3_4_2 test_class_info_save_binary_archive_dll: mingw-3_4_2 test_class_info_save_text_archive_dll: mingw-3_4_2 test_class_info_save_xml_archive: msvc-8.0 test_class_info_save_xml_archive_dll: mingw-3_4_2 test_codecvt_null: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_contained_class_binary_archive_dll: mingw-3_4_2 test_contained_class_text_archive_dll: mingw-3_4_2 test_contained_class_xml_archive_dll: mingw-3_4_2 test_cyclic_ptrs_binary_archive_dll: mingw-3_4_2 test_cyclic_ptrs_text_archive_dll: mingw-3_4_2 test_cyclic_ptrs_xml_archive_dll: mingw-3_4_2 test_delete_pointer_binary_archive_dll: mingw-3_4_2 test_delete_pointer_text_archive_dll: mingw-3_4_2 test_delete_pointer_xml_archive_dll: mingw-3_4_2 test_demo_auto_ptr_dll: mingw-3_4_2 test_demo_dll: mingw-3_4_2 test_demo_exception_dll: mingw-3_4_2 test_demo_fast_archive: sun-5.8 test_demo_fast_archive_dll: mingw-3_4_2 sun-5.8 test_demo_pimpl_dll: mingw-3_4_2 test_demo_polymorphic_dll: mingw-3_4_2 test_demo_portable_archive_dll: mingw-3_4_2 test_demo_shared_ptr_dll: mingw-3_4_2 test_demo_xml_dll: mingw-3_4_2 test_demo_xml_load_dll: mingw-3_4_2 test_demo_xml_save_dll: mingw-3_4_2 test_deque_binary_archive_dll: mingw-3_4_2 test_deque_text_archive_dll: mingw-3_4_2 test_deque_xml_archive_dll: mingw-3_4_2 test_derived_binary_archive_dll: mingw-3_4_2 test_derived_class_binary_archive_dll: mingw-3_4_2 test_derived_class_ptr_binary_archive_dll: mingw-3_4_2 test_derived_class_ptr_text_archive_dll: mingw-3_4_2 test_derived_class_ptr_xml_archive_dll: mingw-3_4_2 test_derived_class_text_archive_dll: mingw-3_4_2 test_derived_class_xml_archive_dll: mingw-3_4_2 test_derived_text_archive_dll: mingw-3_4_2 test_derived_xml_archive_dll: mingw-3_4_2 test_diamond_binary_archive_dll: mingw-3_4_2 test_diamond_text_archive_dll: mingw-3_4_2 test_diamond_xml_archive_dll: mingw-3_4_2 test_exported_binary_archive_dll: mingw-3_4_2 test_exported_text_archive_dll: mingw-3_4_2 test_exported_xml_archive_dll: mingw-3_4_2 test_list_binary_archive_dll: mingw-3_4_2 test_list_ptrs_binary_archive_dll: mingw-3_4_2 test_list_ptrs_text_archive_dll: mingw-3_4_2 test_list_ptrs_xml_archive_dll: mingw-3_4_2 test_list_text_archive_dll: mingw-3_4_2 test_list_xml_archive_dll: mingw-3_4_2 test_map_binary_archive_dll: mingw-3_4_2 test_map_text_archive_dll: mingw-3_4_2 test_map_xml_archive_dll: mingw-3_4_2 test_mi_binary_archive_dll: mingw-3_4_2 test_mi_text_archive_dll: mingw-3_4_2 test_mi_xml_archive_dll: mingw-3_4_2 test_mult_archive_types_dll: mingw-3_4_2 test_multiple_ptrs_binary_archive_dll: mingw-3_4_2 test_multiple_ptrs_text_archive_dll: mingw-3_4_2 test_multiple_ptrs_xml_archive_dll: mingw-3_4_2 test_no_rtti_binary_archive_dll: mingw-3_4_2 test_no_rtti_text_archive_dll: mingw-3_4_2 test_no_rtti_xml_archive_dll: mingw-3_4_2 test_non_default_ctor2_binary_archive_dll: mingw-3_4_2 test_non_default_ctor2_text_archive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_archive_dll: mingw-3_4_2 qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_text_warchive_dll: qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp test_non_default_ctor2_xml_archive_dll: mingw-3_4_2 test_non_default_ctor_binary_archive_dll: mingw-3_4_2 test_non_default_ctor_text_archive_dll: mingw-3_4_2 test_non_default_ctor_xml_archive_dll: mingw-3_4_2 test_non_intrusive_binary_archive_dll: mingw-3_4_2 test_non_intrusive_text_archive_dll: mingw-3_4_2 test_non_intrusive_xml_archive_dll: mingw-3_4_2 test_null_ptr_binary_archive_dll: mingw-3_4_2 test_null_ptr_text_archive_dll: mingw-3_4_2 test_null_ptr_xml_archive_dll: mingw-3_4_2 test_nvp_binary_archive_dll: mingw-3_4_2 test_nvp_text_archive_dll: mingw-3_4_2 test_nvp_xml_archive_dll: mingw-3_4_2 test_object_binary_archive_dll: mingw-3_4_2 test_object_text_archive_dll: mingw-3_4_2 test_object_xml_archive_dll: mingw-3_4_2 test_optional_binary_archive_dll: mingw-3_4_2 test_optional_text_archive_dll: mingw-3_4_2 test_optional_xml_archive_dll: mingw-3_4_2 test_polymorphic_binary_archive_dll: mingw-3_4_2 test_polymorphic_text_archive_dll: mingw-3_4_2 test_polymorphic_xml_archive_dll: mingw-3_4_2 test_primitive_binary_archive_dll: mingw-3_4_2 test_primitive_text_archive_dll: mingw-3_4_2 test_primitive_xml_archive_dll: mingw-3_4_2 test_private_ctor_dll: mingw-3_4_2 test_recursion_binary_archive_dll: mingw-3_4_2 test_recursion_text_archive_dll: mingw-3_4_2 test_recursion_xml_archive_dll: mingw-3_4_2 test_registered_binary_archive_dll: mingw-3_4_2 test_registered_text_archive_dll: mingw-3_4_2 test_registered_xml_archive_dll: mingw-3_4_2 test_reset_object_address: vc-7_0 test_reset_object_address_dll: mingw-3_4_2 vc-7_0 test_set_binary_archive_dll: mingw-3_4_2 test_set_text_archive_dll: mingw-3_4_2 test_set_xml_archive_dll: mingw-3_4_2 test_shared_ptr_132_binary_archive: sun-5.8 test_shared_ptr_132_binary_archive_dll: mingw-3_4_2 sun-5.8 test_shared_ptr_132_text_archive: sun-5.8 test_shared_ptr_132_text_archive_dll: mingw-3_4_2 sun-5.8 test_shared_ptr_132_text_warchive: sun-5.8 test_shared_ptr_132_text_warchive_dll: sun-5.8 test_shared_ptr_132_xml_archive: msvc-8.0 sun-5.8 test_shared_ptr_132_xml_archive_dll: mingw-3_4_2 sun-5.8 test_shared_ptr_132_xml_warchive: sun-5.8 test_shared_ptr_132_xml_warchive_dll: sun-5.8 test_shared_ptr_binary_archive_dll: mingw-3_4_2 test_shared_ptr_text_archive_dll: mingw-3_4_2 test_shared_ptr_xml_archive_dll: mingw-3_4_2 test_simple_class_binary_archive_dll: mingw-3_4_2 vc-6_5 test_simple_class_ptr_binary_archive_dll: mingw-3_4_2 test_simple_class_ptr_text_archive_dll: mingw-3_4_2 test_simple_class_ptr_xml_archive_dll: mingw-3_4_2 test_simple_class_text_archive_dll: mingw-3_4_2 vc-6_5 test_simple_class_text_warchive_dll: vc-6_5 test_simple_class_xml_archive_dll: mingw-3_4_2 vc-6_5 test_simple_class_xml_warchive_dll: vc-6_5 test_split_binary_archive_dll: mingw-3_4_2 test_split_text_archive_dll: mingw-3_4_2 test_split_xml_archive_dll: mingw-3_4_2 test_tracking_binary_archive_dll: mingw-3_4_2 test_tracking_text_archive_dll: mingw-3_4_2 test_tracking_xml_archive_dll: mingw-3_4_2 test_unregistered_binary_archive_dll: mingw-3_4_2 test_unregistered_text_archive_dll: mingw-3_4_2 test_unregistered_xml_archive_dll: mingw-3_4_2 test_utf8_codecvt: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp test_variant_binary_archive_dll: mingw-3_4_2 test_variant_text_archive_dll: mingw-3_4_2 test_variant_xml_archive: borland-5_8_2 test_variant_xml_archive_dll: borland-5_8_2 mingw-3_4_2 test_variant_xml_warchive: borland-5_8_2 test_variant_xml_warchive_dll: borland-5_8_2 test_vector_binary_archive_dll: mingw-3_4_2 test_vector_text_archive_dll: mingw-3_4_2 test_vector_xml_archive_dll: mingw-3_4_2 test_void_cast_dll: mingw-3_4_2 |signals| dead_slot_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp trackable_test: gcc-3.3.6 gcc-3.3.6_linux qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_cpp qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp |spirit| bug_fixes: sun-5.8 bug_fixes_debug: sun-5.8 char_strings_test: sun-5.8 char_strings_test_debug: sun-5.8 epsilon_tests: sun-5.8 epsilon_tests_debug: sun-5.8 file_iterator_tests: sun-5.8 file_iterator_tests_debug: sun-5.8 if_p_as_parser_tests: sun-5.8 mix_and_match_trees: sun-5.8 scanner_value_type_tests: intel-linux-9.0 while_p_as_parser_tests: sun-5.8 |test| basic_cstring_test: sun-5.8 boost_check_equal_str: sun-5.8 foreach_test: sun-5.8 ifstream_line_iterator_test: sun-5.8 output_test_stream_test: sun-5.8 parameterized_test_test: vc-6_5 vc-6_5-stlport token_iterator_test: sun-5.8 |tr1| run_random: sun-5.8 std_run_complex_overloads: sun-5.8 std_run_random: sun-5.8 std_test_bind: darwin-4.0.1 sun-5.8 std_test_complex: sun-5.8 std_test_function: sun-5.8 std_test_hash: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp sun-5.8 std_test_mem_fn: sun-5.8 std_test_random: sun-5.8 std_test_reference_wrapper: sun-5.8 std_test_result_of: sun-5.8 std_test_shared_ptr: sun-5.8 std_test_tuple: sun-5.8 std_test_tuple_tricky: sun-5.8 std_test_type_traits: sun-5.8 test_bind: darwin-4.0.1 test_boost: vc-7_1-stlport test_hash: qcc-3.3.5_gpp qcc-3.3.5_gpp qcc-3.3.5_gpp vc-7_1-stlport test_random: sun-5.8 vc-7_1-stlport test_regex: vc-7_1-stlport test_type_traits: sun-5.8 tr1_extent_test: sun-5.8 tr1_is_abstract_test: sun-5.8 tr1_is_empty_test: sun-5.8 tr1_is_function_test: sun-5.8 tr1_is_member_func_test: sun-5.8 tr1_is_member_obj_test: sun-5.8 tr1_is_object_test: sun-5.8 tr1_is_reference_test: sun-5.8 tr1_rank_test: sun-5.8 tr1_tricky_function_type_test: sun-5.8 |typeof| function_binding_emulation: sun-5.8 function_binding_native: vc-6_5 vc-6_5-stlport vc-7_0 nested_typedef_emulation: cw-9.4 odr_no_uns: vc-6_5 vc-6_5-stlport vc-7_0 template_tpl_emulation: sun-5.8 |utility| addressof_test: sun-5.8 operators_test: gcc-3.4.5_linux_x86_64 |utility/enable_if| lazy: sun-5.8 |wave| test_re2c_lexer: sun-5.8

1 0

[BGL] Add edge with vertex' properties instead of vertex descriptors
by Wang Weiwei 14 Jul '06

14 Jul '06

Hello, I have a graph type as follows: namespace boost { enum vertex_flag_t { vertex_flag = 111 }; BOOST_INSTALL_PROPERTY(vertex, flag); } typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, property<vertex_name_t, std::string, property<vertex_flag_t, bool, property<vertex_color_t, default_color_type> > >, no_property> graph_t; graph_t g; That means I want to associate a string as name, a flag, and a default color to each vertex of my graph, now I want to add edges to my graph directly using the vertex' properties instead of their descriptors, e.g. boost::add_edge("vertex1", "vertex2", g); How can I accomplish this? Thanks. Max

2 1