January 2004 - Boost - lists.preview.boost.org

mpl functions, pow_, root_, reciprocal
by Andy Little 09 Feb '04

09 Feb '04

Hi, Following preliminary ok of "pow" mpl metafunction by Alexey Gurtovoy... Here are some basic headers for mpl functions pow_, root_ and reciprocal. useage: boost::mpl::pow_<type,exponent>::type boost::mpl::root_<type,exponent>::type boost::mpl::reciprocal<type>::type Obvious type for the type and exponent is a static_rational type. For pow_ param order is same as runtime std::pow(x,y) , "root_" follows logically from pow_ .... but obviously ... pow_ could do the job) reciprocal also useful to represent 1/ type. I don't know enough mpl yet to provide generic examples except using the pqs types. If anyone else wants to have a go...? And of course docs :-) . Otherwise will get on with it asap. Feedback welcome. regards Andy Little ---------------------------------------------------------------- headers: #ifndef BOOST_MPL_POW_HPP_INCLUDED #define BOOST_MPL_POW_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type, typename Power> struct pow_ { typedef implementation_defined type }; }} //boost::mpl #endif //----------------- #ifndef BOOST_MPL_ROOT_HPP_INCLUDED #define BOOST_MPL_ROOT_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type, typename Power> struct root_ { typedef implementation_defined type; }; }} //boost::mpl #endif //----------------------------------- #ifndef BOOST_MPL_RECIPROCAL_HPP_INCLUDED #define BOOST_MPL_RECIPROCAL_HPP_INCLUDED namespace boost { namespace mpl{ template <typename Type> struct reciprocal{ typedef implementation_defined type; }; }} //boost::mpl #endif

6 30

function (object) return and argument metafunctions?
by David Abrahams 08 Feb '04

08 Feb '04

Hi, I know we've discussed this in the past, but did we ever settle on an interface for deducing the return and parameter types of function (object)s? Doug G.'s result_of<F(a,b)> template works for return types, but it's not very portable and is not even in Boost proper AFAIK. Many function objects and all function pointers have specific (non-templated) parameter types, and it would be extremely valuable to be able to deduce those as well. It's hard to believe that with all the functional programming libraries we have, there's no standardized facility for this sort of deduction. -- Dave Abrahams Boost Consulting www.boost-consulting.com

6 8

Re: class static constants, mpl, and linker problems
by David Abrahams 03 Feb '04

03 Feb '04

Daniel Krügler <dsp(a)bdal.de> writes: > - Assumption one: Boost does not provide the definitions of > potential static constants hidden by the BOOST_STATIC_CONSTANT > definition (I used only the headers of the library, so my potential > testing bug would be that I had to include the corresponding > translation units of boost providing the constant's definitions, > but sorry - I did not find them!). In general BOOST_STATIC_CONSTANT is used within templates, so the definition of a corresponding member may be given in the header file: template <int N> struct int_ { BOOST_STATIC_CONSTANT(int, value = N); }; #ifndef BOOST_NO_INCLASS_MEMBER_INITIALIZATION template <int N> int const int_<N>::value; #endif > As I said: If this assumption is false, please blame me straight > for incomplete testing and for trying to spread bad rumors on this > (really!) great library. It's probably not false in most cases. > - Assumption two: Even if Boost does provide these definitions, > there may occur problems due to the VC7.1 flags /Za and /Ze (aka > disabling and enabling language extensions), which I will explain > in the following. The same point applies as to assumptions one, if > I did incomplete testing or testing with rather old boost libraries. > > The nasty thing concerning the /Ze flag is that it effectively does > not "extend" the language in every case. A small testing case is the > following program: > > a.h: ------------------------- > #ifndef A_H_INC > #define A_H_INC > struct A > { > static const int val = 42; // Declaration of a static member variable > }; > #endif > ------------------------- > > a.cpp -------------------- > #include "a.h" > const int A::val; // Definition might be needed, if the program accesses > // the adress of A::val > ------------------------- > > main.cpp -------------------- > #include "a.h" > int main() > { > } > ------------------------- > > Although this is a C++ Standard compliant program, it will not > successfully link with the /Ze flag enabled, which is to my opion a > real compiler bug (which I already posted to m.p.v.language, but got > no reasonable response yet). The obtained error message is: > > error LNK2005: "private: static int const A::val" (?val@A@@0HB) already > defined in a.obj > error LNK2005: "private: static int const A::val" (?val@A@@0HB) already > defined in main.obj Looks like a bug to me. > Question: Is this special deficiency of the VC7.1 compiler taken > account in the current boost library? I doubt it. How would we do that? > I think, it is impossible to demand, that users are enforced to use > either only /Ze or only /Za, because each of these choices has some > considerable drawbacks (at least on Windows systems...) Well, it seems to me that we can only respond to actual problems. Do you have an actual case of using a Boost library where these issues cause you trouble? -- Dave Abrahams Boost Consulting www.boost-consulting.com

3 9

[filesystem] On POSIX, any reliable way to find file size?
by Beman Dawes 02 Feb '04

02 Feb '04

There have been requests for a Boost.Filesystem function which returns file size. But I don't want to provide such a function if it will be unreliable. On POSIX compliant 32-bit systems, is there any reliable way to find the size of a file? It looks to me as if stat::st_size's type of off_t isn't large enough on 32-bit systems to cope with large file sizes. Am I wrong, or missing something? How big is the largest possible file on, say, Linux? Isn't it larger than the 2 gigs a 32-bit signed integer can represent? --Beman

5 10

value_initialized, deep const, and template instantiation
by Jim Apple 02 Feb '04

02 Feb '04

value_initialized has non-deep (shallow?) const semantics. const value_initialized<T> is supposed to be const. Unfortunately, due to compiler errors in VC++ and Borland, it has operator T &() const instead of operator T&() operator const T&() const which breaks const-correctness in a big way. I'd like for there to be a config macro that identifies this error. I would make one, as well as a test for it, myself, but I only have access to icc and gcc on linux, both of which pass the test, so it's hard trying to identify the extent of the overloading selection failure. After creating this macro, we could use it to make a const correct value_initialized class for users with more advanced compilers. For those compilers, I think there would be value to adding operator-> for the invocation of member functions, like boost::optional. As an alternative, deep-copy would break const expectations in generic functions that take a const T &, but it would preserve it elsewhere, so it may be worth some more thought. Finally, I have come up with a similar class (which I wrote with deep const sematics, although I am open to argument about shallow const) for solving the following problem: ---------------------------------------------------------------------- #include <iostream> template<typename T> struct wrap { static const T joe; }; template<typename T> const T wrap<T>::joe; struct call_out { int num; call_out() : num(77) {} }; template<typename T> struct check_call { check_call() { std::cout << wrap<T>::joe.num << std::endl; } }; check_call<call_out> x; int main(){} ----------------------------------------------------------------------- This outputs 0, not 77, on gcc 3.3.2, intel 8, and vc6. I don't know if that's correct, 14.7.1/1 says: "... in particular, the initialization (and any associated side effects) of a static data member does not occur unless the static data member is itself used in a way that requires the definition of the static data member to exist." If this is std-conforming behavior, or not, i have a workaround that allows: ------------------------------------------------------------------------ #include <iostream> #include "can_init.hpp" template<typename T> struct wrap { static can_init<const T> joe; }; template<typename T> can_init<const T> wrap<T>::joe; struct call_out { int num; call_out() : num(77) {} }; template<typename T> struct check_call { check_call() { wrap<T>::joe.ensure_init(); std::cout << wrap<T>::joe->num << std::endl; } }; check_call<call_out> x; int main(){} ----------------------------------------------------------------------- which obviously uses deep const. Is there any interest in including this in boost/utility/? Should it have shallow or deep const semantics? Jim

2 5

compile-time array count
by Gennaro Prota 02 Feb '04

02 Feb '04

Having a look to some old list messages I've seen there has been some discussion about discovering the number of elements of an array in compile-time. Sorry if I have simply misunderstood something here (I'm rapidly catching up with old threads), but isn't this enough? http://article.gmane.org/gmane.comp.lib.boost.devel/3216 That's for expressions, of course, not type-ids. Genny.

