- Boost - lists.boost.org

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

Re: [boost] Re: impl(ementations) - keeping it simple
by Reece Dunn 30 Jan '04

30 Jan '04

John Torjo wrote: >Maybe to simplify the process, in boost-root (where boost-build.jam file >exists), we could have a makefile which automatically builds bjam from the >source files and the invokes it with a given configuation. > >like: >make msvc >(instead of bjam "-sTOOLS=msvc") > >Unfortunately, I don't have any makefile knowledge. I am knowledgeable in makefiles, but this leads to a problem: you need to configure the makefile to handle all the various compiler and platform combinations - something bjam already handles, so why duplicate this effort? Is there a bjam file for bjam?! That way it could be bootstrapped. But then why not just download a pre-built version of bjam? Regards, Reece _________________________________________________________________ Express yourself with cool emoticons - download MSN Messenger today! http://www.msn.co.uk/messenger

4 9

[bind] nested call of bind not compiled
by Alexey Nikitin 30 Jan '04

30 Jan '04

I try to compile next code: ===== my_test.cpp ===== #include <functional> #include <boost/bind.hpp> using namespace std; using namespace boost; struct my_assign_if { typedef void result_type; template<class T, class P> void operator()(T& dst, T const& src, P const& to_assign) const { if (to_assign()) dst = src; } }; int main() { int a=1, b=0; bind(my_assign_if(), ref(a), 0, _1)(bind(less<int>(), cref(b), 1)); // compiled bind(my_assign_if(), ref(a), 0, bind(less<int>(), cref(b), 1))(); // not compiled return 0; } ==================== and take next errors: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. my_test.cpp my_test.cpp(11) : error C2064: term does not evaluate to a function taking 0 arguments C:\Alnik\heap\boost\boost-dev\boost\bind.hpp(335) : see reference to function template instantiation 'void my_assign_if::operator ()<T,boost::_bi::result_traits<R,F>::type>(T &,const T &,const P &) const' being compiled with [ T=int, R=boost::_bi::unspecified, F=std::less<int>, P=boost::_bi::result_traits<boost::_bi::unspecified,std::less<int>>::type ] C:\Alnik\heap\boost\boost-dev\boost\bind\bind_template.hpp(21) : see reference to function template instantiation 'R boost::_bi::list3<A1,A2,A3>::operator ()<boost::_bi::bind_t<boost::_bi::unspecified,F,L>::result_type,F,boost::_bi ::list0>(boost::_bi::type<T>,F,A &)' being compiled with [ R=boost::_bi::bind_t<boost::_bi::unspecified,my_assign_if,boost::_bi::list3< boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_t<b oost::_bi::unspecified,std::less<int>,boost::_bi::list2<boost::_bi::list_av_ 2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3>>::result_type, A1=boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_ t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2<boost::_bi::list_ av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1, A2=boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_ t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2<boost::_bi::list_ av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2, A3=boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_ t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2<boost::_bi::list_ av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3, F=my_assign_if, L=boost::_bi::list3<boost::_bi::list_av_3<boost::reference_wrapper<int>,int, boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2< boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3>, T=boost::_bi::bind_t<boost::_bi::unspecified,my_assign_if,boost::_bi::list3< boost::_bi::list_av_3<boost::reference_wrapper<int>,int,boost::_bi::bind_t<b oost::_bi::unspecified,std::less<int>,boost::_bi::list2<boost::_bi::list_av_ 2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3>>::result_type, A=boost::_bi::list0 ] C:\Alnik\heap\boost\boost-dev\boost\bind\bind_template.hpp(19) : while compiling class-template member function 'boost::_bi::bind_t<R,F,L>::result_type boost::_bi::bind_t<R,F,L>::operator ()(void)' with [ R=boost::_bi::unspecified, F=my_assign_if, L=boost::_bi::list3<boost::_bi::list_av_3<boost::reference_wrapper<int>,int, boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2< boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3> ] my_test.cpp(18) : see reference to class template instantiation 'boost::_bi::bind_t<R,F,L>' being compiled with [ R=boost::_bi::unspecified, F=my_assign_if, L=boost::_bi::list3<boost::_bi::list_av_3<boost::reference_wrapper<int>,int, boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2< boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B1,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B2,boost::_bi::list_av_3<boost::reference_wrapper<int>,int ,boost::_bi::bind_t<boost::_bi::unspecified,std::less<int>,boost::_bi::list2 <boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B1,boost::_bi::list_av_2<boost::reference_wrapper<const int>,int>::B2>>>::B3> ] My question: why? or that can not be used by this way? Regards, Alexey.

