- Boost - lists.boost.org

Re: [boost] Performance comparison between ptr_vectorandvector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >
by David Maisonave 06 Jan '06

06 Jan '06

"Sam Partington" <sam.partington(a)gmail.com> wrote in message news:<546fdb840601060205w76ed8be9n2bf73c4323c78c20(a)mail.gmail.com>... > On 1/5/06, David Maisonave <dmaisonave(a)commvault.com> wrote: > > > It seems to me that the first has the disadvantage of making it > > > relatively easy to provide an incorrect cloner that allows > > > slicing. However this is relatively easy to avoid by making your > > > hierarchy noncopyable, (Perhaps a way around this is to remove the > > > default implementation of new_clone?) > > > > Sorry Sam, but that's incorrect. > > As I posted in one of my previous examples, the noncopyable method > > does not work on pointer idioms. Noncopyable is for preventing > > slicing via concrete types. Noncopyable does not help for cloning. > > Since using the clone function method requires adding additional code > > for each new type, this increases the chances of slicing. > > And therefore (IMHO) it's easier to introduce bugs using this method. > > I don't agree with that. The clone concept is a well established > idiom for polymorphic types. Sure missing out a clone _does_ lead to > slicing, but that is understood, and as Thorsten says we can help > check for that with an assert. We can only help the user to get it > write, we can't do it all for them. > The cow_ptr and the copy_ptr can use the same assert code to catch slicing. The assert logic can be placed in the constructor of the cow_ptr and copy_ptr. This would make it easier to catch slicing in the cow_ptr/copw_ptr *than* it would be in the boost pointer containers. That's because in the boost pointer containers you would only catch slicing via assert if and when the object is clone. If the object never gets clone during testing, you would never catch the slicing. With cow_ptr/copy_ptr the slicing would be caught when the object gets instantiated. So you have a much higher probability of catching slicing using the cow_ptr clone method, *than* you would using the boost pointer container method. It's possible that the boost pointer containers could catch some of the slicing issues at compile time, if it new the name of the T::Clone function. If the boost pointer containers cought the type in the constructor, it could *than* do a test for T::my_clone_function. This could catch it if the correct type is being passed in, but again would still fail if being passed in via base type or parent derived type. Any way, it's food for thought.

2 1

Re: [boost] Performance test and memory usage
by Josh Napoli 06 Jan '06

06 Jan '06

