- Boost - lists.boost.org

Re: 1.31.0 release candidate 3
by Stephan T. Lavavej 04 Feb '04

04 Feb '04

I have tested 1.31.0 RC3 by using it to compile the test suite for my personal library libnuwen. The compile was clean without errors or warnings, including shadow warnings. So everything looks fine from my perspective, although I don't come close to using all of Boost. Stephan T. Lavavej http://nuwen.net

4 3

OK to correct typo's in RC.1.31.0 branch docs?
by John Maddock 04 Feb '04

04 Feb '04

Beman and all, Neal Becker has spotted a couple of nasty errors in the regex docs (wrong namespace in one place, wrong type in another), is it OK to commit the corrected docs (4 files) at this late stage to the release, I would rather commit than not, otherwise the end user could possibly be mislead. Thanks, John.

2 2

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