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

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

value_initialized added to libraries.htm
by Fernando Cacciola 30 Jan '04

30 Jan '04

Both on the main trunk and 1.31.0 RC2 Fernando Cacciola SciSoft

1 0

boost_1_31_rc2 - documentation glitches in tools/build/v2/
by Bronek Kozicki 30 Jan '04

30 Jan '04

1. GIF picture is corrupted: boost_1_31_0_rc2\tools\build\v2\c++boost.gif 2. two HTML files have bad "src" path to this picture: boost_1_31_0_rc2\tools\build\v2\doc\architecture.html boost_1_31_0_rc2\tools\build\v2\doc\extending.html B.

3 3

Who is the current maintainer of boost.thread?
by Roland 30 Jan '04

30 Jan '04

Some weeks ago Michael Glassford posted a question about the same subject. But as far as I can remeber without any answer. Did I miss something? Mike stated, that the original author silently disappeared from the list. The last relevant CVS commits have been done by a person named bill_kempf 11 months ago. Is this just a nickname for William Kempf? I like to restate the question, and also would offer to spend some of my time for helping in maintainance of the thread library. The submission_process.htm page also deals with Lifecycle, and says: "If you no longer can or wish to maintain your library, please post a message on the Boost developers mailing list and help someone else take over as the library maintainer." Does this also imply, that the only way to deal with an obviously silent maintainer, is to submit a totally new review request for a replacement library to move on with an otherwise stalled library? Regards, Roland

4 6

[graph] RC_1_31_0 bfs VC++ 7.1 failing metacomm only
by Beman Dawes 30 Jan '04

30 Jan '04

graph bfs VC++ 7.1 is passing on my machine but failing at runtime in Metacomm's tests. The only output is "EXIT STATUS: 666". Any ideas? --Beman

1 0

RE: [boost] Boost.Thread request: event object
by Sean Kelly 30 Jan '04

30 Jan '04

On Mon, 26 Jan 2004, Hurd, Matthew wrote: > > So are you saying that multiple threads calling WaitForSingleObject for > the same event is not safe or is the lack of safety elsewhere in the > windows event mechanism. I wouldn't mind a source url or something for > this if you have one so I can come up to speed. Aside from the papers linked to in the Boost.Thread documentation, the best thing to do is search comp.programming.threads for "windows" and "event." The discussion has come up there quite a few times, including some of the original talk about the Boost.Thread implementation. Alexander Terekhov (from this list) is involved in most of the discussions so you could search on his name as well. One such link is here: http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&threadm=3e2ae910%240%245… By the way, I'm not saying that WaitForMultipleObjects is broken so much as that Windows events seem to be broken once you get beyond the fairly simple cases. Waiting on a mutex in Windows uses the WaitForObject calls as well, so I don't think the function itself is at issue. > I think WSFU if a crimson herring, best to forget about it. I don't think I'd ever want to require a customer to install WSFU to use my application, but from the documentation it seems quite solid. Rather than Win32 wrappers (ala Cygwin) it's actually an entire subsystem that contains a full posix implementation. I haven't done much more than skim the docs, but it's at least worth some play-time. As for the rest... I like to come to my own conclusions and an still reading up on the details in my rather limited free time. I will freely admit that I would be more likely to use the Boost condvar implementation everywhere rather than in just the complcated cases if I could safely do away with a large chunk of the code. I guess what I want is for someone to prove to me that the solution really does need to be as complex as it seems :) Sean

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] > I may be mistaken, but it seems that the new asynchronous I/O > completion system at least currently cannot be used with sockets. You are correct - I thought I saw a changelist somewhere that said otherwise but I must have been dreaming... 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. ##########################################################################

1 0

(no subject)
by darin＠bentspoon.com 30 Jan '04

30 Jan '04

1 0

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Hurd, Matthew 30 Jan '04

30 Jan '04

