- Boost - lists.boost.org

boost_1_31_0_rc2 - Missing files,
by Joe Gottman 31 Jan '04

31 Jan '04

I discovered that there are a couple of missing html files in the rc2: \boost_1_31_0_rc2\libs\iterator\doc\iterator_traits.html and \boost_1_31_0_rc2\libs\iterator\doc\interoperable.html Joe Gottman

2 1

Linux RC_1_31_0 regression test questions
by Beman Dawes 31 Jan '04

31 Jan '04

Looking at http://boost.sourceforge.net/regression-logs/cs-Linux-RC_1_31_0.html to make sure we are in good shape for RC2 from the Linux perspective, I've got some (probably dumb) questions: * gcc 3.4 20040124 (prerelease) has 21 errors compared to 3 errors for gcc 3.3.1 and 3.3.2. Has anyone looked at the 3.4 errors and reported them to the appropriate gcc or Boost lists? Here are the three tests failing gcc 3.3.1 and 3.3.2: * iterator interoperable_fail * python embedding * type_traits is_abstract_test Do any of these raise alarm bells? Or are they all to be expected? --Beman

4 4

Re: [Type Traits] is_array and remove_bounds bug
by Jonathan Turkanis 31 Jan '04

31 Jan '04

"John Maddock" <john(a)johnmaddock.co.uk> wrote in message news:005801c3e27a$a6c4d1f0$4b580352@fuji... > > I have noticed that is_array and remove_bounds do not seem to work > > with array types of unknown bounds; e.g., > > > > BOOST_STATIC_ASSERT(!boost::is_array< int[] >::value); > > BOOST_STATIC_ASSERT((boost::is_same< boost::remove_bounds< int[] > > >::type, int[]>::value)); > > > > compile on GCC 3.2 and VC7.1. Is this the desired behavior? > > No, not at all. > > Thanks for the patches, No trouble. > ... this seems to be a strange corner case: VC7.1 > doesn't need the patches (it does the right thing without them), but gcc > does, while Borland doesn't compile the patched version, or do the right > thing without the patches... sigh. That's funny. My installation of VC7.1 defintely doesn't work with the unpatched version. > > Anyway, I've patched the headers and extended the test cases on my local cvs > copy, I've got the type traits regression tests running now, assuming > everything is OK, then I'll commit your patches when cvs comes back online. > How did the regressions turn out? BTW, while we're on the subject of remove_bounds, I think the documentation is slightly misleading. All the remove_xxx traits have a note under 'compiler requirements' essentially stating that the traits don't work correctly without partial specialization, 'except as noted below'. AFAICT, the note refers to the use of the macro BOOST_BROKEN_COMPILER_TYPE_TRAITS_SPECIALIZATION; however, this macro does not provide specializations of remove_bounds (and probably can't, efficiently). I therefore think it might be appropriate to remove 'except as noted below' from the remove_bounds documentation. I am I wrong? Thanks. Jonathan

2 1

Re: [boost] Re: Re: BOOST_STD_EXTENSION_NAMESPACE and dinkumware stdlib313
by John Maddock 31 Jan '04

31 Jan '04

> That's interesting. Since the compiler is determined before the > standard library, it would still be possible to put the definition in > boost/config/stdlib/dinkumware.hpp, like so > > #if defined(BOOST_MSVC) && (BOOST_MSVC >= 1310) > #define BOOST_STD_EXTENSION_NAMESPACE stdext > #endif > > Maybe one should check _CPPLIB_VER for good measure. This sounds > reasonable. What do you think? That sounds reasonable, I'll commit the changes to the main development branch when I get a chance, Intel uses Microsoft's headers (at least I think they do), so it'll be the same for them, but other vendors that use Dinkumware don't necessarily do the same thing (although again it's hard to be definitive). Thanks, John

1 0

Re: [boost] Fast-test-cycle Proposal [was 1.31.0 Progress (or lack thereof)]
by John Maddock 31 Jan '04

31 Jan '04

> > Would this be useful and worthwhile? Yes absolutely. John.

1 0

Incorrect link on the mailing lists page.
by Angus Leeming 31 Jan '04

31 Jan '04

http://www.boost.org/more/mailing_lists.htm Boost.Spirit lists Spirit has two additional mailing lists. Spirit-general for Spirit users and Spirit-devel for Spirit developers (open to anyone who wishes to hang out with Spirit coders). Both have GMane NNTP access (Spirit-general and Spirit-devel) with searchable archives ( Spirit-general and Spirit-devel). ^^^^^^^^^^^^^^ Both the searchable archives point to gmane.comp.parsers.spirit.devel Incidentally, when I go to the first 'Spirit-general' link: https://lists.sourceforge.net/lists/listinfo/spirit-general and click on To see the collection of prior postings to the list, visit the Spirit-general Archives. I get: ERROR Either your mailing list name was misspelled or your mailing list has not been archived yet. If this list has just been created, please retry in 2-4 hours Regards, Angus

5 8

Re: Very odd Comeau C++ behavior
by Comeau Computing 30 Jan '04

30 Jan '04