If you need more accuracy for modern x86 CPUs, it is relatively easy to make an implementation of timer that uses the performance counter. Here is how to read the timer and get the period in Windows: period() { DWORD BufSize = _MAX_PATH; DWORD dwMHz = _MAX_PATH; HKEY hKey; // open the key where the proc speed is hidden: //long lError = RegOpenKeyEx(HKEY_LOCAL_MACHINE, LPCTSTR("HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0"), 0, KEY_READ, &hKey); // query the key: RegQueryValueEx(hKey, LPCTSTR("~MHz"), NULL, NULL, (LPBYTE) &dwMHz, &BufSize); value_ = 1./(dwMHz*1000000); } }; __forceinline static ULARGE_INTEGER readTimer() { #ifdef _WIN64 return __rdtsc(); #else ULARGE_INTEGER retval; unsigned int LowPart; unsigned int HighPart; __asm{ xor eax, eax xor ebx, ebx xor ecx, ecx xor edx, edx _emit 0x0f // RDTSC _emit 0x31 mov [LowPart], eax // TICK COUNTER STARTS HERE mov [HighPart], edx // TICK COUNTER STARTS HERE } retval.LowPart = LowPart; retval.HighPart = HighPart; return retval; #endif } -----Original Message----- From: boost-bounces(a)lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Howard Hinnant Sent: Tuesday, January 03, 2006 10:19 PM To: boost(a)lists.boost.org Subject: Re: [boost] Performance test and memory usage On Jan 3, 2006, at 5:12 PM, axter wrote: > What boost libraries are available for running code performance test There is timer: http://www.boost.org/libs/timer/timer.htm which is very handy, but in my experience not a complete solution for performance testing on modern machines because of the variability of the results. I've had good experience with the following timer driver: template <class F> float test(F f) { std::vector<float> t; int i; for (i = 0; i < 10; ++i) t.push_back(f()); double total_time = std::accumulate(t.begin(), t.end(), 0.0); while (i < 1000 && total_time < 1.0) { t.push_back(f()); total_time += t.back(); ++i; } std::sort(t.begin(), t.end()); t.resize(t.size() * 9 / 10); return (float)(std::accumulate(t.begin(), t.end(), 0.0) / t.size ()); } Which can be used like: float time_something() { // whatever set up needs to happen clock_t t = clock(); // or boost::timer, or whatever { // time this } // scope to time any destructors as appropriate t = clock() - t; // or whatever // whatever tear down needs to happen return (float)(t/(double)CLOCKS_PER_SEC); return seconds (or whatever) as a float } int main() { cout << test(time_something) << '\n'; } The basic idea of "test" is to call the function to be timed many times (say up to 1000), throw away the slowest 10% of those times, and average the rest. Why? <shrug> shoot-from-the-hip "theory" and experience that its return is fairly consistent to 2, maybe 3 digits. The test function has a "time out" feature where it quits if the accumulated measured time grows beyond 1 second (which may not be appropriate for all tests). But it is easy to get bored when you unexpectedly find yourself waiting 30 minutes for timing result, so that's why it's there. Otoh, I put in a minimum repetition of at least 10, no matter how long the measured time is, so you get at least some accuracy (tweak knobs as you like). Note that the accumulation/averaging happens in double, even though the data and answer are float (just paranoia really). Weakness: If you're timing something that is quicker than the minimum resolution of your timer, this doesn't work. But otherwise, this is better than the traditional loop inside the timer as it throws away those results that happen to get interrupted by your email checker running. :-) Anyway, if it is useful to you, use it. If not, no sweat. > and > memory usage (if any)? If you limit it to new/delete (neglecting malloc), the following would be easy to adapt: http://groups.google.com/group/codewarrior.mac/browse_frm/thread/ efb176352c161b08/0faec33468b1d6bd?lnk=st&q=insubject%3Aworld's +insubject%3Asimplest+author%3Ahinnant&rnum=2&hl=en#0faec33468b1d6bd (some day I'm going to have to start using tinyurl (or whatever it is)). The above is just an overloaded new using hash_map<void*, mem_info, malloc_allocator<appropriate pair> >. (map could just as easily be used). You could collect statistics from the container, and from mem_info. The malloc_alloc is necessary so that the container itself doesn't pollute your measurement. -Howard _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

Re: [boost] Performance comparison between ptr_vector and vector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >
by David Maisonave 06 Jan '06

06 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dph810$l4b$1(a)sea.gmane.org>... > David Maisonave wrote: > > "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > > news:<dpgu8s$e6k$1(a)sea.gmane.org>... > > >>This gave: > >> > >>Test performance for initializing and copying container of pointers. > >> > >>vector<copy_ptr<Shape> > 1.42 s > >> > >>boost::ptr_vector<Shape> 0.81 s > >> > >>vector<cow_ptr<Shape> > 0.13 s > >> > >> > >>But this test is a bit unfair: we create copies of the vector, but > >>we never mutate that copy. A fair test would mutate all the > >>elements. > > > > > > The cow_ptr is like a clone pointer and a shared pointer put > > together. > > right. > > > It shares the pointer, until an attempt is made to access it via > > non-constant operator-> or operator*. If non-constant access is > > made, then it checks to see if it's reference counter is larger then > > one. If so, it then performs the deep-copy, and releases the > > reference count. > > > > This is very efficient, because there's a good chance that the using > > code will never access all or any of the container objects in a > > non-constant manner. > > well, if no objects are being mutated, we don't have to make a copy. > > In practice I don't have a good estimate of how much data is touched, > but imgaine that it can easily be it all. In that case I expect > ptr_vector to win again (like it did in the other three categories). > > > The difference in efficiency will show up even more, when you have a > > more complex type that takes more time to construct. > > right, the above results has another string data member of size 100. > > > The test code uses > > a simple Shape class, which doesn't have much to it, but if you > > added more data members, and made the construction more complex, > > then the above test will be drastically different and it would show > > cow_ptr having a very high performance ratio. > > it would also increase the likelihood that we would mutate the > objects. > > > By the way, I believe you could add this type of COW logic to the > > existing boost pointer containers, and increase their efficiency. > > It depends somewhat of the situation at hand AFAICT. > > > But there is an overhead to this logic, > > right. ptr_vector uses vector<void*> internally to minimize binary > size too. and runtime-space-wise, its optimal. whether that matters > depends on the situation. > > > and you might have notice that > > some of the test show copy_ptr out performming cow_ptr. > > You could consider adding a policy option to the boost pointer > > containers, that would allow choosing between COW method and > > Clone-Always method. > > perhaps, but I do fear such a thing would greatly complicate the > implementation. > > I also have some concerns on performance of COW in multi-threaded > environments. > > As for cow_ptr requiring copy-semantics, then I think that is a very > poor idea. It must be possible to call new_clone() or similar. > I don't see anything wrong with requiring copy-semantics, and I don't like the idea of forcing the user to implement new_clone, because it makes using the smart pointer less generic. The built-in types have copy constructors, and so does most of the STL objects. To quote Scott Meyers [Effective C++]: ************************************************************************ ***************************************************** "If it's good enough for int's, it's good enough for me and my classes. It should be good enough for you and yours, too. Why introduce gratuitous incompatibilities with the conventions followed by the build-in types?" ************************************************************************ ***************************************************** A container of cow_ptr is more generic then boost pointer containers, because it doesn't require the type to have a clone method, or extra clone logic. If you want to use cow_ptr with legacy code, you can do so, with out having to break the interface. Imagine having legacy code, in which you already have an interface for an abstract type. If you want to create a container of pointers using boost pointer containers, you would have to make a lot of changes to existing legacy code, that could, or more then likely would introduce new bugs to the code. It's far safer to have a container that requires little - to no modification of existing code, and cow_ptr can do that as-is.

3 7

building 32-bit boost on an AMD Opteron?
by chrisc＠cs.rpi.edu 06 Jan '06

06 Jan '06

Hi -- I am trying to build boost on a 64-bit AMD Opteron but make it yield 32 bit code. The reason for this is I want smaller executables and memory footprint (Side note: if you do pmap on even a small hello world program on an 64 bit Opteron it requires 10 MB of virtual memory vs. 1.2 MB if compiled in 32 bit mode -- Can you believe it?). I have tried to edit the tools/build/gcc-tool.bjam file to add the -m32 compiler option to LINKFLAGS, CFLAGS, CPPFLAGS and CXXFLAGS. However, in doing so, it generates a number of compiler errors. Below is a sample (I am using GCC 4.0.2 under SUSE Linux). Any help would be most appreciated!! thank you!, Chris %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% bjam "-sTOOLS=gcc" install Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (and if you don't know what ICU is then you probably don't need it). --------------------------------------------------------------------- *** If you don't need Boost.Python, you can ignore this section *** *** pass --without-python to suppress this message in the future *** skipping Boost.Python library build due to missing or incorrect configuration couldn't find Python.h in "/usr/local/include/python2.2" You can configure the location of your python installation by setting: PYTHON_ROOT - currently "/usr/local" PYTHON_VERSION - The 2-part python Major.Minor version number (e.g. "2.2", NOT "2.2.1") - currently "2.2" The following are automatically configured from PYTHON_ROOT if not otherwise set: PYTHON_LIB_PATH - path to Python library object; currently "/usr/local/lib/python2.2/config" PYTHON_INCLUDES - path to Python #include directories; currently "/usr/local/include/python2.2" --------------------------------------------------------------------- ...patience... ...patience... ...found 13317 targets... ...updating 1523 targets... MkDir1 bin MkDir1 bin/boost MkDir1 bin/boost/libs MkDir1 bin/boost/libs/test MkDir1 bin/boost/libs/test/build MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.so MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.so/gcc MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.so/gcc/debug MkDir1 bin/boost/libs/test/build/libboost_prg_exec_monitor.so/gcc/debug/shared-linkable-true gcc-C++-action bin/boost/libs/test/build/libboost_prg_exec_monitor.so/gcc/debug/shared-linkable-true/execution_monitor.o g++: no input files set -e "g++" -c -Wall -ftemplate-depth-255 -DBOOST_TEST_NO_AUTO_LINK=1 -g -m32; flags gcc LINKFLAGS <debug-symbols>on -m32 -fno-inline -fPIC -I"bin/boost/libs/test/build" -I "/home/carother/32-Bit/boost_1_33_0" -o "bin/boost/libs/test/build/libboost_prg_exec_monitor.so/gcc/debug/shared-linkable-true/execution_monitor.o" "/home/carother/32-Bit/boost_1_33_0/libs/test/build/../src/execution_monitor.cpp" "/usr/bin/objcopy" --set-section-flags .debug_str=contents,debug "bin/boost/libs/test/build/libboost_prg_exec_monitor.so/gcc/debug/shared-linkable-true/execution_monitor.o" ...failed gcc-C++-action bin/boost/libs/test/build/libboost_prg_exec_monitor.so/gcc/debug/shared-linkable-true/execution_monitor.o...

3 3

Re: [boost] Performance comparison between ptr_vector andvector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >
by David Maisonave 06 Jan '06

06 Jan '06

"Sam Partington" <sam.partington(a)gmail.com> wrote in message news:<546fdb840601050424v61fae4f4n952293c6451203ae(a)mail.gmail.com>... > (Incidentally David you can disable the ADL warning in the project, or > on the command line and they go away, quite why they don't with > #pragma I don't know :-) ) > > It seems to me that this discussion is actually three orthogonal > discussions. > > 1. How should cloning be implemented. > Current implementation : > A clone function which defaults to copy constructor (if accessible) > for the static type of the container. Overridable using ADL. > > Alternative implementation: > Use the copy constructor for the static type of the pointer passed in > (which may be a more derived type than the static type of the > container). > > It seems to me that the first has the disadvantage of making it > relatively easy to provide an incorrect cloner that allows slicing. > However this is relatively easy to avoid by making your hierarchy > noncopyable, (Perhaps a way around this is to remove the default > implementation of new_clone?) Sorry Sam, but that's incorrect. As I posted in one of my previous examples, the noncopyable method does not work on pointer idioms. Noncopyable is for preventing slicing via concrete types. Noncopyable does not help for cloning. Since using the clone function method requires adding additional code for each new type, this increases the chances of slicing. And therefore (IMHO) it's easier to introduce bugs using this method. > > The second makes this harder. The default it gives you is more > sensible but implementing this requires a cloner type to be stored > along side each and every element in the container. Also if you do > have a problem with slicing, there is no way of overriding the > default behaviour. For example, this will slice with no fix possible. > > T* CreateT(); // return something derived from T > cow_ptr<T> p(CreateT()); The above code can be prevented if the T type is an abstract type. Both methods can prevent most slicing by using an abstract type. Both methods can still get slice via a derived-derived type. And in both methods, using noncopyable does not prevent slicing. However, (IMO), it's easier for a user to accidentally introduce slicing using the clone-function method, then it > > 2. Should ptr_ containers differ in interface from std containers. > > I've only just recently had a proper look at the ptr containers, and I > do find the differences somewhat disconcerting. The map iterator > dereferencing for example, is not what one is used to STL containers > would expect. I think it will cause most people to stumble when they > first start to use it. I can see the temptation to 'fix' interface > problems in the std containers, but that comes at a cost of a learning > curve and strange inconsitencies for the user. i->first and i->second > isn't pretty, but we're used to it now, and I can't see the std > containers changing. It took me a while to get most of these containers working, and I was only able to get ptr_set and ptr_map working with Thorsten's help. I also like the ptr_map::iterator better, and I which the std::map had use that interface instead. But since std::map didn't, I don't think ptr_map should deviate from it's counter part. It's too bad both methods can't be some how incorparated. > 3. Should ptr_vector support copy on write semantics. Or could boost > use a cow smart pointer? > > All of the performance comparisons shown so far that aren't affected > by cow show nearly identical results. That's not true. The copy container test shows cow_ptr being a clear winner. On my test, it show a very significant difference, and as I previously posted, the difference would be even more significant if we used a more complex type who's constructor takes more CPU time. > To test the copy on write behaviour more accurately, I changed the > copy test so it mutated all of the objects. And I added shared_ptr to > the types tested. That would *not* be an accurate test, since you're not taking advantage of the cow_ptr's feature. That's more of a worse case scenario test. Just as sorting algorithms have best case scenario and worse case scenario, depending on the data, so does cow_ptr and boost pointer containers. You can't use one type of data and say that would be an accurate test for all sorting algorithms. The cow_ptr will be most beneficial when copying a container or copying part of a container, and when the copy is not access via non-constant pointer. The std::string is an example where this logic works well. When you copy a class that has an std::string member, the copy is performed efficiently if the std::string implementation is using COW logic. Most of the time you won't even access all the data members of a class, which means the COW method helps to prevent copying data that doesn't need to be copy. I don't think ptr_vector should change to copy on write. I think it should have the option, via policy class, to use either COW or deep-copy-always. That way, the user can decide which is right for their particular requirements. You mention that you felt the discussion is actually three orthogonal. However, none of the three items you listed included what I consider to be the main issue. To me the main issue, is should a separate set of container classes be used as a main method for pointer of container logic. Or should we use the existing well tested, well known, portable STL containers, with a good clone smart pointer. I favor using the existing STL containers, which is easier for a C++ programmer to learn.

