- Boost - lists.boost.org

Re: 4 more associative containers.
by Rich Sposato 04 Feb '04

04 Feb '04

Joaquín M López Muñoz wrote: > De: "David B. Held" > > "Jeremy Maitin-Shepard" <jbms(a)attbi.com> wrote in message > > news:87u128yr3g.fsf@jbms.ath.cx... > > > I believe that a library named ``indexed_set,'' which has been > > > proposed and is pending formal review, provides this functionality > > > in addition to supporting multiple indices. > > Are you sure it does the same thing? I was under the impression > > that Joaquin's library lets you define *additional* indexes, but what > > if you just want to use an existing index, but it is comparable to > > something other than the key_type? > indexed_set does provide this functionality > (multiple indices aside.) See > http://tinyurl.com/2vu5g, section "Special lookup operations". > See also > http://tinyurl.com/3dyzh, section "Index set operations" > for a formal definition of the kind of special lookup > operations provided. And so indexed_set does provide the ability to lookup by a type other than the key_type. Which means that if we compared the various set containers in terms of abilities, flex_set is a special case of indexed_set where the number of indexes == 1. >From what I just read about indexed_set, it seems that the best benefit to using flex_set instead of indexed_set is that flex_set is simpler and smaller. We can sort set container classes by abilities to get this: std::set < flex_set < indexed_set. We can also sort multiset containers by ability and get this: std::multiset < flex_multiset < indexed_set. Rich Sposato

2 1

Re: [boost] Getting rid of some warnings on gcc?
by Reece Dunn 04 Feb '04

04 Feb '04

Beman Dawes wrote: >At 10:50 AM 2/3/2004, Marshall Clow wrote: > > >I've noticed that a bunch of the gcc tests (Mac OS, Linux, Windows) > >have many, many warnings, and they're all the same: > >... > >So I tried adding "typename" in two spots. In the MacOS testing, it > >changed 30+ tests from "Warn" to "Pass". Here's the change: > > > >diff -r1.23 token_functions.hpp > >304c304 > >< tokenizer_detail::get_iterator_category< > >--- > >> typename > >>tokenizer_detail::get_iterator_category< > >396c396 > >< tokenizer_detail::get_iterator_category< > >--- > >> typename > >>tokenizer_detail::get_iterator_category< > >VC++ 6.0 fails with the added "typename", so it has to be placed in #if ... >#endif. But, yes, the change does clear a lot of gcc warnings. The change >seems so innocuous I went ahead and committed it to the CVS HEAD. Doesn't BOOST_DEDUCED_TYPENAME fix the compatibility with VC++ 6? Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

2 1

[serialization] void_cast patch
by Vladimir Prus 04 Feb '04

04 Feb '04

I believe that the attached patch should be applied to void_cast.cpp. According to std::3.2/3 "An inline function shall be defined in every translation unit in which it is used" which means putting inline function is .cpp file is not okay. The problem I had is then with optimization on, those function were stipped, leading to link errors. - Volodya

1 0

another regex doc error
by Neal D. Becker 04 Feb '04

04 Feb '04

