- Boost - lists.preview.boost.org

Re: [boost] [optional] outdated tests?
by JOAQUIN LOPEZ MU?Z 11 Jul '04

11 Jul '04

----- Mensaje original ----- De: Rene Rivera <grafik.list(a)redshift-software.com> Fecha: Domingo, Julio 11, 2004 6:13 pm Asunto: [boost] [optional] outdated tests? > Boost.Optional optional_test and optional_test_ref both have the > following error: Cannot open include file: > 'boost/detail/none.hpp': No > such file or directory. > > But only on the Win32 tests, and not on the Linux test. Not sure > what > the discrepancy is about but the file is definitely not there in > CVS. Linux test also fail, but, as discussed in a previous thread, the reports pages are not getting updated due to a XML-related problem. I think Aleksey fixed that, so hopefully the pages will update again soon. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

Fw: STLport & boost
by François Dumont 11 Jul '04

11 Jul '04

Hello I am currently actively contributing to STLport. One of my contribution is to make boost and STLport closer. I think STLport can gain a lot in using some of the boost libraries and then boost will be able to count on a robust std lib. For the moment I only use 2 libraries from boost, type_traits and call_traits. I have some issue when I include the boost headers from STLport. I was counting on the BOOST_STD_CONFIG macro to limit the damage but for some platforms this feature is just useless. Under Win32 there is a workaround implemented for MSVC compilers (win32.hpp:60) on the min and max template functions. This workaround require the inclusion of the algorithm standard header which make the STLport lib build process failed. According the comment this workaround has not really been validated so my questions are: - is it require for all MSVC++ versions? Doesn't VC.Net 2003 or even 2002 managed the described cases correctly? - Couldn't this workaround be implemented for the native library only and not when using STLport? STLport looks to me as the right place to handle this case. Bests Francois Dumont

11 24

Linux regressions
by John Maddock 11 Jul '04

11 Jul '04

There appear to be a few regressions in the Linux test results: 1) Several libraries are listed as failing with intel-linux-8 including config_test, regex, and python. However these do pass when tested on my own machine with the latest Intel binaries. Could this be a setup issue? For example if the compiler has recently been patched then you may need to clear out past builds before the tests will start passing again. 2) Test exec monitor is failing with gcc-2.96+STLPort which is causing quite a few other failures. 3) the test results look a little messed up somehow, and the failures listed in http://boost.sourceforge.net/regression-logs/cs-Linux.html don't match those in http://boost.sourceforge.net/regression-logs/cs-Linux/developer/. Definitely vacation time now... John.

4 6

Re: [boost] Re: Pretty Good Initialization Library
by brangdon＠cix.compulink.co.uk 11 Jul '04

11 Jul '04

In-Reply-To: <cch4as$941$1(a)sea.gmane.org> andrewalex(a)hotmail.com (Andrei Alexandrescu $See Website for Email$) wrote (abridged): > I was worried more (only) about the order of evaluation. > > v += foo(), bar(); I don't think order of evaluation is sacred. However, I am also not keen on using comma for this. I'd rather use operator<<(). v << foo() << bar(); This is partly because comma is so small its easy to overlook, partly because it is used for so many other common things, and partly because I think the semantics of operator<<() fit better here. "Append these items to that stream or container, with conversion or formatting if appropriate." I would also be happy with: v << repeat(5) << 4; meaning: v << 4 << 4 << 4 << 4 << 4; and so forth. It doesn't bother me that: v = 1, 2, 3; has no direct equivalent. It becomes: v.clear(); v << 1 << 2 << 3; Presumably you'd be content with operator<<() in that it doesn't imply an order of evaluation. -- Dave Harris, Nottingham, UK

11 28

boost::function code size
by Vladimir Prus 11 Jul '04

11 Jul '04