2 1

Re: [boost] Iostreams 'drain' algorithm proposal
by Oliver.Kowalke＠infineon.com 06 Jan '06

06 Jan '06

Hello Anrew, >I have a patch, should there be any interest. I would be interested in your patch. Regards, Oliver

2 1

[xpressive] Problem accessing repeating embedded pattern.
by Dick Bridges 05 Jan '06

05 Jan '06

I am trying to use Xpressive for parsing string-based message buffers. The messages start with a fixed string and end with an "empty" line (similar in form to HTTP). There is an example in the code below. Following a successful search, I'd like to be able process messages in the buffer with something like this pseudo code: for each message for each name_value pair make_pair(name, value) prepend what.suffix() to the next packet The examples of repeating an embedded regex I found in the .pdf and the examples subdirectory seemed close to what I need but I have not been able to make them work. Here is code that is the closest I've been able to get: #include <iostream> #include <boost/xpressive/xpressive.hpp> using namespace std; using namespace boost::xpressive; int main(int argc, char **argv) { std::string buffer = "FROGGIE\r\n" "Volume = 1\r\n" "Other1= 2\r\n" "Channel=3\r\n" "Other =4\r\n" "\r\n" "FROGGIE\r\n" "Volume = 5\r\n" "Other1= 6\r\n" "Channel=7\r\n" "Other =8\r\n" "\r\n" "FROGGIE\r\n" "Volume = 9\r\n" "Other1= 0\r\n" "Channel=10\r\n"; sregex name_value_pair_ = (+alnum >> *_s >> "=" >> *_s >> +_d >> *_s >> _ln); sregex message_ = (*_s >> "FROGGIE" >> _ln >> +name_value_pair_ >> _ln); sregex re_ = +(s1= message_); smatch what; if( regex_search( buffer, what, re_ ) ) { cout << "\n<what.size()>" << what.size() << "</what.size()>" << "\n<what[0]>\n" << what[0] << "</what[0]>" << "\n<what[1]>\n" << what[1] << "</what[1]>" << "\n<what[2]>\n" << what[2] << "</what[2]>" << "\n<what.suffix()>\n" << what.suffix() << "</what.suffix()>" << endl; } } // main I am not very accomplished with regular expressions but what[0] and what.suffix() look correct and I hoped that what.size() held the number of messages and what[1] and what[2] accessed each in turn. I clearly did not understand. <what.size()>2</what.size()> <what[0]> FROGGIE Volume = 1 Other1= 2 Channel=3 Other =4 FROGGIE Volume = 5 Other1= 6 Channel=7 Other =8 </what[0]> <what[1]> FROGGIE Volume = 5 Other1= 6 Channel=7 Other =8 </what[1]> <what[2]> </what[2]> <what.suffix()> FROGGIE Volume = 9 Other1= 0 Channel=10 </what.suffix()> OS is Linux Core 3 2.6.9-1.667. Compiler is gcc 3.4.4-linux. Xpressive README.txt (in the .zip) says "xpressive 0.9.8d". If someone could point me in the right direction, I'd surely appreciate it. Regards, Dick Bridges

