- Boost - lists.boost.org

STLPort 5.0 configuration
by Robert Ramey 14 Jul '06

14 Jul '06

I'm trying to tweak a couple of tests so that they pass with STLPort 5.0. A part of the test has to be run differently for this platform and I want to detect which version of STLPort I'm running on. Here is the part of the test. This works for STL 4.5.3 but for STLPort 5.0 it doesn't. When I look in config it looks like I should be using // at least one library - MSL notes: it doesn't make much sense // to implement the == operator for hash collections - but goes ahead // does it anyway even though it doesn't seem to work. So sort into // vectors and then compare. Currently, it seems that STLPort versions // greater than 5.0 don't support the == operator on hashed sets #if !defined(_STLPORT_VERSION) || (_STLPORT_VERSION < 0x500) BOOST_CHECK(ahash_map == ahash_map1); #else std::vector< std::pair<random_key, A> > tvec, tvec1; std::copy(ahash_map.begin(), ahash_map.end(), std::back_inserter(tvec)); std::sort(tvec.begin(), tvec.end()); std::copy(ahash_map1.begin(), ahash_map1.end(), std::back_inserter(tvec1)); std::sort(tvec1.begin(), tvec1.end()); BOOST_CHECK(tvec == tvec1); #endif When I look at config infoSTLPort standard library version 0x510 I see __SGI_STL_PORT =0x510 __STL_DEBUG =1 _STLP_DEBUG =1 _STLP_DEFAULT_TYPE_PARAM =1 _STLP_IMPORT_VENDOR_CSTD =1 _STLP_LONG_LONG =long long _STLP_OWN_IOSTREAMS [no value] _STLP_USE_NEW_C_HEADERS [no value] _STLP_USE_OWN_NAMESPACE =1 __GLIBCXX__ =20051201 _GLIBCXX_USE_LONG_LONG =1 _GLIBCXX_USE_C99_MATH =1 _GLIBCXX_USE_C99 =1 _GLIBCXX_USE_LFS =1 _GLIBCXX_HOSTED =1 _GLIBCXX_SJLJ_EXCEPTIONS =1 So it looks like I should have something like: #if !defined__SGI_STL_PORT) || (__SGI_STL_PORT < 0x500) But I'm not sure how this would work with STLPort 4.5.3 What should I be doing. Robert Ramey

1 0

Re: [boost] [BGL] Help Needed
by Wang Weiwei 14 Jul '06

14 Jul '06