boost_1_31_0_rc2/libs/regex/doc/match_flag_type.html says: namespace std{ namespace regex_constants{ That should be boost, not std, at least for now :)

2 1

Doc error in regex?
by Neal D. Becker 04 Feb '04

04 Feb '04

I'm trying 1.31.0rc2. unsigned int flags = boost::match_default; while(regex_search(start, end, what, re, flags)) { ../Test/PlotComplex.cc:36: error: invalid conversion from `unsigned int' to ` boost::regex_constants::_match_flags' But this is exactly what the example: boost_1_31_0_rc2/libs/regex/doc/regex_search.html shows. Need to update the doc?

2 1

RE: [boost] Re: 1.31.0 release candidate 3
by Bjorn.Karlsson＠readsoft.com 04 Feb '04

04 Feb '04

> From: Douglas Paul Gregor [mailto:gregod@cs.rpi.edu] > > Thanks to everyone who has tried this. So it looks like it might be an > optimizer bug (did anyone else try with optimization on?). > This probably > isn't a showstopper bug if it is an optimizer problem > (especially if one > needs particularly high optimization settings to trigger it). > I'll try to > work around this problem tonight, but it won't make 1.31.0. > I've managed (pun intended) to reproduce the problem when compiling with /CLR (compiles to managed code). The cause is this overloaded function: namespace detail { namespace function { inline bool has_empty_target(...) { return false; } } } When this function is called in assign_to (upon construction of the boost::function), the returned result is true (!), which means that the perfectly valid function (object) is never assigned, and the boost::function is thus empty. Oops... One way around this compiler bug is to avoid the ellipsis function, changing the signature of has_empty_target to: namespace detail { namespace function { inline bool has_empty_target(const void* f) { return false; } } } Cheers, Bjorn Karlsson

1 0

Getting rid of some warnings on gcc?
by Marshall Clow 04 Feb '04

04 Feb '04

I've noticed that a bunch of the gcc tests (Mac OS, Linux, Windows) have many, many warnings, and they're all the same: >/mnt/rh73/home/grafik/CVSROOTs/Boost/boost/boost/token_functions.hpp:305: >warning: ` > typename > >boost::tokenizer_detail::get_iterator_category<Iterator>::iterator_category' > is implicitly a typename and >/mnt/rh73/home/grafik/CVSROOTs/Boost/boost/boost/token_functions.hpp:397: >warning: ` > typename > >boost::tokenizer_detail::get_iterator_category<InputIterator>::iterator_category > ' is implicitly a typename So I tried adding "typename" in two spots. In the MacOS testing, it changed 30+ tests from "Warn" to "Pass". Here's the change: diff -r1.23 token_functions.hpp 304c304 < tokenizer_detail::get_iterator_category< --- > typename >tokenizer_detail::get_iterator_category< 396c396 < tokenizer_detail::get_iterator_category< --- > typename >tokenizer_detail::get_iterator_category< -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> Hey! Who messed with my anti-paranoia shot?

2 1

RE: [boost] 4 more associative containers.
by Rich Sposato 03 Feb '04

03 Feb '04

Gary Powell wrote: > I'm interested. I ran into the same issues with std::set that you have > and because of it, switched to a map when it wasn't really necessary. > Regarding acceptance by boost... I'm interested and will take a look > at the code. The code works with the STL version for GCC, but does not play well with other implementations of the STL. Later, I would like Boost to adopt these classes, but right now, I am only asking if Boost members are interested in the abilities these containers afford. Some questions I want Boost to ask are: 1. Do you like the class names: flex_set, flex_map, flex_multiset, and flex_multimap? 2. How can I implement the classes to not just compile and run with multiple compilers, but also work with existing STL implementations? (I am in the midst of making a separate version of these containers to work with Microsoft's STL implementation. I much prefer making only one version of these.) 3. Do you think I overlooked anything when I implemented these? (One suggestion is writing the containers to use an equivalence function in the comparator.) Thanks, Rich Sposato

1 0

should boost::ref forward some operators?
by Neal D. Becker 03 Feb '04

03 Feb '04

I ran into the following problem. I have an algorithm which looks like: template<typename in_t, typename out_t> void Alg (in_t in, in_t inend, out_t out) { for (; in != inend; in++, out++) do_something() } Now if I want to call this algorithm more than once, it would be convenient to pass out by ref, so it would be incremented: Alg (v.begin(), v.end(), boost::ref (out)) that is, pass a reference to some kind of output iterator this fails, because boost::ref doesn't have operator++ defined for reference_wrapper. My question is, should boost::ref forward operators like ++ so that this would work?

4 3

Re: 4 more associative containers
by Rich Sposato 03 Feb '04

03 Feb '04

Stefan Slapeta wrote: > Rich Sposato wrote: > > 1. You can search on any type that is comparable to the key_type, rather > > than just the key_type. (The STL associative containers only allows > > searches on the same type as the key.) > BTW, there is also an extention in STLPort which supports comparisons like > this. When I asked about this at STLport, they said they don't have extensions to the STL. Maybe I did not ask the right question. > I often wondered why this isn't supported by the standard containers. > Any idea? I must caution that flex_set has a minor disadvantage, a problem which std::set does not have. For primitive types, flex_set will cause code-bloat, while std::set will not. I don't use flex_set with primitive types because the compiler will make 2 functions out of this code for flex_set< long >, while it only makes one function using std::set< long >. typedef std::set< long > bunchOfLongs; long a = 1; short b = 2; bunchOfLongs.erase( a ); bunchOfLongs.erase( b ); The compiler will see flex_set< long >::erase( const long & ); as different from flex_set< long >::erase( const short & ); But, a compiler will see both of those calls above as: std:set< long >::erase( const long & ); For that reason, I can't advocate changing std::set's functions to be templated the way flex_set functions are. I suppose if it had templated functions like flex_set, there would be no need for flex_set, and somebody would some day advocate using a less-templated class called no_bloat_set. :-) I actually consider the bloat issue as minor because most of the functions are inline and small. Also, I rarely do a search using more than one type anyway. My typical usage with flex_set and related classes is to insert using the key_type, and find, count, and erase using a different type. Sometimes, the amount of code actually decreases inspite of a little bloat because I don't have to construct a temporary anymore. I think that could answer why the associative containers like map do not have templated functions. As to the other container types, I don't think they will need templated search functions. If you use the sequential containers, you can use the stand-alone find, count, binary_search, etc... functions and pass in a predicate. Rich

1 0