> 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. Some process abstractions might be straight forward for "kill" signals and the windows equivalent. 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. The other thing I'd like to see is a substitutable framework, like the synch stuff I posted a while ago, where you can develop to a particular policy concept, for example a shareable mutex, then substitute a single threaded or null mutex or anything else in. ACE has had something similar for many years and it is straight forward. The current interface does not support such use AFAICT, hence the synch wrapper I use. I'd be happy to document and clean this up if there is interest. Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

4 4

:Guess_Toolset in build.bat failed for mingw. Failed even correctthis one. please help as well.
by Herbert Yu 29 Jan '04

29 Jan '04

Not sure now. I downloaded version 1.30.2 of boost. The build.bat file in {root}\tools\build\jam_src cannot work correctly with mingw as it says. First I have to add following to build.bat for it can guess mingw call :Test_Path gcc.exe if not errorlevel 1 ( set BOOST_JAM_TOOLSET=mingw set BOOST_JAM_TOOLSET_ROOT=%FOUND_PATH%..\ goto :eof) setlocal & endlocal It guess first? Should use my environment first! I have set both BOOST_JAM_TOOLSET and TOOLS! set TOOLS=mingw Set BOOST_JAM_TOOLSET=mingw Even build.bat can guess my mingw, it failed as following: execunix.c: In function `execcmd': execunix.c:214: warning: passing arg 3 of `spawnvp' from incompatible pointer type C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x12f):timestamp.c: undefined reference to `file_time' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x2cd):timestamp.c: undefined reference to `file_archscan' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccKYiaaa.o(.text+0x315):timestamp.c: undefined reference to `file_dirscan' C:\DOCUME~1\hyu\LOCALS~1\Temp/ccCOkaaa.o(.text+0x131c):builtins.c: undefined reference to `file_dirscan' gcc -o bin.mingwx86\jam -DNDEBUG -DOPT_HEADER_CACHE_EXT -DOPT_GRAPH_DEBUG_EXT -DOP T_SEMAPHORE -DOPT_FIX_TARGET_VARIABLES_EXT -DOPT_IMPROVED_PATIENCE_EXT -DYYSTACKSIZE=5000 -s -O3 -finline-functions -DMINGW command.c compile.c exp and.c glob.c hash.c hcache.c headers.c hdrmacro.c jam.c jambase.c jamgram.c lists.c make.c make1.c newstr.c option.c parse.c regexp.c rules.c scan.c search.c subst.c timestamp.c variable.c modules.c strings.c filesys.c builtins.c pwd.c execunix.c fileunix.c pathunix.c ...failed .cc bin.mingwx86\jam... ...failed updating 1 target... ...updated 2 targets... Can anyone help me? I am not on the list. Please reply to my email address as well. Thanks Herbert Yu

1 0

lightweight mutex for MacOS
by Martin Taylor 29 Jan '04

29 Jan '04

Hi I would like to put forward an implementation of a lightweight mutex for MacOS. I have tested it with shared_ptr_mt_test.cpp without problem. It's fairly short, so I hope you don't mind me posting it directly here for review. I should add also that I didn't really write this code (that's not a disclaimer - Howard Hinnant cooked it up after I asked the Codewarrior newsgroup for help!) Anyway, here's the code: #if __MACH__ #include <sched.h> #else #include <Multiprocessing.h> #endif namespace boost { namespace detail { class lightweight_mutex { private: volatile int a_; lightweight_mutex(lightweight_mutex const &); lightweight_mutex & operator=(lightweight_mutex const &); public: lightweight_mutex(): a_(0) { } class scoped_lock; friend class scoped_lock; class scoped_lock { private: lightweight_mutex & m_; scoped_lock(scoped_lock const &); scoped_lock & operator=(scoped_lock const &); void yield_thread() { #if __MACH__ sched_yield(); #else MPYield(); #endif } public: explicit scoped_lock(lightweight_mutex & m); ~scoped_lock() { m_.a_ = 0; } }; }; inline lightweight_mutex::scoped_lock::scoped_lock(lightweight_mutex & m) : m_(m) { register volatile int *p = &m_.a_; register int f; register int one = 1; asm { loop: lwarx f, 0, p cmpwi f, 0 bne- yield stwcx. one, 0, p beq+ done } yield: yield_thread(); goto loop; done: ; } } // namespace detail } // namespace boost Martin