4 8

Re: [boost] Re: Boost Digest, Vol 622, Issue 5
by John Maddock 02 Feb '04

02 Feb '04

> How about using Boost.Thread's call_once function? I realize it requires > extra code, but something along these lines seems like it should both > avoid too much locking and still work: > Aha, good thinking, yes that's a good idea. John.

2 1

ICE with is_abstract on VC 7.0
by Robert Ramey 01 Feb '04

01 Feb '04

When I compile anything that includes is_abstract.hpp I get a compiler ICE with VC 7.0 since is_abstract.hpp is included by type_traits.hpp it means that a large part of boost 1.31 release candidate 2 is now uncompilable on this platform. is_abstract was known to test the limits of many platforms. It is incredible to me that this could be dropped into "release candidate # 2" without having been part of the development tree for a reasonable amount of time. When can we expect 1.31 release candidate # 3? Robert Ramey

5 6

1.31.0 Release candidate 2 available
by Beman Dawes 01 Feb '04

01 Feb '04

Release candidate 2 is available at http://www.esva.net/~beman/boost_1_31_0_rc2.zip Feedback appreciated! Boost developers should limit changes to the RC_1_31_0 branch to fixes for showstoppers. Anything less should go in the next release. --Beman

14 25

problem with new iterators in 1.31 Release candidate # 2
by Robert Ramey 01 Feb '04

01 Feb '04

I have a problem with the latest version of the new iterators. This is illustrated in the following example. #include <strstream> #include <iterator> #include <boost/iterator/counting_iterator.hpp> main(){ std::istrstream is("abcdefg"); typedef boost::counting_iterator<std::istream_iterator<char> > ci; const ci end = std::istream_iterator<char>(); // note the const !!! ci begin = std::istream_iterator<char>(is); unsigned int size; // the following should fail at compilation ? // in fact it compiles are returns a value of -7 !!! size = begin - end; // the following should compile and return a value of 7 // in fact, it compiles but goes into an infinite loop size = end - begin; } Note that this problem did not appear with the first release candidate. Also, if one follows the links from the main documentation page, one is directed to the documentation of the old iterators. This is extremely confusing. This has been pointed out before. This above example is using 1.31. "release candidate" #2 compiled with VC 7.0 Robert Ramey

2 1

Re: [boost] [filesystem] On POSIX, any reliable way to find file size?
by Beman Dawes 31 Jan '04

31 Jan '04

At 01:29 PM 1/31/2004, Christoph Ludwig wrote: >I don't know whether there is a solution within any formally defined >Unix or Posix standard. But according to >http://www.suse.de/~aj/linux_lfs.html the Linux 2.4 kernel supports >the Large File Support (LFS) interface. There is also a link to the >LFS specification: >http://ftp.sas.com/standards/large.file/x_open.20Mar96.html Thanks. I think that is a bit dated, but Jens' reply seems reflect actual practice and that should be enough to get started with. --Beman

1 0

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

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