- Boost - lists.boost.org

Interest in a small array count facility?
by Gennaro Prota 14 Jul '06

14 Jul '06

Hi guys, a while ago there was some discussion about incorporating a compile-time array count facility in boost. I also provided an implementation for multidimensional arrays. Is there still interest for this? The benefits over the classical sizeof(array)/sizeof(array[0]) idiom are not overwhelming but at least there's a fair syntactical convenience and, of course, the advantage of unit test integration. If there's interest I can add it, to the utility subdirectory I guess (better suggestions are welcome; I really don't like using utility/ as a sort of repository for anything we have no better place for). --Gennaro.

8 32

Interest in super string class?
by Jeff Garland 14 Jul '06

14 Jul '06

I've been working on a little project where I've had to doing lots of string processing, so I decided to put together a string type that wraps up boost.regex and boost.string_algo into a string type. I also remember a discussion in the LWG about whether the various string algorithms should be built in or not -- well consider this a test -- personally I find it easier built into the string than as standalone functions. You can download from the string/text processing part of the vault: http://tinyurl.com/dbcye Below is the summary and motivating code example. Enjoy, Jeff -------------------------------------------------------------------------- Souped up string class that includes fancy query, replacement, and conversion functions. This type has the following main goals: * Is a drop-in replacement convertable to std::string and std::wstring * Provide case conversions and case insensitive comparison * Provide white space triming functions * Provide a split functions to parse a string into pieces base on string or regex * Provide sophisticated text replacement functions based on strings or regex * Provide append and insert functions for types Overall, this class is mostly a convience wrapper around functions available in boost.string_algo and boost.regex. This is best illustrated with some code: super_string s(" (456789) [123] 2006-10-01 abcdef "); s.to_upper(); cout << s << endl; s.trim(); //lop of the whitespace on both sides cout << s << endl; double dbl = 1.23456; s.append(dbl); //append any streamable type s+= " "; cout << s << endl; date d(2006, Jul, 1); s.insert_at(28, d); //insert any streamable type cout << s << endl; //find the yyyy-mm-dd date format if (s.contains_regex("\\d{4}-\\d{2}-\\d{2}")) { //replace parens around digits with square brackets [the digits] s.replace_all_regex("\$([0-9]+)\$", "__[$1]__"); cout << s << endl; //split the string on white space to process parts super_string::string_vector out_vec; unsigned int count = s.split_regex("\\s+", out_vec); if (count) { for(int i=0; i < out_vec.size(); ++i) { out_vec[i].replace_first("__",""); //get rid of first __ in string cout << i << " " << out_vec[i] << endl; } } } //wide strings too... wsuper_string ws(L" hello world "); ws.trim_left(); wcout << ws << endl; Expected output is: (456789) [123] 2006-10-01 ABCDEF (456789) [123] 2006-10-01 ABCDEF (456789) [123] 2006-10-01 ABCDEF1.23456 (456789) [123] 2006-10-01 2006-Jul-01 ABCDEF1.23456 __[456789]__ [123] 2006-10-01 2006-Jul-01 ABCDEF1.23456 0 [456789]__ 1 [123] 2 2006-10-01 3 2006-Jul-01 4 ABCDEF1.23456 hello world

22 95

Re: [boost] [Boost-users] bug in documentation
by Daryle Walker 14 Jul '06

14 Jul '06

On 7/11/06 4:40 PM, "Ovanes Markarian" <om_boost(a)keywallet.com> wrote: > there is currently a bug in boost::lambda documentation > (<http://www.boost.org/doc/html/lambda/s03.html>). > > Current version: > > template <class T> : public binary_function<T, T, T> > struct plus { > T operator()(const T& i, const T& j) const { > return i + j; > } > }; > > should be: > > template <class T> > struct plus : public binary_function<T, T, T> > { > T operator()(const T& i, const T& j) const { > return i + j; > } > }; Fixed. (Hopefully; this HTML page is generated. There are two possible files it could come from. The first one, $ROOT/libs/lambda/doc/lambda.xml, was already OK. I fixed the second file at $ROOT/libs/lambda/doc/detail/lambda_doc.xml in the trunk as revision 1.15. Please undo this if changing this file was inappropriate. I don't know which of the two Lambda XML doc files is important.) -- Daryle Walker Mac, Internet, and Video Game Junkie darylew AT hotmail DOT com

1 0

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