2 1

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Darryl Green 30 Jan '04

30 Jan '04

> -----Original Message----- > From: Jeremy Maitin-Shepard [mailto:jbms@attbi.com] > Sent: Thursday, 29 January 2004 7:03 PM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing > > > "Hurd, Matthew" <hurdm(a)sig.com> writes: > > >> On Behalf Of Sean Kelly > >> > >> What remains an issue in my mind is how far to take this. > Socket and > >> file classes for each platform at least... what else? > > > Waitable timers would be the other "main" one I'd guess. > > Unfortunately, I do not believe that it is possible to wait on both a > timer and a file descriptor on POSIX platforms, so this is the same > situation as mutexes (see below). It is easy enough to do this - for example see ACE's Reactor Notify for details. If you care about other threads you need the notify interface to force a wake-up when a new timeout needs to be calculated, otherwise just calculating the timeout parameter from the head of the timer queue before blocking is enough. > > > Some process abstractions might be straight forward for > "kill" signals > > and the windows equivalent. > > Signal handling abstraction is probably best done by a separate > library. Signals are useful for dealing with asynchronous > i/o on POSIX > platforms, but I would recommend that non-blocking, but not > asynchronous I/O be used by the library on those platforms. > > > I would still like to see mutexes, timers, socket i/o and > file i/o all > > with similar acquisition concepts so there is a hope of > marrying them > > down the track if it is not done up front. > > I believe it has been concluded that there is pretty much no > way at all > of efficiently waiting on both a mutex and a file descriptor on most > POSIX platforms, including Linux and BSD. Furthermore, it is also > inefficient on Windows, since it requires use of > WaitForMultipleObjects, which doesn't scale well. I would not > recommend that an i/o multiplexing attempt to handle mutexes and > timers. > I don't see why the library shouldn't be generic enough to allow a unification on a platform that supports it. It may not be all that mythical - I'm sure there was some discussion and patches on lkml some time back suggesting that it is possible to extend epoll to work with futexes. On the opposite side of the coin, Linux 2.6 has extended aio in the kernel that should make aio a pretty reasonable option for that platform and at least tries to address most of the negatives mentioned re using aio on Posix platforms. Haven't tried to actually use it yet though! Regards Darryl. ########################################################################## This e-mail is for the use of the intended recipient(s) only. If you have received this e-mail in error, please notify the sender immediately and then delete it. If you are not the intended recipient, you must not use, disclose or distribute this e-mail without the author's prior permission. We have taken precautions to minimise the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. ##########################################################################

3 2

Re: [Function] Implemented operator== and operator!=
by Raoul Gough 30 Jan '04

30 Jan '04