At 08:40 PM 1/26/2004 +0200, Peter Dimov wrote: >While implementing operator== for boost::mem_fn, I found that the following >program, which I expected to print '1' six times, mysteriously outputs 1 0 1 >1 0 1 under Comeau C++, causing all mem_fn equality tests to fail: > >#include <iostream> > >struct X >{ > int mf0_1() { return 0; } > int mf0_2() { return 0; } >}; > >struct mf0 >{ > typedef int (X::*F) (); > F f_; > > explicit mf0(F f): f_(f) {} > > bool operator==(mf0 const & rhs) const > { > return f_ == rhs.f_; Thanks for the report, it appears you've uncovered a problem. It's being looked into further. For now, this should work: return f_ == rhs.f_ ? true : false; > } > > bool operator!=(mf0 const & rhs) const > { > return f_ != rhs.f_; As well as here: return f_ != rhs.f_ ? true : false; > } >}; > >int main() >{ > std::cout << ( &X::mf0_1 == &X::mf0_1 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) == mf0(&X::mf0_1) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ == mf0(&X::mf0_1).f_ ) << std::endl; > > std::cout << "--\n"; > > std::cout << ( &X::mf0_1 != &X::mf0_2 ) << std::endl; > std::cout << ( mf0(&X::mf0_1) != mf0(&X::mf0_2) ) << std::endl; > std::cout << ( mf0(&X::mf0_1).f_ != mf0(&X::mf0_2).f_ ) << std::endl; >} > >Output: > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>como >testbed.cpp >Comeau C/C++ 4.3.0.1 (Aug 21 2002 15:45:32) for MS_WINDOWS_x86 >Copyright 1988-2002 Comeau Computing. All rights reserved. >MODE:strict errors C++ > > >C:\Documents and Settings\pdimov\My Documents\Projects\testbed>aout.exe >1 >0 >1 >-- >1 >0 >1 > >Is this a known issue with Comeau C++ 4.3? Or is there something wrong with >the code? ------- Comeau C/C++ 4.3.3: Check out the $43.30 limited time offer Comeau C/C++ ONLINE ==> http://www.comeaucomputing.com/tryitout World Class Compilers: Breathtaking C++, Amazing C99, Fabulous C90. Comeau C/C++ with Dinkumware's Libraries. Have you tried it? comeau(a)comeaucomputing.com http://www.comeaucomputing.com

1 0

Re: [boost] [Function] Implemented operator== and operator!=
by Peter Dimov 30 Jan '04

30 Jan '04

Douglas Gregor wrote: >> On the main branch, I've implemented operator== and operator!= for >> Boost.Function (but not in the form you expect). I am getting a C4800 warning from MSVC 7.1 ('int' forced to true/false) in function_template.hpp:299: bool equal = BOOST_FUNCTION_COMPARE_TYPE_ID(typeid(Functor), *type); return (equal? functor_ptr : make_any_pointer(reinterpret_cast<void*>(0))); That's because type_info::operator= returns an int (for ABI reasons, I presume.) This is a regression. The fix is trivial: return BOOST_FUNCTION_COMPARE_TYPE_ID(typeid(Functor), *type)? functor_ptr: make_any_pointer(reinterpret_cast<void*>(0)); The definition of BOOST_FUNCTION_COMPARE_TYPE_ID is: # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) (X==Y) It should be: # define BOOST_FUNCTION_COMPARE_TYPE_ID(X,Y) ((X) == (Y)) Also, I'm not really sure whether we should pre-emptively "fix" type_info::operator= like this. Bugfixes should be in response to actual bug reports.

3 2

Re: move_ptr
by David B. Held 30 Jan '04

30 Jan '04

Daniel, I got your email about the move policy and I replied to it. However, I have a flaky DNS entry for my domain, so your school's mail server was not able to resolve my email address and rejected my message. Anyway, thanks for the code, and I'll definitely look it over. Dave --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com) Version: 6.0.571 / Virus Database: 361 - Release Date: 1/26/2004

1 0

Line ending woes
by Beman Dawes 30 Jan '04

30 Jan '04

Here is some fresh information: * The reason the inspection program wasn't detecting more line ending problems was a really stupid bug by me - the files were not being read in binary mode. That made it look like the program was working, because it worked on a corner case which happened to be the case tested during development. Not only that, but html files weren't in the list of extensions being checked. Anyhow, both problems have been fixed in CVS. * Running the corrected inspect program shows 148 files with invalid line endings, in both the current CVS RC_1_31_0 branch and the release candidate. * Here are the RC2 counts by library: build 16 date_time 2 dynamic_bitset 1 graph 4 inspect 1 integer 2 math 7 mpl 1 python 1 spirit 113 * The current CVS head has 190 invalid line endings, with all of the increase coming in Spirit. That's worrisome; does it mean that some Spirit files are missing from the RC_1_31_0 branch? I'm not too worried about the scattered bad line ends in other libraries, but I'm definitely worried about Spirit. Before Joel or anyone makes wholesale fixes, I'd like to see one file fixed and checked. I'm also concerned that because we aren't 100% sure exactly what happened, it will bite us again. --Beman

2 2