- Boost - lists.boost.org

[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 03 Feb '04

03 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

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

03 Feb '04

Maxim Yegorushkin wrote: > I had difficulty storing and finding boost::intrusive_ptr<> in std::set<>. > When I wanted to check if an arbitrary pointer value was in that set like: > struct some {/*...*/}; > typedef boost::intrusive_ptr<some> some_ptr; > typedef std::set<some_ptr> some_set; > some_set set; > bool exists(some const* s) > { > return set.find(s) != set.end(); > } > void foo() > { > bool b = exists(reinterpret_cast<some*>(0xdeadbeaf)); // boom > } > as std::set::find() requires a key value, it ended up with constructing the > smart pointer from a bogus value trying to do add_ref() and then release() > on that value which led to runtime errors. > If std::set<> had been able to use not a key value for find() but a key > comparable value I would not have had any problems with that code. I had similar problems with a conversion constructor getting invoked when I wanted to pass a pointer or value into std::set::find or std::multiset::count. That was one of the dificulties which led me to create flex_set and its related classes. Since flex_set does not require a temporary object, it also does not silently invoke a conversion constructor. Rich

1 0

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

03 Feb '04

On Mon, Feb 02, 2004 at 11:50:45PM -0800, Rich Sposato wrote: > > The containers are called flex_set, flex_map, flex_multiset, and > > flex_multimap. They are similar to the 4 STL associative containers. > > There are two important differences between the STL containers and these: > > 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.) > > 2. You do *not* need to create a temporary object of key_type to search > > through the containers. (The STL containers require you to create one > > temporary object to search for another.) > A good idea. I recall wishing for something like this a while ago; I > don't remember if it stemmed from an actual problem in practice or just > general unhappiness with the std:: interface in theory. > (It might be even more swell if comparators could know about > 'equivalence' as well, so you could test for equivalence using one > user-defined function, rather than two calls like !c(x,y)&&!c(y,x).) This seems like a good suggestion since it would provide a slight efficiency since the comparison will only be done once rather than twice. When I looked through flex_set implementation, I found only two places where equivalence is tested. Both of those are inside insert member functions. So, there is a benefit to adding an equivalence function to the comparison functor. Since there is no reason to templatize the insert functions, the equivalence function will not need to be overloaded as the function operators are. Using the Employee example to define an equivalence function, I guess it will look like this: struct CompareEmployees : std::binary_function< const Employee *, const Employee *, bool > { // rest of functor as shown in the introductory message. inline bool equivalent( const Employee * l, const Employee * r ) const { return ( l->GetName() == r->GetName() ); } }; Would anybody prefer a different function name beside equivalent? > Do you have have documentation of the new 'concepts'? Specifically it > seems like flex_xxxx<T> uses a new ComparableTo<T,U> concept to place > requirements on both the Comparator and the template arguments to > methods like find(). The only any documentation on it so far is what is on my website, and what I wrote for the journal, Overload. Most of my website's description of flex_set is already mentioned in the introductory post to this mail list. The ComparableTo< T, U > concept is enforced by the compiler and the comparator. In theory, the templated member functions can work with any type. But in practice, the compiler can only use one of the overloaded function operators in the comparator with a specific call to one of the templated member functions of flex_set. To designate that a specific type is comparable to the flex_set's key_type, just add another overloaded operator to the comparator. Say, if I wanted to compare an Employee object to a Customer object, I would just add two more functions like this: struct CompareEmployees : std::binary_function< const Employee *, const Employee *, bool > { // rest of functor as shown in the introductory message. inline bool operator () ( const Employee * l, const Customer * r ) const { return ( l->GetName() < r->GetName() ); } inline bool operator () ( const Customer * l, const Employee * r ) const { return ( l->GetName() < r->GetName() ); } }; Rich Sposato

1 0