Raoul Gough <RaoulGough(a)yahoo.co.uk> writes: > <#part type="text/plain" filename="d:/TEMP/gcc_296_err.txt" disposition=attachment > description="g++ 2.96 compiler output"> > <#/part> I guess I don't know how to drive my news reader! Here's the error output as inline text: g++ -fPIC -ftemplate-depth-120 -w -DNDEBUG -O3 -DBOOST_PYTHON_MAX_BASES=2 -DBOOST_PYTHON_SOURCE -I/foo/boost -I/usr/local_cci/Python-2.2.1t/include/python2.2 -c -o boost/libs/python/src/converter/arg_to_python_base.os /foo/boost/libs/python/src/converter/arg_to_python_base.cpp /foo/boost/boost/function/function_template.hpp: In method `void boost::function0<R, Allocator>::assign_to (const boost::reference_wrapper<FunctionObj> &, boost::detail::function::function_obj_ref_tag) [with FunctionObj = void (*) (), R = void, Allocator = allocator<boost::function_base>]': /foo/boost/boost/function/function_template.hpp:427: instantiated from `boost::function0<R, Allocator>::assign_to (Functor) [with Functor = boost::reference_wrapper<void (*) ()>, R = void, Allocator = allocator<boost::function_base>]' /foo/boost/boost/function/function_template.hpp:289: instantiated from `boost::function0<R, Allocator>::function0 (Functor, typename boost::enable_if_c<boost::type_traits::ice_not<boost::is_integral<Functor>::value>::value, int>::type) [with Functor = boost::reference_wrapper<void (*) ()>, R = void, Allocator = allocator<boost::function_base>]' /foo/boost/boost/python/errors.hpp:29: instantiated from `boost::python::handle_exception (T) [with T = void (*) ()]' /foo/boost/boost/python/errors.hpp:36: instantiated from here /foo/boost/boost/function/function_template.hpp:511: Internal error #373. /foo/boost/boost/function/function_template.hpp:511: confused by earlier errors, bailing out scons: *** [boost/libs/python/src/converter/arg_to_python_base.os] Error 1 scons: building terminated because of errors. /bar/build % g++ --version g++ --version 2.96 -- Raoul Gough. export LESS='-X'

1 0

Re: [Function] Implemented operator== and operator!=
by Raoul Gough 30 Jan '04

30 Jan '04

<#part type="text/plain" filename="d:/TEMP/gcc_296_err.txt" disposition=attachment description="g++ 2.96 compiler output"> <#/part> User-Agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (windows-nt) Cancel-Lock: sha1:mbn75GX0BrE0mKdP1bjMm9VxSrg= Douglas Gregor <gregod(a)cs.rpi.edu> writes: > On Tuesday 20 January 2004 01:29 pm, Douglas Gregor wrote: >> On the main branch, I've implemented operator== and operator!= for >> Boost.Function (but not in the form you expect). > > It's now documented. > > I've also checked in some changes to handle reference_wrapper logically: I just tried upgrading to the CVS mainline and got an internal compiler error in function_template.hpp when compiling one of the Python lib modules with gcc 2.96 linux. Reverting to RC_1_31_0 fixes the error. Recent lossage? /foo/boost/boost/python/errors.hpp:29: instantiated from `boost::python::handle_exception (T) [with T = void (*) ()]' /foo/boost/boost/python/errors.hpp:36: instantiated from here /foo/boost/boost/function/function_template.hpp:511: Internal error #373. /foo/boost/boost/function/function_template.hpp:511: confused by earlier errors, bailing out Compiler bug is documented at: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=57466 See attachment for more compiler output. -- Raoul Gough. export LESS='-X'

2 1

Graph: edge(u,v,g) isn't O(log(E/V)) as promised
by Alan Stokes 30 Jan '04

30 Jan '04

For an adjaceny_list which uses sets for its edges, edge(u, v, g) is supposed to be O(log(E/V)), as you would expect for a lookup in a set. (See http://www.boost.org/libs/graph/doc/using_adjacency_list.html#sec:choosing-….) But in fact it is linear in the number of out edges. This is because in graph/detail/adjacency_list.hpp (line 1325 in revision 1.113), in the edge_dispatch function that handles the disallow_parallel_edge_tag case, the code reads: i = std::find(g.out_edge_list(u).begin(), g.out_edge_list(u).end(), StoredEdge(v)), when it should probably be: i = g.out_edge_list(u).find(StoredEdge(v)), as it was in revisions 1.59 and previous. As an aside, it's not that obvious from the documentation that adjacency_list supports edge(u, v, g). AFAICT it's defined only in the AdjacencyMatrix concept, which adjacency_list is not documented as being a model of. [This is a repost - the original was in message 31695 on the 21st of January. But I foolishly reported two different problems with the same subject & in the same thread, only one of which was addressed. I'm assuming the other one was overlooked and so repeating it. I apologise if this assumption is incorrect.] - Alan

2 2