3 13

Bug list status
by Marshall Clow 05 Jan '06

05 Jan '06

Six weeks ago: 77 open bugs Five weeks ago: 70 open bugs Four weeks ago: 64 open bugs. Three weeks ago: 65 open bugs. Two week ago: 64 open bugs One week ago: 61 open bugs Today: 59 open bugs Now that 1.33.1 has been released, let's get these bugs cleaned up... Thank you for your cooperation! As Jeff has pointed out, Mike Glassford (threads) and Stephen Cleary (pool) have been MIA for quite a while. If anyone wants to contribute fixes for their libraries, let me (or Jeff) know! If you think that a bug has been assigned incorrectly, please let me know. Bug counts per assignee: Mike Glassford 10 Doug Gregor 8 Stephen Cleary (shammah) 5 Joerg Walter 4 Joel de guzman (djowel) 3 Jeff Garland (az_sw_dude) 3 Jeremy Siek 3 Jonathan Turkanis 3 John R. Bandela 2 Marshall Clow 2 Beman Dawes 2 Eric Friedman (ebf) 2 Thorsten Ottosen (nesotto) 2 Vladimir Prus 2 Rene Rivera (grafik) 2 Kevlin Henney 1 Hubert Holin 1 Samuel Kremp 1 John Maddock 1 Jens Maurer 1 Daniel Wallin 1 Here are the currently opened bugs, sorted by assignee. Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: wrong usage of ios_base::narrow Bug #: 989487 <http://sourceforge.net/tracker/index.php?func=detail&aid=989487&group_id=75…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: date_time type conversion warning Bug #: 1069225 <http://sourceforge.net/tracker/index.php?func=detail&aid=1069225&group_id=7…> Assignee: az_sw_dude <http://sourceforge.net/users/az_sw_dude/> Summary: local_adjustor::utc_to_local throws 'Time label invalid' Bug #: 1220011 <http://sourceforge.net/tracker/index.php?func=detail&aid=1220011&group_id=7…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: clock is not portable Bug #: 788762 <http://sourceforge.net/tracker/index.php?func=detail&aid=788762&group_id=75…> Assignee: beman_dawes <http://sourceforge.net/users/beman_dawes/> Summary: boost::filesystem::exists has bugs with UNC paths Bug #: 1164057 <http://sourceforge.net/tracker/index.php?func=detail&aid=1164057&group_id=7…> Assignee: daniel_wallin <http://sourceforge.net/users/daniel_wallin/> Summary: [Parameter] Docco error section 2.7.2 Bug #: 1378446 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378446&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: EdgeListS = setS for adjacency_list does not work Bug #: 1163077 <http://sourceforge.net/tracker/index.php?func=detail&aid=1163077&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: LEDA graph adaptors do not handle hidden nodes properly Bug #: 1168431 <http://sourceforge.net/tracker/index.php?func=detail&aid=1168431&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: random_vertex/random_edge are unnecessarily inefficient Bug #: 1204684 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204684&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: Document copy_component Bug #: 1204688 <http://sourceforge.net/tracker/index.php?func=detail&aid=1204688&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: reverse_graph and constness of property maps Bug #: 1246336 <http://sourceforge.net/tracker/index.php?func=detail&aid=1246336&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: html docs frequently missing key words Bug #: 1294420 <http://sourceforge.net/tracker/index.php?func=detail&aid=1294420&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: EdgeListS = has_setS for adjacency_list does not work Bug #: 1352049 <http://sourceforge.net/tracker/index.php?func=detail&aid=1352049&group_id=7…> Assignee: dgregor <http://sourceforge.net/users/dgregor/> Summary: predicates without default constructor fail to compile (2) Bug #: 1353875 <http://sourceforge.net/tracker/index.php?func=detail&aid=1353875&group_id=7…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: Miss ' = ParserT()' Bug #: 907299 <http://sourceforge.net/tracker/index.php?func=detail&aid=907299&group_id=75…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: spirit insert_key_actor.hpp Bug #: 1059936 <http://sourceforge.net/tracker/index.php?func=detail&aid=1059936&group_id=7…> Assignee: djowel <http://sourceforge.net/users/djowel/> Summary: Another config correction for Sun C++ Bug #: 1220782 <http://sourceforge.net/tracker/index.php?func=detail&aid=1220782&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: boost::blank - missing operators Bug #: 1191356 <http://sourceforge.net/tracker/index.php?func=detail&aid=1191356&group_id=7…> Assignee: ebf <http://sourceforge.net/users/ebf/> Summary: [variant] Bug in recursive_wrapper_fwd.hpp Bug #: 1359257 <http://sourceforge.net/tracker/index.php?func=detail&aid=1359257&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: timeconv.inl to_duration() nsec error Bug #: 548104 <http://sourceforge.net/tracker/index.php?func=detail&aid=548104&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: AIX 4.3 SIGSEGV at thread termination Bug #: 551577 <http://sourceforge.net/tracker/index.php?func=detail&aid=551577&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: boost::threads uses msvc only function? Bug #: 568951 <http://sourceforge.net/tracker/index.php?func=detail&aid=568951&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: BCB6 throw EExternelException Bug #: 596149 <http://sourceforge.net/tracker/index.php?func=detail&aid=596149&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: thread_cleanup problems Bug #: 649291 <http://sourceforge.net/tracker/index.php?func=detail&aid=649291&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Mac implementation of threads is CPU hog Bug #: 885045 <http://sourceforge.net/tracker/index.php?func=detail&aid=885045&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: xtime_cmp: use comparison not subtraction Bug #: 993272 <http://sourceforge.net/tracker/index.php?func=detail&aid=993272&group_id=75…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: condition variables and recursive_mutex Bug #: 1072605 <http://sourceforge.net/tracker/index.php?func=detail&aid=1072605&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: compiler error on Mac implementation of threads Bug #: 1201779 <http://sourceforge.net/tracker/index.php?func=detail&aid=1201779&group_id=7…> Assignee: glassfordm <http://sourceforge.net/users/glassfordm/> Summary: Exception safety in class 'thread' Bug #: 1305885 <http://sourceforge.net/tracker/index.php?func=detail&aid=1305885&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost jam problem with parallel builds Bug #: 1234224 <http://sourceforge.net/tracker/index.php?func=detail&aid=1234224&group_id=7…> Assignee: grafik <http://sourceforge.net/users/grafik/> Summary: boost.build needs fixes for HP/UX Bug #: 1395924 <http://sourceforge.net/tracker/index.php?func=detail&aid=1395924&group_id=7…> Assignee: hubert_holin <http://sourceforge.net/users/hubert_holin/> Summary: Cannot compile octonion_test.cpp because of bug in sinc.hpp Bug #: 751289 <http://sourceforge.net/tracker/index.php?func=detail&aid=751289&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: Compiler error for tokenizer on Solaris Bug #: 976241 <http://sourceforge.net/tracker/index.php?func=detail&aid=976241&group_id=75…> Assignee: jbandela <http://sourceforge.net/users/jbandela/> Summary: token_iterator::at_end() result is inversed Bug #: 1338326 <http://sourceforge.net/tracker/index.php?func=detail&aid=1338326&group_id=7…> Assignee: jmaurer <http://sourceforge.net/users/jmaurer/> Summary: Diff in state of mersenne_twister gen between GCC3.41 & CW9 Bug #: 1115124 <http://sourceforge.net/tracker/index.php?func=detail&aid=1115124&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: bug in ublas/storage.hpp Bug #: 1095697 <http://sourceforge.net/tracker/index.php?func=detail&aid=1095697&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: dead links in uBLAS page Bug #: 1169273 <http://sourceforge.net/tracker/index.php?func=detail&aid=1169273&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: Documentation not available on web site: Bug #: 1228242 <http://sourceforge.net/tracker/index.php?func=detail&aid=1228242&group_id=7…> Assignee: joerg_walter <http://sourceforge.net/users/joerg_walter/> Summary: uBLAS::subslice doesn't work Bug #: 1292635 <http://sourceforge.net/tracker/index.php?func=detail&aid=1292635&group_id=7…> Assignee: johnmaddock <http://sourceforge.net/users/johnmaddock/> Summary: Adding boost::is_complex to type_traits.hpp Bug #: 1315712 <http://sourceforge.net/tracker/index.php?func=detail&aid=1315712&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: invalid result for File Dependency Examp Bug #: 551110 <http://sourceforge.net/tracker/index.php?func=detail&aid=551110&group_id=75…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: Spelling of Edmonds-Karp-Algorithm Bug #: 1226292 <http://sourceforge.net/tracker/index.php?func=detail&aid=1226292&group_id=7…> Assignee: jsiek <http://sourceforge.net/users/jsiek/> Summary: g++ v3.2.3 inker error for read_graphviz ih boost v1.33.1 Bug #: 1378907 <http://sourceforge.net/tracker/index.php?func=detail&aid=1378907&group_id=7…> Assignee: kevlin <http://sourceforge.net/users/kevlin/> Summary: lexical_cast & pure virtual functions & VC 8 STL Bug #: 1358600 <http://sourceforge.net/tracker/index.php?func=detail&aid=1358600&group_id=7…> Assignee: mclow <http://sourceforge.net/users/mclow/> Summary: Solaris - once.cpp compile error Bug #: 549162 <http://sourceforge.net/tracker/index.php?func=detail&aid=549162&group_id=75…> Assignee: mclow <http://sourceforge.net/users/mclow/> Summary: mistake in documentation of condition Bug #: 1364416 <http://sourceforge.net/tracker/index.php?func=detail&aid=1364416&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: boost.range and 'const char[]'. Bug #: 1272315 <http://sourceforge.net/tracker/index.php?func=detail&aid=1272315&group_id=7…> Assignee: nesotto <http://sourceforge.net/users/nesotto/> Summary: [Boost.Range]boost::const_begin calls non-qualified 'begin' Bug #: 1361686 <http://sourceforge.net/tracker/index.php?func=detail&aid=1361686&group_id=7…> Assignee: samuel_k <http://sourceforge.net/users/samuel_k/> Summary: format: assert when parsing invalid pattern Bug #: 1326132 <http://sourceforge.net/tracker/index.php?func=detail&aid=1326132&group_id=7…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: ct_gcd_lcm.hpp compilation error Bug #: 558174 <http://sourceforge.net/tracker/index.php?func=detail&aid=558174&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: pool::purge_memory() does not reset next_size Bug #: 984124 <http://sourceforge.net/tracker/index.php?func=detail&aid=984124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: Borland compiler error with Pool, boost::pool_allocator Bug #: 988124 <http://sourceforge.net/tracker/index.php?func=detail&aid=988124&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: perfomance: memory cleanup for pool takes too long Bug #: 995270 <http://sourceforge.net/tracker/index.php?func=detail&aid=995270&group_id=75…> Assignee: shammah <http://sourceforge.net/users/shammah/> Summary: boost::pool_allocator breaks with vector of vectors Bug #: 1179641 <http://sourceforge.net/tracker/index.php?func=detail&aid=1179641&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: rational operator&lt; can overflow Bug #: 798357 <http://sourceforge.net/tracker/index.php?func=detail&aid=798357&group_id=75…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: boost::rational documentation typos(?) Bug #: 1043616 <http://sourceforge.net/tracker/index.php?func=detail&aid=1043616&group_id=7…> Assignee: turkanis <http://sourceforge.net/users/turkanis/> Summary: problem with boost::iostreams when compiled with Visual C++ Bug #: 1365752 <http://sourceforge.net/tracker/index.php?func=detail&aid=1365752&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: multitoken broken in program_options 1.33 Bug #: 1266877 <http://sourceforge.net/tracker/index.php?func=detail&aid=1266877&group_id=7…> Assignee: vladimir_prus <http://sourceforge.net/users/vladimir_prus/> Summary: Proogram_options: Fails to parse options with a common root Bug #: 1395874 <http://sourceforge.net/tracker/index.php?func=detail&aid=1395874&group_id=7…> -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Re: [boost] Performance comparison between ptr_vector and vector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >
by David Maisonave 05 Jan '06