Hello Enage, Thank you so much for your help and sample code. One more question is: :-) If MyVPropType and MyEPropType are 2 user-defined typenames already exist that I want the vertex/edge descriptors to map into. e.g. class MyVPropType { std::vector<int> v; std::map<int, std::string> m; } class MyEPropType { double weight; std::string path_name; } And I also need two user types as the vertex/edge descriptors, e.g. -vertex descriptor type class MyVDescriptor { std::pair<int, std::string>; // sth else } -edge descriptor type class MyEDescriptor { std::string name; boost::array<int, 10> array; } (all of the above user types are somewhat complex intentionally but I think this does not matter, is it?) Additionally, while using these user maps, I want also retain the default color map for the vertices. How to write the code (using an adjacency_list graph class)? Thanks again. Max >--- Wang Weiwei wrote: >> > Thanks for your help. Would you pls give me an >> > example showing the usage of internal property >> > map for the vertices and edges? >> >> or, to make the question simpler, how to declare >> an adjacency_list type graph object with internal >> vertex/edge property maps as follows: >> >> vertex descriptor -> MyVpmType >> edge descriptor -> MyEpmType > >struct elem_id_t >{ > typedef boost::vertex_property_tag kind; >}; > >struct edge_id_t >{ > typedef boost::edge_property_tag kind; >}; > >typedef boost::property<elem_id_t, char> > MyVpmType; >typedef boost::property<edge_id_t, std::string> > MyEpmType; >typedef boost::adjacency_list< > boost::listS > , boost::vecS > , boost::directedS > , MyVpmType > , MyEpmType > > > Graph; > >Graph g; > >> And how to access the internal maps to do sum >> get/put operation? > >boost::property_map<Graph, elem_id_t>::type > vertex_map = boost::get(elem_id_t(), g); >boost::property_map<Graph, edge_id_t>::type > edge_map = boost::get(edge_id_t(), g); > > Cromwell D. Enage > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com >_______________________________________________ >Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost > > = = = = = = = = = = = = = = = = = = = = 　　　　　　　　致礼！　　　　　　　　Wang Weiwei 　　　　　　　　wwwang(a)ccsdl.org 　　　　　　　　　　2006-07-14

1 0

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

13 Jul '06

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. > >> std::less is ambiguous. It could be that you wanted merely the > >> function object representation of operator<, or it could be that > you > >> wanted the default map/set ordering relation. It is not clear which > >> of the two std::less is supposed to be. > > > > If shared_ptr doesn't support operator< it's not a problem, is it? > > The context is: > > - If we had a separate relation for set/map we would use that for > settable/mappable objects. > - Why is a separate relation better than just using less<>? > - Because it is evident from the design of the standard library > that less<> > isn't meant for that, not consciously, at least. > > "What should shared_ptr do" is a separate question. Under the > current status > quo, it defines operator< to order pair< shared_ptr<>, int > as > well. Under > a revised standard, it may well need to do something else, > depending on how > the standard is changed. 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. That's what the standard says - it is intentional (Alex would have had operator <() defined even for types such as complex - but couldn't get that through the standard - he was especially concerned with pointer comparisons to separate containers because this is very useful. Not being able to change the language he at least got the change for std::less (not being there this is probably a misrepresentation of history - but the Alex's intent was that a total ordering should be present nearly everywhere) - he was using operator <() even in the cases he new it was "wrong", because there is no operator [glyph for < with a loop at the small end]. I convinced him that std::less<> is a reasonable way to spell [glyph for < with a loop at the small end.] For pair<shared_ptr<>, int> - what makes shared_ptr special? This doesn't work pair<T*, int> today - I don't see why we should special case shared_ptr - especially in a way which should likely change in the future. Rather I'd recommend specializing std::less - note that you could also specialize std::less<> for std::pair<shared_ptr<>, T> (and the two other variants) if this is _really_ a big concern. I haven't run across a need to order pairs with shared_ptr (nor a pair with pointers for that matter). 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. 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. Sean

4 3

Solaris versions of sp_counted_base and atomic_count by Michael van der Westhuizen
by Peter Dimov 13 Jul '06

13 Jul '06

Michael van der Westhuizen has generously contributed Solaris versions of atomic_count and sp_counted_base. You can find them in the CVS HEAD and as attachments to this message. I haven't applied his patch (also attached) to atomic_count.hpp and sp_counted_base.hpp that would enable them yet, but I plan do so in a couple of days if there are no objections. If you have any suggestions or comments, please let me know; in particular, if you have a better idea how to detect SunOS 5.10 or later, or if you know what memory synchronization guarantees the Solaris atomics are supposed to provide. :-) Thanks in advance for any help or interest, and of course, big thanks to Michael for his contribution.

4 36

iterator_facade and InputIterators
by Richard Smith 13 Jul '06

13 Jul '06

The Standard's table of InputIterator requirements (table 72 in section 24.1) says that, amongst other things, an InputIterator must support the following two expressions: *a Convertible to T, the iterator's value_type a->m Equivalent to (*a).m The same language is present in the "New Iterator Concepts", N1550, documentation in the definition of ReadableIterator. In particular, InputIterators are allowed to, and often do, have operator* returning by value: template <typename T> class my_iterator { public: typedef T value_type; T operator*() const; // ... }; Because it is legal to call non-const member functions on temporary objects, it is legal to call non-const member functions on the value returned from operator*: struct foo { void non_const(); }; my_iterator<foo> i; (*i).non_const(); My reading of Table 72 documentation suggests that this means that for my_iterator<foo> to be a Readable Iterator, it must also be legal to write: i->non_const(); If so, this means that operator-> should return T* instead of T const* (possibly via a proxy class). In the current implementation of boost::iterator_facade, operator-> returns a proxy that acts as a T const*: template <class T> struct operator_arrow_proxy { operator_arrow_proxy(T const* px) : m_value(*px) {} const T* operator->() const { return &m_value; } operator const T*() const { return &m_value; } T m_value; }; Is there a reason not to change this to have operator-> returning a T*? That would seem closer to the defintion of an InputIterator. (I supposed that if operator* returns by const value, it would be necessary to resurrect the constness in the proxy, but assuming the iterator's reference typedef is also a const-qualified value, this should be easy enough.) I had a look at the current concept-based iterator proposal, N2039, to see whether that shed any light on this and it also seems to require this behaviour from an InputIterator. It formal concept only requires operator->'s return to be convertible to T const* (which T*, or a proxy to T*, is): concept InputIterator<typename X> { where /*...*/ Convertible<pointer, value_type const*>; pointer operator->(X); // } And in it's definition of operator->, it requires (*a).m to be well-formed and then defines a->m to be equivalent to it. Have I misunderstood some aspect of this, or does the Standard really all require that a generic input iterator adaptor, such as boost::iterator_adaptor (and by impliciation boost::iterator_facade) should support this? -- Richard Smith

2 3

[BGL] Search Algrorithms' Behavior
by Wang Weiwei 13 Jul '06

13 Jul '06

Hello, I have an undirected graph with several isolated (unconnected) sub-graphs. For example Vertex {1, 2, 3, 4, 5} Edge {(1,2), (1,3) (4, 5)} I want to know what will be the behavior of the search algorithms (such as DFS, BFS, or undirected_DFS) when I submit a search call with a specified beginning vertex. As a result, all of the verteces will be visited, or just those topologically connected to the input vertex? Any help will be appreciated. Max

2 1

[signals] slots bug?
by Bruno Martínez 13 Jul '06

13 Jul '06

Hello. Investigating a problem Elisabeth Benoit was having at the users mailing list I've come to this code, that doesn't work as I would expect: #include <boost/signal.hpp> #include <iostream> void func() { std::cout << "pp\n"; } int main() { boost::signal0<void> signal1; boost::signal0<void> signal2; boost::signal0<void>::slot_type slot = &func; boost::signals::connection conn = signal1.connect(slot); signal2.connect(slot); conn.disconnect(); signal2(); } The func() free function is only called once, because disconnect() removes the slot from both signals. I'm not sure if this is a bug, but I would expect slot_type to work as boost::function. Regards, Bruno

1 0

boost.org and www
by Gennaro Prota 13 Jul '06

13 Jul '06

Just out of curiosity, I verified that boost.org qualifies as a "class A" domain name for http://no-www.org/index.php. I wonder: is it intentional that we always use "www" in our url references? -- [ Gennaro Prota, C++ developer for hire ] [ resume: available on request ]

2 3

[signals] Bug in documentation
by Bruno Martínez 13 Jul '06

13 Jul '06

Hi. There's a bug in the tutorial. It says sig.connect(&print_sum); sig.connect(&print_product); sig.connect(&print_difference); sig.connect(&print_quotient); prints The sum is 8 The difference is 2 The product is 15 The quotient is 1.66667 when in fact it prints The sum is 8 The product is 15 The difference is 2 The quotient is 1.66667 because slots are called in FIFO order. Regards, Bruno

1 0

Tuples and Bind problem
by Arash Partow 13 Jul '06

13 Jul '06

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() - " << i << "\t" << j << "\t" << k << 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 { return u.get<i>(); } }; 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), boost::bind(select<param_set,0>(),_1), boost::bind(select<param_set,0>(),_2), boost::bind(select<param_set,0>(),_3))); return true; } Basically the "select class" is a code snippet I found on this list, the compilation errors I believe exist in how I'm calling bind, but I cant tell whats going wrong. Also I'm wondering is there a better way of doing what I'm trying to do, is there already a class or something in boost that will allow one to bind a function and a tuples of parameters. Also I'm wondering if it will be possible to derive AClass from boost::noncopyable and still be able to instantiate class instances as part of method parameters. Any help would be very much appreciated. 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

2 1