Hello, I've became interested in how efficient code-size-wise boost::function is, so I wrote a small script which generates a function which calls boost::function object N times and finds the size of the generated function. The results are somewhat interesting and somewhat alarming (to me). On gcc 3.3 with -Os, each call to boost::function costs 147 bytes of code size. With -O3 it's about 166 bytes. On gcc 3.4 calls cost 203 bytes with -Os and between 220 and 240 with -O3. However, when boost::function is called 15 times, the inliner heuristics kick in and calls are no longer inlined -- meaning each call costs about 14 bytes. This is a good thing for 3.4, but still: 1. For 3.3 boost::function causes a serious code bloat. 2. Even for 3.4, I'm not sure how it will perform if calls are done in several modules. Or how the heuristics will work on non-trivial cases: if they use the % of size increase then on large modules boost::function inlining can cost much more. Given that, IIUC, boost::function has to do indirect call somewhere anyway, I'm not sure inlining is such a good idea. Maybe some of the methods should be declared out-of-line, so that compiler don't try to inline them? - Volodya

2 3

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > On Jul 9, 2004, at 11:00 PM, Glen Knowles wrote: > > >> <nod> I just implemented lock_both::lock two ways: Once > just keep > >> try-locking both ways, and once locking in the order of > the addresses > >> of the locks (with only two locks in the test, this was a safe > >> operator<). My test looks like: > > > > The problem case for spinning is when one thread gets the locks and > > the holds them for a non-trivial length of time. During > that time the > > other, spinning thread, just wastes cpu as fast as it can. > This just > > gets magnified as more threads are involved. > > You are describing a spin-lock, but not lock_both (except for > a theoretical and unlikely scenario). Yes, I didn't think it through all the way. Glen

1 0

RE: [boost] Re: Re: Re: Pretty Good Initialization Library
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Vladimir Prus [mailto:ghost@cs.msu.su] > > As Andras Erdei the gap between people who know about special > properties of operator(), and those who know that overloaded > version does not have that properties is very, very narrow. FWIW, I knew that a comma was a sequence point from experience with C but didn't know (never thought about) that it lost that property when overloaded in C++. Glen

1 0

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Matt Hurd [mailto:matt.hurd@gmail.com] > > Holding multiple locks is pretty common and necessary. If > you can guarantee they will always be acquired in the same > order they will not deadlock. It is necessary. :) > > AFAIK r/w locks only makes sense if you're going to hold read locks > > for a period of time, otherwise you're better off just > using a regular mutex. > > Concurrency may be better with shared access. > > The most common case for me is for collections. Multi-read > might be quite important to your application's concurrent performance. My logic is that using a read lock only improves concurrency over exclusion for that period of time that you hold the lock. If that period is short any improvement will likely be insignificant next to what you paid for hitting the memory barrier in either case. Of course, YMMV :) Glen

1 0

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Glen Knowles 10 Jul '04

10 Jul '04

> From: Howard Hinnant [mailto:hinnant@twcny.rr.com] > On Jul 9, 2004, at 7:10 PM, Glen Knowles wrote: > >> Without try locks, lock_both can't be made to work without risking > >> deadlock. > > > > Lock_both can be made to work with try locks? Either you > have a way to > > deterministicly set the order you lock the mutexes or you have > > problems. You can avoid deadlocking with try lock, but you > will fail > > to get the pair of locks in cases were you would have gotten it by > > waiting. I suppose you could just keep try-locking both > ways until you > > get it, but that's not good for performance. :) > > Well actually keep try-locking both ways is what I've been > doing. I'd agree with you that in a heavily contested > context, performance could theoretically suffer arbitrarily badly. > > > One solution to this problem would be mutex::operator< > > <nod> I just implemented lock_both::lock two ways: Once > just keep try-locking both ways, and once locking in the > order of the addresses of the locks (with only two locks in > the test, this was a safe operator<). My test looks like: The problem case for spinning is when one thread gets the locks and the holds them for a non-trivial length of time. During that time the other, spinning thread, just wastes cpu as fast as it can. This just gets magnified as more threads are involved. Glen

2 1

Boost sandbox
by Edward Diener 10 Jul '04

10 Jul '04

How does one access files in the Boost sandbox ? I am particular interested in libraries that have been reviewed and approved after the 1.31 release. When I get the latest Boost from CVS I do not see those libraries there. I am assuming they are somewhere, perjaps in the sandbox. How can I get them to try them out before the next release of Boost ?

2 3