6 14

Gmane archive problems
by Gennaro Prota 29 Jan '04

29 Jan '04

FYI, this is a notice that appears at the top of Gmane's homepage (http://gmane.org) ------------- Problems January 29th 2004: By mistake Gmane ran an expiry process last night, which means that most of the articles are gone from the spool. They are now being rescued from backup, but this process will likely take a few days. ------------------- Genny.

1 0

Re: 1.31.0 Release candidate 2 available - some nitpicks
by Baptiste Lepilleur 29 Jan '04

29 Jan '04

----- Original Message ----- From: "Joel de Guzman" <joel(a)boost-consulting.com> To: "Baptiste Lepilleur" <blepctc(a)free.fr> Sent: Thursday, January 29, 2004 11:53 AM Subject: Re: 1.31.0 Release candidate 2 available - some nitpicks > Baptiste Lepilleur wrote: > > >>>Joel de Guzman wrote: > >>> > >>> > >>>>Pavel Vozenilek wrote: > >>>> > >> > >>[...] > >>I see no empty blank lines. Could someone else please confirm this? > > > > > > Line ending of all HTML files of spirit are of the form '\r\r\n' (just look > > at them with a binary editor). It's likely the result of a checking in unix > > file format from a windows platform (or something like that). You need to > > run some tools to fix line endings. > > That's actually the first thing that I did. Check out the link I > gave [http://tinyurl.com/2tokp] See if you can find double \r. > As I said, I think the problem is with the zip file. The CVS version > is clean. You're correct, but the line endings of the CVS are already wrong. They are '\r\n' (dos), but the cvs is running on a linux box, it should be '\n'... When it get checked out on windows, '\n' becomes '\r\n' and therefore '\r\n' becomes '\r\r\n'. Running a line ending clean up tools to conform the local platform, and checking the files back in would fix the issue. Baptiste. > > Regards, > -- > Joel de Guzman > http://www.boost-consulting.com > http://spirit.sf.net >

1 0

1_31_0_rc2 python2.3 warning (nit)
by Neal D. Becker 29 Jan '04

29 Jan '04

Any use of 1_31_0_rc2 with python2.3 gives: /usr/include/python2.3/pyconfig.h:847:1: warning: "_POSIX_C_SOURCE" redefined In file included from /usr/include/limits.h:26, from /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/limits.h:122, from /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/syslimits.h:7, from /usr/lib/gcc-lib/i386-redhat-linux/3.3.2/include/limits.h:11, from /usr/local/src/boost_1_31_0_rc2/boost/python/detail/wrap_python.hpp:27, from /usr/local/src/boost_1_31_0_rc2/boost/python/detail/prefix.hpp:13, from /usr/local/src/boost_1_31_0_rc2/boost/python/class.hpp:9, from /usr/local/src/boost_1_31_0_rc2/boost/python/suite/indexing/indexing_suite.hpp:10, from /usr/local/src/boost_1_31_0_rc2/boost/python/suite/indexing/vector_indexing_suite.hpp:10, from Test.cc:1:

2 1

Re: [boost] Re: 1.31.0 Release candidate 2 available - some nitpicks
by Reece Dunn 29 Jan '04

29 Jan '04

Joel de Guzman wrote: >Pavel Vozenilek wrote: >>2. Spirit 1.8 docs: each line in code snippets is appended >> by empty line. Seems as CSS problem (unless its feature). > >Hmmm... which code snippets? I can't find them. I have had a look at the docs. For example, libs/spirit/doc/scanner.html has the following code snippet: template< typename IteratorT = char const*, typename PoliciesT = scanner_policies<> > class scanner; The problem is in the html sources where every line is folloowed by a blank line, e.g.: <html> <head> <title>The Scanner and Parsing</title> ... -- this seems to be a problem with the HTML code generator. Regards, Reece _________________________________________________________________ Use MSN Messenger to send music and pics to your friends http://www.msn.co.uk/messenger

10 14

bjam docs for boost developers?
by Jeremy Siek 29 Jan '04

29 Jan '04

Hi All, Are there bjam docs for boost developers that explain how to write a Jamfile in the style of the Jamfiles in the existing boost libraries? I already know about: http://www.boost.org/tools/build/jam_src/index.html but that doesn't cover stuff like "run" and "compile" and "link-fail". -Jeremy ------------------------------------------------------------------------ ----------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek(a)osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 856-1820 ------------------------------------------------------------------------ -----------------

4 6

boost_1_31_0_rc2 link check results
by Neal D. Becker 29 Jan '04

29 Jan '04

LinkChecker 1.10.3 Copyright ?2000-2004 Bastian Kleineidam LinkChecker comes with ABSOLUTELY NO WARRANTY! This is free software, and you are welcome to redistribute it under certain conditions. Look at the file `LICENSE' within this distribution. Get the newest version at http://linkchecker.sourceforge.net/ Write comments and bugs to calvin(a)users.sourceforge.net Start checking at 2004-01-29 09:11:04-004 URL http://www.boost.org/LICENSE_1_0.txt Name www.boost.org/LICENSE_1_0.txt Parent URL file:///usr/local/src/boost_1_31_0_rc2/index.htm, line 465, col 21 Real URL http://www.boost.org/LICENSE_1_0.txt Check Time 0.253 seconds Result Error: 404 Not Found Thats it. 1 error in 129 links found Stopped checking at 2004-01-29 09:11:19-004 ( 14.760 seconds)

1 0

RE: [boost] Re: Re: Boost.Thread : IO multiplexing
by Hurd, Matthew 29 Jan '04

29 Jan '04

> On Behalf Of Sean Kelly > Subject: Re: [boost] Re: Re: Boost.Thread : IO multiplexing > > IOCP works for both file and socket operations. Perhaps not a poll > method but I'm not much interested in the low-end solutions anyway. Small point. Please don't knock the pollster ;-) Polling trades CPU for latency gain. Polling is a high end solution for low latency requirements, which covers a lot of my issues (not the psychological ones though ;-)). Not so good for high throughput systems, but it can be. A combined approach, poll for a while you can then wait for an interrupt ( a bit like spin-locks ), can be especially beneficial for supercomputer oriented frameworks as plenty of research shows. A polling, single threaded architecture is often best for the style of performance oriented apps I develop. I have also seen some neat SAN software developed with polling that wouldn't have otherwise worked at all well. Regards, Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

3 2

Index.html for 1.31.0 and spirit
by Russell Hind 29 Jan '04

29 Jan '04

Is the index.html complete for 1.31.0? I think something could be mentioned for spirit as to what version it is now, and also the fact that it nolonger supports bcc32 compilers just to give people a warning that they are best to stick with 1.30.2 if they use spirit and borland compilers. (Or replace the spirit directory with the one from 1.30.2) Cheers Russell

3 3

[1.31 RC2, format] BCB problem
by Pavel Vozenilek 29 Jan '04

29 Jan '04

Borland C++ 6, patch 4, format_implementation.hpp: template< class Ch, class Tr> basic_format<Ch, Tr>& basic_format<Ch, Tr>:: operator= (const basic_format& x) { if(this == &x) return *this; (basic_format(x)).swap(*this); <<<=== here it fails return *this; } [C++ Error] format_implementation.hpp(93): E2102 Cannot use template 'basic_format<Ch,Tr>' without specifying specialization parameters Adding template parameters helped here: (basic_format<Ch, Tr>(x)).swap(*this); /Pavel

3 2

Re: [boost] Re: Re: Boost.Thread : IO multiplexing
by Roland 29 Jan '04

29 Jan '04

(Michael Glassford <glassfordm(a)hotmail.com>) wrote: > Sean Kelly wrote: > > I'm not sure that much if anything would need to be done to provide > > support for IO multiplexing in Boost. ... > That, of course, would be the best solution. Have you looked at the > code in the orignal post to see if such a solution would solve his > problem? > ... > > I guess the question > > becomes, is there a need for such an IO library in Boost? The > nature > > of the project would demand a good bit of custom code for each > > platform, which isn't typical of Boost components. I have been off for a few days now, and I like to see that I have arrived at the very same conclusions than you. 1) I believe now that most likely everything can be done with boost.thread as is (question still is performance) 2) I used an approach as 1 thread / WFMO instead beeing able to directly wait on condvars _and_ IO simulateneously. (Altough this approach isn't easily portable, as it contains a lot of platform dependencies. Also this approach does not scale very well for the multiplexing case since WMFO/select scenarios are limited in the number of waitable things. This is where IO completion should enter the scene.) 3) I agree that the real question should be whether there should be a such an IO library in boost. Personally I would vote for such a thing, perhaps based on already existing "C" async_io libs, much like the pthreads lib. If anyone is interseted I could try to post my files, but I am not sure where I should post them since they are more a bit of example appliaction code than library code. Would the boost files area be adequate? Roland

4 9

Re: [boost] 1.31.0 Release candidate 2 available
by Jeremy Siek 29 Jan '04

29 Jan '04

Hi Beman, On Wed, 28 Jan 2004, Beman Dawes wrote: bdawes> Good catch! adj-matrix-graph2.gif, subgraph.gif, and bdawes> undir-adj-matrix-graph2.gif are checked in a regular rather than binary bdawes> files. bdawes> bdawes> Jeremy? Ok, I think I got those fixed. Also, I fixed the bad figure references in adjacency_list.html and adjacency_matrix.html. Cheers, Jeremy ---------------------------------------------------------------------- Jeremy Siek http://php.indiana.edu/~jsiek/ Ph.D. Student, Indiana Univ. B'ton email: jsiek(a)osl.iu.edu C++ Booster (http://www.boost.org) office phone: (812) 856-1820 ----------------------------------------------------------------------

1 0

RE: [boost] Boost.Thread request: event object
by Hurd, Matthew 29 Jan '04

29 Jan '04

> On Behalf Of Daryle Walker > Subject: Re: [boost] Boost.Thread request: event object > > >> > >> if( lock const& l = lock(guard,t)) > > > > I like this last one, though I suspect I'll end up with > > > > if (lock lk(guard,t)) > > > > in my code as it will be the first thing I'll think of. > [TRUNCATE] > > Did you see my last message in this thread? I said that the rules of C++ > _FORBID_ creation of multiple objects and/or use of the constructor call > syntax when using object creation with the condition of an "if" or > "while". > The single object syntax with "=" is the only one allowed. > > -- > Daryle Walker Quite right. My sloppiness. Thanks Daryle. Matt Hurd. IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

1 0

The quick_allocator not-a-memory-leak
by Darren Cook 28 Jan '04

28 Jan '04

I've a class using the boost quick_allocator like this: class Chain{ //... void* operator new(std::size_t sz){ return boost::detail::quick_allocator<Chain>::alloc(sz); } void operator delete(void *p,std::size_t sz){ boost::detail::quick_allocator<Chain>::dealloc(p,sz); } //... }; I've started using valgrind ( http://valgrind.kde.org/ ) to look for memory problems in my unit tests and it is complaining that the memory is never released. Now I understand this: // "Listen to me carefully: there is no memory leak" // -- Scott Meyers, Eff C++ 2nd Ed Item 10 But is there some function I can call at the end of my program to: a) confirm I've called dealloc() for every alloc() and that the next pointer is currently at start b) release the memory. Valgrind supports suppressing the complaint but the check of deallocs matches allocs would be a useful test anyway. Darren

2 2