05 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dpk19e$u4$1(a)sea.gmane.org>... > Thorsten Ottosen wrote: > > Sam Partington wrote: > > >>It seems to me that the first has the disadvantage of making it > >>relatively easy to provide an incorrect cloner that allows slicing. > >>However this is relatively easy to avoid by making your hierarchy > >>noncopyable, (Perhaps a way around this is to remove the default > >>implementation of new_clone?) > > > > > > It's not very sensible to make the hierarchy copyable, because you > > can run into slicing in other places then. > > > > As for the default, then I've been thinking about this too. It still > > won't catch that one missed a clone() function longer down the hiararchy. > > > > Hm...I just came to think that a little assertion might help us out > here: > > inline base* new_clone( const base& b ) > { > base* res = b.clone(); > assert( typeid(*res) == typeid(b) ); > return res; > } > > That should catch any problems. I can even put this inside the > clone-allocator, so the user don't have to specify this. > That's a good idea, and it's something I could also add to cow_ptr and copy_ptr. However, doesn't boost have something better then typeid?

1 0

Boost regression notification (2005-12-01 [HEAD])
by Douglas Gregor 05 Jan '06

05 Jan '06

Boost regression test failures ------------------------------ Report time: 2005-12-01T06:00:10Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… 625 failures in 21 libraries: bind (1) concept_check (14) date_time (17) filesystem (5) foreach (5) graph (3) io (1) math (3) mpl (1) multi_array (7) parameter (1) program_options (14) python (289) regex (1) serialization (36) smart_ptr (1) spirit (3) tr1 (171) typeof (24) wave (4) xpressive (24) |bind| bind_dm3_test: msvc |concept_check| stl_concept_covering: cw-9_4 cw-9_4 gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 intel-win32-9_0 mingw-3_4_2 msvc vc-7_1 vc-7_1 |date_time| testc_local_adjustor: msvc testclock: msvc testdst_rules: msvc testfiletime_functions: msvc testgreg_duration_operators: msvc testgreg_serialize_dll: cw-9_4 intel-win32-8_1 vc-7_1 testiterator: msvc testlocal_adjustor: msvc testmicrosec_time_clock: msvc testparse_time: msvc testtime: msvc testtime_formatters: msvc testtime_period: msvc testwcustom_time_zone: msvc testwposix_time_zone: msvc |filesystem| path_test: mingw-3_4_2 msvc vc-7_1 path_test_dll: msvc vc-7_1 |foreach| array_byref: intel-win32-8_1 array_byval: intel-win32-8_1 rvalue_const: intel-win32-9_0 stl_byref: intel-win32-8_1 stl_byval: intel-win32-8_1 |graph| graphviz_test: vc-7_1 vc-7_1 layout_test: intel-win32-9_0 |io| ios_state_unit_test: intel-win32-9_0 |math| complex_test: gcc-3_4_3-sunos msvc log1p_expm1_test: msvc |mpl| size_t: gcc-4_0-darwin |multi_array| access: cw-9_4 assign: cw-9_4 assign_to_array: cw-9_4 idxgen1: cw-9_4 index_bases: cw-9_4 iterators: cw-9_4 slice: cw-9_4 |parameter| sfinae: msvc |program_options| cmdline_test: vc-7_1 cmdline_test_dll: vc-7_1 options_description_test: vc-7_1 options_description_test_dll: vc-7_1 parsers_test: vc-7_1 parsers_test_dll: vc-7_1 positional_options_test: vc-7_1 positional_options_test_dll: vc-7_1 unicode_test: vc-7_1 unicode_test_dll: vc-7_1 variable_map_test: vc-7_1 variable_map_test_dll: vc-7_1 winmain: vc-7_1 winmain_dll: vc-7_1 |python| andreas_beyer: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 args: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 auto_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 back_reference: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 ben_scott1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 bienstman3: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 builtin_converters: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 callbacks: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 const_argument: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 crossmod_exception: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 data_members: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 defaults: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 dict: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 docstring: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 enum: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 exception_translator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 exec: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos extract: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 implicit: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 injected: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 iterator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 keywords: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 list: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 long: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 map_indexing_suite: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 minimal: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 multi_arg_constructor: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 nested: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 numpy: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 object: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 opaque: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 operators: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pearu1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle1: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle3: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pickle4: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 pointer_vector: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism2: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 polymorphism2_auto_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 properties: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 raw_ctor: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 return_arg: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 select_from_python_test: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos shared_ptr: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 slice: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 staticmethod: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 stl_iterator: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos msvc vc-7_1 str: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 test_pointer_adoption: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 try: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 tuple: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 vector_indexing_suite: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 virtual_functions: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 wrapper_held_type: gcc-3.3.6-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos vc-7_1 |regex| grep: vc-7_1 |serialization| test_class_info_load_binary_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_binary_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_text_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_archive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_class_info_load_xml_warchive_dll: gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin test_const_save_fail1: msvc test_const_save_fail2: msvc test_const_save_fail3: msvc test_map_binary_archive_dll: msvc test_map_text_archive_dll: msvc test_map_text_warchive_dll: msvc |smart_ptr| shared_ptr_alloc2_test: msvc |spirit| multi_pass_compile_tests: intel-win32-8_1 traverse_tests: intel-win32-9_0 traverse_tests_debug: intel-win32-9_0 |tr1| run_complex_overloads: cw-9_4 gcc-3_4_3-sunos msvc run_random: msvc std_run_complex_overloads: cw-9_4 gcc-3_4_3-sunos msvc std_run_random: cw-9_4 msvc std_test_array: cw-9_4 msvc std_test_bind: cw-9_4 msvc std_test_boost: msvc std_test_complex: cw-9_4 msvc std_test_function: cw-9_4 msvc std_test_hash: cw-9_4 msvc std_test_mem_fn: cw-9_4 msvc std_test_random: cw-9_4 msvc std_test_reference_wrapper: msvc std_test_regex: cw-9_4 msvc std_test_result_of: cw-9_4 msvc std_test_shared_ptr: msvc std_test_tr1_include: cw-9_4 msvc std_test_tuple: cw-9_4 msvc std_test_type_traits: cw-9_4 msvc test_array: msvc test_bind: cw-9_4 msvc test_complex: cw-9_4 msvc test_function: cw-9_4 msvc test_functional: msvc test_hash: cw-9_4 msvc test_mem_fn: cw-9_4 msvc test_random: cw-9_4 msvc test_reference_wrapper: cw-9_4 msvc test_regex: msvc test_result_of: cw-9_4 msvc test_shared_ptr: cw-9_4 msvc test_tr1_include: cw-9_4 msvc test_tuple: cw-9_4 msvc test_type_traits: msvc test_utility: msvc tr1_add_const_test: cw-9_4 msvc tr1_add_cv_test: cw-9_4 msvc tr1_add_pointer_test: cw-9_4 msvc tr1_add_reference_test: cw-9_4 msvc tr1_add_volatile_test: cw-9_4 msvc tr1_aligned_storage_test: cw-9_4 msvc tr1_alignment_of_test: cw-9_4 msvc tr1_extent_test: cw-9_4 tr1_has_nothrow_assign_test: cw-9_4 msvc tr1_has_nothrow_constr_test: cw-9_4 msvc tr1_has_nothrow_copy_test: cw-9_4 msvc tr1_has_tr1_ref_wrap_fail: cw-9_4 tr1_has_tr1_shared_ptr_fail: cw-9_4 tr1_has_tr1_tuple_fail: cw-9_4 tr1_has_trivial_assign_test: cw-9_4 msvc tr1_has_trivial_constr_test: cw-9_4 msvc tr1_has_trivial_copy_test: cw-9_4 msvc tr1_has_trivial_destructor_test: cw-9_4 msvc tr1_has_virtual_destructor_test: cw-9_4 msvc tr1_is_arithmetic_test: cw-9_4 msvc tr1_is_array_test: cw-9_4 msvc tr1_is_base_of_test: cw-9_4 msvc tr1_is_class_test: cw-9_4 msvc tr1_is_compound_test: cw-9_4 msvc tr1_is_const_test: cw-9_4 msvc tr1_is_convertible_test: cw-9_4 msvc tr1_is_empty_test: cw-9_4 msvc tr1_is_enum_test: cw-9_4 msvc tr1_is_floating_point_test: cw-9_4 msvc tr1_is_function_test: cw-9_4 msvc tr1_is_fundamental_test: cw-9_4 msvc tr1_is_integral_test: cw-9_4 msvc tr1_is_member_func_test: cw-9_4 msvc tr1_is_member_obj_test: cw-9_4 msvc tr1_is_member_pointer_test: cw-9_4 msvc tr1_is_object_test: cw-9_4 msvc tr1_is_pod_test: cw-9_4 msvc tr1_is_pointer_test: cw-9_4 msvc tr1_is_polymorphic_test: cw-9_4 msvc tr1_is_reference_test: cw-9_4 msvc tr1_is_same_test: cw-9_4 msvc tr1_is_scalar_test: cw-9_4 msvc tr1_is_signed_test: cw-9_4 msvc tr1_is_union_test: cw-9_4 msvc tr1_is_unsigned_test: cw-9_4 tr1_is_void_test: cw-9_4 msvc tr1_is_volatile_test: cw-9_4 msvc tr1_rank_test: cw-9_4 tr1_remove_all_extents_test: cw-9_4 tr1_remove_const_test: cw-9_4 tr1_remove_cv_test: cw-9_4 tr1_remove_extent_test: cw-9_4 tr1_remove_pointer_test: cw-9_4 tr1_remove_reference_test: cw-9_4 tr1_remove_volatile_test: cw-9_4 tr1_tricky_abstract_type_test: cw-9_4 msvc tr1_tricky_add_pointer_test: cw-9_4 msvc tr1_tricky_function_type_test: cw-9_4 msvc tr1_tricky_incomplete_type_test: cw-9_4 msvc tr1_tricky_is_enum_test: cw-9_4 tr1_tricky_partial_spec_test: cw-9_4 msvc |typeof| data_member_native: cw-9_4 function_native: cw-9_4 msvc function_ptr_native: cw-9_4 function_ref_native: cw-9_4 lvalue_native: cw-9_4 msvc member_function_native: cw-9_4 modifiers_emulation: cw-9_4 cw-9_4 modifiers_native: cw-9_4 cw-9_4 noncopyable_native: cw-9_4 std_emulation: cw-9_4 cw-9_4 std_native: cw-9_4 template_dependent_native: cw-9_4 template_enum_native: cw-9_4 template_int_native: cw-9_4 template_multiword_native: cw-9_4 template_tpl_native: cw-9_4 msvc template_type_native: cw-9_4 type_native: cw-9_4 |wave| testwave: cw-9_4 vc-7_1 testwave_dll: cw-9_4 vc-7_1 |xpressive| misc1: cw-9_4 test1: cw-9_4 test1u: cw-9_4 test2: cw-9_4 test2u: cw-9_4 test3: cw-9_4 test3u: cw-9_4 test4: cw-9_4 test4u: cw-9_4 test5: cw-9_4 test5u: cw-9_4 test6: cw-9_4 test6u: cw-9_4 test7: cw-9_4 test7u: cw-9_4 test8: cw-9_4 test8u: cw-9_4 test9: cw-9_4 test9u: cw-9_4 test_cycles: cw-9_4 test_dynamic: cw-9_4 test_non_char: cw-9_4 test_regex_primitives: cw-9_4 test_static: cw-9_4

4 15