- Boost - lists.boost.org

Re: [boost] ptr_container: ptr_map_adapter interface
by axter 04 Jan '06

04 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dpdofv$434$1(a)sea.gmane.org>... > axter wrote: > > > > "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > > news:<dpbv9p$k15$1(a)sea.gmane.org>... > > > >>axter wrote: > >>>>From my test, it doesn't seem as though ptr_map has consistent and > >>> > >>>>reliable > >>> > >>>implementation. > >> > >>Do you care to explain in detail what that means? > > > > > > One of the reasons to use pointers, is so that you don't have object > > slicing. ptr_map is a container of pointers, but you still get > > object slicing. IMHO, that inconsistent at best, and unreliable at > > worse. > > >>>4. When assigning value via operator[] from one container to > >>>another, you get object splicing for derived types > >>So? > > > > See above comment: > This is your own fault....you should make your class hierarchy > noncopyable by default. So are you saying, that in order to safely use ptr_map, the class hierarchy needs to be noncopyable by default? If so, I would see that as a justification for favoring the use of the cow_ptr smart pointers over using ptr_map, since the cow_ptr does not have such a restriction for it's safe usage. > If you really want to assign the pointers, then use replace(). > > > > >>>5. It doesn't seem to compile on VC++ 6.0, and when it compiles on > >>>VC++ 7.1 you get compiler warnings > >> > >>Yes, vc7.1 warns about a lot of things, particular ADL. Turn it off. > >> I agree that the VC7.1 warnings are BS. However, I think most developers would prefer to use code that doesn't require turning of any warnings. > >>>If you use cow_ptr instead, you don't have the above problems. > >>> > >>>There are similar problems in the boost::ptr_set class, which also > >>>can be replaced with cow_ptr or copy_ptr std::set<cow_ptr<foo> > > >>>MyPtrSet; > >>> > >>>IMHO, the entire boost pointer container set of classes can be > >>>replace with either cow_ptr and/or copy_ptr, and the result would > >>>be a more reliable, > >> > >>reliable in what way? > > > > > > Reliable in that you get expected interface when compiling. Reliable > > in that you get expected behavior at runtime. > > I think you would use the term "familiar" here. Reliability for me > implies safety or performance guarantees. > For me it implies safety, and in the test I performed these containers do not work safely, because they crash or perform unexpected behavior like object splicing. It takes a lot of work to get containers right, and it just not practical to expect one programmer to be able to put together a set of containers that are going to safely emulate (or closely emulate) all the main STL containers, and be able to work properly in all the main stream compilers. (VC++6.0, 7.0, 7.1, 8.x, GNU 3.x, 4.0, Borland 5.x, Intel, Comeau, etc..). IMHO, it's far easier and safer to develop a safe smart pointer that can be used with the existing safe, reliable, and well tested STL containers. It's also easier for a user to learn how to use a container of smart pointers who's container interface matches that which they're already familiar with. > >>Switching to a deep-copying smart pointer can have significant > >>performance implications, particularly (but not only) with compilers > >>without RTO, like vc6. > >> > > > > > > VC6 doesn't even compile using the boost::ptr_map or > > boost::ptr_set?..... > > well, it's basically an ancient compiler and I don't have the > resources to port to it anymore. > > > You can eliminate performance implications by using a deep-copying > > smart pointer like the cow_ptr, which I previously posted. Moreover, > > I wouldn't be surprise if the cow_ptr was able to out perform the > > boost pointer containers. > > I would. COW doesn't have a good reputation. I try not to deal with reputations, and deal with facts. I rather take a more scientific approach, which involves testing and measuring. You can not measure reputation.

2 1

Re: [boost] ptr_container: ptr_map_adapter interface
by axter 04 Jan '06

04 Jan '06

"bwood" <brass(a)mailvault.com> wrote in message news:<20060103232237.47DB9B64A52(a)gateway.mailvault.com>... > Thorsten Ottosen wrote: > >> You can eliminate performance implications by using a deep-copying > smart > >> pointer like the cow_ptr, which I previously posted. Moreover, I > >> wouldn't be surprise if the cow_ptr was able to out > perform the > >> boost pointer containers. > > >I would. COW doesn't have a good reputation. > > I agree with Thorsten and will be interested in the results of the > tests. I think the ptr_containers need more work, but I don't think > they should be replaced because something might be better. If an > alternative proves to be better and is adopted by people, the > ptr_containers will not be used and will be a footnote in history. In > the meantime I think the competition between approaches is > interesting. > > Brian > www.webEbenezer.net > > I don't think the pointer containers should be removed from the boost library. (At least not the vector, list, and deque). I don't think that using cow_ptr or copy_ptr will be a completely win-win situation. I predict that the boost pointer containers will do better at memory management, although I have not yet developed a good test for this. Also, I do like the interface ptr_vector has via it's iterators, in that you don't have to dereference the iterator in order to access the pointee. I think the cow_ptr should be used as the default method for creating containers of pointers, and that the current boost pointer containers should be used when memory management is the more important factor for a particular requirement. I'm not sure about the ptr_set and ptr_map classes, because I haven't seen any example code usage that would have it work with an abstract type. From my test so far, it seems that they're interface is too different from their STL counter parts, and the logic does not seem to be consistent with the other pointer containers, nor with each other. Hopefully, someone here can provide me with some working example code.

2 1

Re: [boost] ptr_container: ptr_map_adapter interface
by axter 04 Jan '06

04 Jan '06

-----Original Message----- From: a3 [mailto:a3@axter.com] Sent: Tuesday, January 03, 2006 7:44 PM To: boost(a)lists.boost.org Subject: Re: ptr_container: ptr_map_adapter interface "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dpdofv$434$1(a)sea.gmane.org>... > axter wrote: > > > > "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > > news:<dpbv9p$k15$1(a)sea.gmane.org>... > > > >>axter wrote: > >>>>From my test, it doesn't seem as though ptr_map has consistent and > >>> > >>>>reliable > >>> > >>>implementation. > >> > >>Do you care to explain in detail what that means? > > > > > > One of the reasons to use pointers, is so that you don't have object > > slicing. ptr_map is a container of pointers, but you still get > > object slicing. IMHO, that inconsistent at best, and unreliable at > > worse. > > >>>4. When assigning value via operator[] from one container to > >>>another, you get object splicing for derived types > >>So? > > > > See above comment: > This is your own fault....you should make your class hierarchy > noncopyable by default. So are you saying, that in order to safely use ptr_map, the class hierarchy needs to be noncopyable by default? If so, I would see that as a justification for favoring the use of the cow_ptr smart pointers over using ptr_map, since the cow_ptr does not have such a restriction for it's safe usage. > If you really want to assign the pointers, then use replace(). > > > > >>>5. It doesn't seem to compile on VC++ 6.0, and when it compiles on > >>>VC++ 7.1 you get compiler warnings > >> > >>Yes, vc7.1 warns about a lot of things, particular ADL. Turn it off. > >> I agree that the VC7.1 warnings are BS. However, I think most developers would prefer to use code that doesn't require turning of any warnings. > >>>If you use cow_ptr instead, you don't have the above problems. > >>> > >>>There are similar problems in the boost::ptr_set class, which also > >>>can be replaced with cow_ptr or copy_ptr std::set<cow_ptr<foo> > > >>>MyPtrSet; > >>> > >>>IMHO, the entire boost pointer container set of classes can be > >>>replace with either cow_ptr and/or copy_ptr, and the result would > >>>be a more reliable, > >> > >>reliable in what way? > > > > > > Reliable in that you get expected interface when compiling. Reliable > > in that you get expected behavior at runtime. > > I think you would use the term "familiar" here. Reliability for me > implies safety or performance guarantees. > For me it implies safety, and in the test I performed these containers do not work safely, because they crash or perform unexpected behavior like object splicing. It takes a lot of work to get containers right, and it just not practical to expect one programmer to be able to put together a set of containers that are going to safely emulate (or closely emulate) all the main STL containers, and be able to work properly in all the main stream compilers. (VC++6.0, 7.0, 7.1, 8.x, GNU 3.x, 4.0, Borland 5.x, Intel, Comeau, etc..). IMHO, it's far easier and safer to develop a safe smart pointer that can be used with the existing safe, reliable, and well tested STL containers. It's also easier for a user to learn how to use a container of smart pointers who's container interface matches that which they're already familiar with. > >>Switching to a deep-copying smart pointer can have significant > >>performance implications, particularly (but not only) with compilers > >>without RTO, like vc6. > >> > > > > > > VC6 doesn't even compile using the boost::ptr_map or > > boost::ptr_set?..... > > well, it's basically an ancient compiler and I don't have the > resources to port to it anymore. > > > You can eliminate performance implications by using a deep-copying > > smart pointer like the cow_ptr, which I previously posted. Moreover, > > I wouldn't be surprise if the cow_ptr was able to out perform the > > boost pointer containers. > > I would. COW doesn't have a good reputation. I try not to deal with reputations, and deal with facts. I rather take a more scientific approach, which involves testing and measuring. You can not measure reputation.

1 0

Re: [boost] ptr_container: ptr_map_adapter interface
by axter 04 Jan '06

04 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news: <news:%3cdpeb1m$3cl$1@sea.gmane.org> <dpeb1m$3cl$1(a)sea.gmane.org>... > > 4. ptr_vector produces a runtime error when assigning one container to > > another via operator[] > > I need to see an as small as possible test that shows this. Given that > you prohibit slicing (by declaring an explicit copy constructor or by > removing copyability totally) it might be due to this. I posted a link with all the test code, which is split up with comments: See following link: http://code.axter.com/BoostPtrContainerTestCode.zip All the classes have copy constructors. Here's the section of code which I pulled from above link: #ifdef INCLUDE_CODE_THAT_WILL_CAUSE_RUNTIME_FAILURE_ //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// //boost::ptr_vector fails assignment test because, //the following code will produce a runtime failure for(i = 0;i < ContainerOfOriginalShapes.size();++i) CopyViaContainerForLoopOp[i] = ContainerOfOriginalShapes[i]; //-------------------------------------------------------------------------- --------------------------------------------------- //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// #endif //INCLUDE_CODE_THAT_WILL_CAUSE_RUNTIME_FAILURE_ I believe the runtime error occurs on the destructor of the containers after performing the above logic. > > 5. Produces multiple compiler warnings when using VC++ 7.1 > > Yes. Vc7.1 and other compilers warn against far too much. ADL for > example. > > > 6. Will fail to clone the right type if a derived-derived type fails to > > implement the clone method. > > There is no magic like in shared_ptr here. That would impose some > overhead. Shared_ptr would not clone the type, and instead share the object, which is what you're trying to avoid with a container of pointers. > > > 7. Does not have the standard vector::assign member function that takes > > (size_type, const Type&) > > Might be possible to add, though the second argument might be an > auto_ptr, a bald pointer or a reference. > > I'm considering adding a little more initialization help > in boost.assign: > > http://www.boost.org/libs/assign/doc/index.html#ptr_push_back > > > 2. Can not insert using an abstract pointer. > > implement new_clone(). Can you provide an example? I don't see any examples for using these containers with an abstract pointer in the boost links. > > > 3. Can not find using an abstract pointer. > > please produce a minimal example after implmenting new_clone(). Again, need example usage. > > > 4. Crashes when inserting via de-referenced iterator from another > > container > > ditto. See previously posted link. > > > 5. boost::ptr_set is publicly derived from boost::ptr_set_adapter, > > however ptr_set_adapter does not have a virtual function, nor does > > any of it's base classes. > > The classes are not copyable, so you won't run into slicing problems. > The inheritance is purely for inheriting implementation. I see. I will remove this item from my list. > > > 6. Fails to compile when used with ptr_set::const_reverse_iterator > > logic > > please produce a minimal example. Here's the section of code which I pulled from above link: typedef boost::ptr_map<int, BaseNotAbstract> ContainerTypeBaseNotAbstract; #ifdef INCLUDE_CODE_THAT_DOES_NOT_COMPILE_ //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// //Instead of using first and second iterator members, boost::ptr_map uses operator-> and key() functions to access first and second. However, it still fails to compile when using const_reverse_iterator, so //the following lines of code will not compile: for(ContainerTypeBaseNotAbstract::const_reverse_iterator r_c_iter = mIntToBase.rbegin();r_c_iter != mIntToBase.rend();++r_c_iter) { r_c_iter->GetData(); } //-------------------------------------------------------------------------- --------------------------------------------------- //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// #endif //INCLUDE_CODE_THAT_DOES_NOT_COMPILE_ typedef boost::ptr_set<Shape> ContainerTypeIntToShape; #ifdef INCLUDE_CODE_THAT_DOES_NOT_COMPILE_ //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// //Fails to compile when used with ptr_set::const_reverse_iterator logic for (ContainerTypeIntToShape::const_reverse_iterator i = setShape.rbegin();i != setShape.rend();++i) i->draw(); //-------------------------------------------------------------------------- --------------------------------------------------- //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// #endif //INCLUDE_CODE_THAT_DOES_NOT_COMPILE_ You should be able to duplicate this compile error very easily. > > > boost::ptr_map > > 1. Unable to compile with an abstract type > > implement new_clone(); Again, need example usage. > > > 2. Does not have an insert type for std::pair > > and cannot provide one without allowing memory leaks. > > > 3. Can not insert using a constant for 1st argument > > ditto. > > > 5. Does not support the pointer as the key type > > right. use shared_ptr or something then. Shared_ptr does not give you cloning logic. Using the cow_ptr or the copy_ptr, you do get cloning logic, and you do get support for the pointer as the key type. > > > 6. Fails to compile insert to iterator type > > please produce minimal example. Here's the section of code which I pulled from the posted link: #ifdef INCLUDE_CODE_THAT_DOES_NOT_COMPILE_ //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// //boost::ptr_map::insert fails to compile with an iterator or const_iterator, the following //line of code will not compile: ContainerTypeBaseNotAbstract mIntToBase2; for (ContainerTypeBaseNotAbstract::const_iterator i = mIntToBase.begin();i != mIntToBase.end();++i) mIntToBase2.insert(i); for (ContainerTypeBaseNotAbstract::iterator i = mIntToBase.begin();i != mIntToBase.end();++i) mIntToBase2.insert(i); //-------------------------------------------------------------------------- --------------------------------------------------- //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// #endif //INCLUDE_CODE_THAT_DOES_NOT_COMPILE_ Again, you should be able to duplicate this compile error very easily. > > > 7. ptr_map::equal_range does not return std::pair<iterator, iterator> > > type as does the standard map::equal_range > > nor does it need to. the two classes are used in vastly different > domains and so generic code working with them both is an illusion. I still see this as a detraction from using the ptr_map container, since it requires knowledge of a different interface. It's easier for a developer to pickup on a class that uses the same interface as an existing well known class. A developer can learn how to use std::map<int, cow_ptr<T> > much faster then using boost::ptr_map, because they don't have to learn a new container interface. > > > 8. Does not use the standard first and second iterator members as does > > the standard map::iterator > > right, you're not allowed access to the pointer. > > > 9. Instead of using first and second iterator members, boost::ptr_map > > uses operator-> and key() functions to access first and second. > > However, it still fails to compile when using > > const_reverse_iterator. > > A minimal example is appreciated. Here's the section of code which I pulled from the posted link: #ifdef INCLUDE_CODE_THAT_DOES_NOT_COMPILE_ //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// //Instead of using first and second iterator members, boost::ptr_map uses operator-> and key() functions to access first and second. However, it still fails to compile when using const_reverse_iterator, so //the following lines of code will not compile: for(ContainerTypeBaseNotAbstract::const_reverse_iterator r_c_iter = mIntToBase.rbegin();r_c_iter != mIntToBase.rend();++r_c_iter) { r_c_iter->GetData(); } //-------------------------------------------------------------------------- --------------------------------------------------- //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////// #endif //INCLUDE_CODE_THAT_DOES_NOT_COMPILE_ Could you please provide some example usage code for ptr_set and ptr_map with an abstract pointer type. I highly recommend adding example code on the boost link.

1 0

Re: [boost] ptr_container: ptr_map_adapter interface
by bwood 04 Jan '06

04 Jan '06

Thorsten Ottosen wrote: >> You can eliminate performance implications by using a deep-copying smart >> pointer like the cow_ptr, which I previously posted. >> Moreover, I wouldn't be surprise if the cow_ptr was able to out perform the >> boost pointer containers. >I would. COW doesn't have a good reputation. I agree with Thorsten and will be interested in the results of the tests. I think the ptr_containers need more work, but I don't think they should be replaced because something might be better. If an alternative proves to be better and is adopted by people, the ptr_containers will not be used and will be a footnote in history. In the meantime I think the competition between approaches is interesting. Brian www.webEbenezer.net

2 1

[fusion-2]: Problems with as_map on empty views
by Andreas Pokorny 03 Jan '06

03 Jan '06

Hi there, I have a slight problem with the construction of a map with fusion::as_map on an empty view: #include <boost/fusion/sequence/class/map.hpp> #include <boost/fusion/sequence/view/filter_view.hpp> #include <boost/fusion/sequence/conversion/as_map.hpp> #include <boost/fusion/core/pair.hpp> struct drop_all {template <typename A> struct apply : boost::mpl::false_ {};}; int main() { using namespace boost::fusion; typedef map<pair<int,int>,pair<float,int>, pair<short,int> > my_map; typedef filter_view<my_map, drop_all> empty_view; typedef meta::as_map<empty_view>::type empty_map; my_map source; empty_view empty_source( source ); empty_map obj( as_map( empty_source) ); } Should I check if the view is empty before running as_map? I had a related problem, which I am right now unable to minimize. Somehow filter and transform views seem to call the meta functions with mpl::void_ and fusion::void_. Regards, Andreas Pokorny

3 5

Re: [boost] ptr_container: ptr_map_adapter interface
by axter 03 Jan '06

03 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dpbv9p$k15$1(a)sea.gmane.org>... > axter wrote: > > "Slawomir Lisznianski" <public(a)paramay.com> wrote in message > > news:<donook$li2$1(a)sea.gmane.org>... > > > >>Hello, > >> > >>I've been using ptr_map lately and have a few questions regarding > >>its interface. > >> > >>Below is a signature of `insert' function as declared in > >>ptr_map_adapter: > >> > >>std::pair<iterator,bool> insert( key_type& k, value_type x ); > >> > >>Why is `k' a non-const reference? > > it's a matter about exception-safety. > > see the FAQ. > > >>To imply ownership transfer, couldn't `x' be of > >>`std::auto_ptr<value_type>' type instead? > > right. the next release will have overloads taking auto_ptr<T> as well > as T*. > > >>What happend to std::pair as an argument of insert? Was symmetry > >>with std::map dropped for a reason here? > >> > > yes, exception-safety. > > >>From my test, it doesn't seem as though ptr_map has consistent and > >>reliable > > implementation. > > Do you care to explain in detail what that means? One of the reasons to use pointers, is so that you don't have object slicing. ptr_map is a container of pointers, but you still get object slicing. IMHO, that inconsistent at best, and unreliable at worse. > > > I recommend that boost replace the pointer containers with the > > following smart pointers: http://code.axter.com/copy_ptr.h > > http://code.axter.com/cow_ptr.h > > > > Example usage: > > std::map<int, cow_ptr<foo> > MyPtrMap; > > > > The above type gives you more functionality then the boost::ptr_map > > type, and of course, it's interface matches the std::map interface. > > Where as the boost::ptr_map type has the following problems: 1. > > Doesn't allow you to use an abstract pointer > > Really? > > > 2. Requires a non-constant argument for the insert function > > Right, to give exception-safety. > > > 3. Requires value semantics for the operator[] function > > ? > > > 4. When assigning value via operator[] from one container to > > another, you get object splicing for derived types > > So? See above comment: > > > 5. It doesn't seem to compile on VC++ 6.0, and when it compiles on > > VC++ 7.1 you get compiler warnings > > Yes, vc7.1 warns about a lot of things, particular ADL. Turn it off. > > > If you use cow_ptr instead, you don't have the above problems. > > > > There are similar problems in the boost::ptr_set class, which also > > can be replaced with cow_ptr or copy_ptr std::set<cow_ptr<foo> > > > MyPtrSet; > > > > IMHO, the entire boost pointer container set of classes can be > > replace with either cow_ptr and/or copy_ptr, and the result would be > > a more reliable, > > reliable in what way? Reliable in that you get expected interface when compiling. Reliable in that you get expected behavior at runtime. > > Switching to a deep-copying smart pointer can have significant > performance implications, particularly (but not only) with compilers > without RTO, like vc6. > VC6 doesn't even compile using the boost::ptr_map or boost::ptr_set?..... You can eliminate performance implications by using a deep-copying smart pointer like the cow_ptr, which I previously posted. Moreover, I wouldn't be surprise if the cow_ptr was able to out perform the boost pointer containers. I'm currently working on making a comparison between the boost pointer containers and copy_ptr/cow_ptr. I also plan to do performance test, so that the comparison will be more complete. Below I list some of the issues found using the boost pointer containers. Some of the issues are by design, and some are not. Whether it's by design or not, I still consider the issues relevant in a comparison. The test was performed using boost_1_33_0 and VC++ 7.1, 6.0, and GNU 3.x. You can download the test code via following link: http://code.axter.com/BoostPtrContainerTestCode.zip The current test code is a little hard to read, but once I'm completely done with all the test, I will clean it up. Please feel free to correct me on any of the items listed below. Most of the items listed below, you'll find relevant comments in the above test code. Boost::ptr_vector 1. The constructor that takes two iterators fails to compile on VC++ 6.0 2. Fails to include a copy constructor (by design) 3. ptr_vector::push_back fails to compile with a de-referenced iterator 4. ptr_vector produces a runtime error when assigning one container to another via operator[] 5. Produces multiple compiler warnings when using VC++ 7.1 6. Will fail to clone the right type if a derived-derived type fails to implement the clone method. 7. Does not have the standard vector::assign member function that takes (size_type, const Type&) boost::ptr_set 1. Fails to compile on VC++ 6.0 2. Can not insert using an abstract pointer. 3. Can not find using an abstract pointer. 4. Crashes when inserting via de-referenced iterator from another container 5. boost::ptr_set is publicly derived from boost::ptr_set_adapter, however ptr_set_adapter does not have a virtual function, nor does any of it's base classes. 6. Fails to compile when used with ptr_set::const_reverse_iterator logic boost::ptr_map 1. Unable to compile with an abstract type 2. Does not have an insert type for std::pair 3. Can not insert using a constant for 1st argument 4. Unable to compile on VC++ 6.0 5. Does not support the pointer as the key type 6. Fails to compile insert to iterator type 7. ptr_map::equal_range does not return std::pair<iterator, iterator> type as does the standard map::equal_range 8. Does not use the standard first and second iterator members as does the standard map::iterator 9. Instead of using first and second iterator members, boost::ptr_map uses operator-> and key() functions to access first and second. However, it still fails to compile when using const_reverse_iterator.

2 2

Boost regression notification (2006-01-03 [HEAD])
by Douglas Gregor 03 Jan '06

03 Jan '06

Boost Regression test failures Report time: 2006-01-03T15:18:20Z This report lists all regression test failures on release platforms. Detailed report: http://engineering.meta-comm.com/boost-regression/CVS-HEAD/developer/issues… The following platforms have a large number of failures: gcc-3.2.3-linux 1147 failures in 22 libraries (563 are from non-broken platforms) random (1) concept_check (19 of 20 failures are from non-broken platforms) iostreams (22) conversion (5) graph (8 of 9 failures are from non-broken platforms) numeric/interval (3) program_options (7) rational (9) tr1 (192 of 194 failures are from non-broken platforms) parameter (12) math (0 of 1 failures are from non-broken platforms) wave (14 of 17 failures are from non-broken platforms) test (15 of 16 failures are from non-broken platforms) serialization (168 of 598 failures are from non-broken platforms) spirit (0 of 98 failures are from non-broken platforms) xpressive (56 of 57 failures are from non-broken platforms) date_time (5 of 12 failures are from non-broken platforms) multi_array (8) multi_index (0 of 1 failures are from non-broken platforms) ptr_container (0 of 12 failures are from non-broken platforms) typeof (4) filesystem (36 of 41 failures are from non-broken platforms) Test failures marked with a (*) represent tests that failed on platforms that are considered broken. They are likely caused by misconfiguration by the regression tester or a failure in a core library such as Test or Config. |random| random_test: intel-9.0-linux |concept_check| stl_concept_covering: cw-9_4 cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux* gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-9.0-linux intel-win32-8_1 intel-win32-9_0 mingw-3_4_2 mingw-3_4_2 tru64cxx71-006 vc-7_1 vc-7_1 |iostreams| auto_close_test: tru64cxx71-006 code_converter_test: tru64cxx71-006 component_access_test: tru64cxx71-006 compose_test: tru64cxx71-006 copy_test: tru64cxx71-006 counter_test: tru64cxx71-006 example_test: tru64cxx71-006 filtering_stream_test: tru64cxx71-006 finite_state_filter_test: tru64cxx71-006 flush_test: tru64cxx71-006 invert_test: tru64cxx71-006 line_filter_test: tru64cxx71-006 newline_test: tru64cxx71-006 pipeline_test: tru64cxx71-006 regex_filter_test: tru64cxx71-006 restrict_test: tru64cxx71-006 seekable_file_test: tru64cxx71-006 seekable_filter_test: tru64cxx71-006 stdio_filter_test: tru64cxx71-006 symmetric_filter_test: tru64cxx71-006 tee_test: tru64cxx71-006 wide_stream_test: tru64cxx71-006 |conversion| lexical_cast_test: gcc-4_0-darwin intel-win32-8_1 intel-win32-9_0 vc-7_1 vc-7_1 |graph| csr_graph_test: cw-9_4 cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux dijkstra_heap_performance: cw-9_4 cw-9_5-darwin graphviz_test: gcc-3.2.3-linux* vc-7_1 vc-7_1 |numeric/interval| mul: tru64cxx71-006 overflow: tru64cxx71-006 pi: tru64cxx71-006 |program_options| cmdline_test_dll: cw-9_4 options_description_test_dll: cw-9_4 parsers_test_dll: cw-9_4 positional_options_test_dll: cw-9_4 unicode_test_dll: cw-9_4 variable_map_test_dll: cw-9_4 winmain_dll: cw-9_4 |rational| rational_test: cw-9_4 cw-9_5-darwin gcc-2.95.3-stlport-4.6.2-linux intel-9.0-linux intel-win32-8_1 intel-win32-9_0 tru64cxx71-006 vc-7_1 vc-7_1 |tr1| run_complex_overloads: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_run_complex_overloads: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_run_random: cw-9_4 cw-9_5-darwin std_test_array: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_test_bind: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_test_boost: tru64cxx71-006 std_test_complex: cw-9_4 cw-9_5-darwin std_test_function: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_test_hash: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_test_mem_fn: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_test_random: cw-9_4 cw-9_5-darwin std_test_reference_wrapper: tru64cxx71-006 std_test_regex: cw-9_4 cw-9_5-darwin std_test_result_of: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_test_shared_ptr: tru64cxx71-006 std_test_tr1_include: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_test_tuple: cw-9_4 cw-9_5-darwin tru64cxx71-006 std_test_type_traits: cw-9_4 cw-9_5-darwin gcc-3.2.3-linux* test_array: cw-9_4 test_complex: cw-9_4 cw-9_5-darwin test_deque: tru64cxx71-006 test_exception: gcc-2.95.3-stlport-4.6.2-linux test_function: cw-9_4 cw-9_5-darwin test_functional: tru64cxx71-006 test_list: tru64cxx71-006 test_memory: tru64cxx71-006 test_new: gcc-2.95.3-stlport-4.6.2-linux test_queue: tru64cxx71-006 test_random: cw-9_4 cw-9_5-darwin test_result_of: cw-9_4 cw-9_5-darwin test_stack: tru64cxx71-006 test_stdexcept: gcc-2.95.3-stlport-4.6.2-linux tru64cxx71-006 test_tr1_include: cw-9_4 cw-9_5-darwin test_tuple: cw-9_4 cw-9_5-darwin test_tuple_tricky: cw-9_4 cw-9_5-darwin test_type_traits: gcc-3.2.3-linux* test_typeinfo: tru64cxx71-006 test_vector: tru64cxx71-006 tr1_add_const_test: cw-9_4 cw-9_5-darwin tr1_add_cv_test: cw-9_4 cw-9_5-darwin tr1_add_pointer_test: cw-9_4 cw-9_5-darwin tr1_add_reference_test: cw-9_4 cw-9_5-darwin tr1_add_volatile_test: cw-9_4 cw-9_5-darwin tr1_aligned_storage_test: cw-9_4 cw-9_5-darwin tr1_alignment_of_test: cw-9_4 cw-9_5-darwin tr1_extent_test: cw-9_4 cw-9_5-darwin tr1_has_nothrow_assign_test: cw-9_4 cw-9_5-darwin tr1_has_nothrow_constr_test: cw-9_4 cw-9_5-darwin tr1_has_nothrow_copy_test: cw-9_4 cw-9_5-darwin tr1_has_tr1_ref_wrap_fail: cw-9_4 cw-9_5-darwin tr1_has_tr1_shared_ptr_fail: cw-9_4 cw-9_5-darwin tr1_has_tr1_tuple_fail: cw-9_4 cw-9_5-darwin tr1_has_trivial_assign_test: cw-9_4 cw-9_5-darwin tr1_has_trivial_constr_test: cw-9_4 cw-9_5-darwin tr1_has_trivial_copy_test: cw-9_4 cw-9_5-darwin tr1_has_trivial_destructor_test: cw-9_4 cw-9_5-darwin tr1_has_virtual_destructor_test: cw-9_4 cw-9_5-darwin tr1_is_arithmetic_test: cw-9_4 cw-9_5-darwin tr1_is_array_test: cw-9_4 cw-9_5-darwin tr1_is_base_of_test: cw-9_4 cw-9_5-darwin tr1_is_class_test: cw-9_4 cw-9_5-darwin tr1_is_compound_test: cw-9_4 cw-9_5-darwin tr1_is_const_test: cw-9_4 cw-9_5-darwin tr1_is_convertible_test: cw-9_4 cw-9_5-darwin tr1_is_empty_test: cw-9_4 cw-9_5-darwin tr1_is_enum_test: cw-9_4 cw-9_5-darwin tr1_is_floating_point_test: cw-9_4 cw-9_5-darwin tr1_is_function_test: cw-9_4 cw-9_5-darwin tr1_is_fundamental_test: cw-9_4 cw-9_5-darwin tr1_is_integral_test: cw-9_4 cw-9_5-darwin tr1_is_member_func_test: cw-9_4 cw-9_5-darwin tr1_is_member_obj_test: cw-9_4 cw-9_5-darwin tr1_is_member_pointer_test: cw-9_4 cw-9_5-darwin tr1_is_object_test: cw-9_4 cw-9_5-darwin tr1_is_pod_test: cw-9_4 cw-9_5-darwin tr1_is_pointer_test: cw-9_4 cw-9_5-darwin tr1_is_polymorphic_test: cw-9_4 cw-9_5-darwin tr1_is_reference_test: cw-9_4 cw-9_5-darwin tr1_is_same_test: cw-9_4 cw-9_5-darwin tr1_is_scalar_test: cw-9_4 cw-9_5-darwin tr1_is_signed_test: cw-9_4 cw-9_5-darwin tr1_is_union_test: cw-9_4 cw-9_5-darwin tr1_is_unsigned_test: cw-9_4 cw-9_5-darwin tr1_is_void_test: cw-9_4 cw-9_5-darwin tr1_is_volatile_test: cw-9_4 cw-9_5-darwin tr1_rank_test: cw-9_4 cw-9_5-darwin tr1_remove_all_extents_test: cw-9_4 cw-9_5-darwin tr1_remove_const_test: cw-9_4 cw-9_5-darwin tr1_remove_cv_test: cw-9_4 cw-9_5-darwin tr1_remove_extent_test: cw-9_4 cw-9_5-darwin tr1_remove_pointer_test: cw-9_4 cw-9_5-darwin tr1_remove_reference_test: cw-9_4 cw-9_5-darwin tr1_remove_volatile_test: cw-9_4 cw-9_5-darwin tr1_tricky_abstract_type_test: cw-9_4 cw-9_5-darwin tr1_tricky_add_pointer_test: cw-9_4 cw-9_5-darwin tr1_tricky_function_type_test: cw-9_4 cw-9_5-darwin tr1_tricky_incomplete_type_test: cw-9_4 cw-9_5-darwin tr1_tricky_is_enum_test: cw-9_4 cw-9_5-darwin tr1_tricky_partial_spec_test: cw-9_4 cw-9_5-darwin |parameter| basics: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux efficiency: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux macros: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux sfinae: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux tutorial: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux unnamed: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |math| log1p_expm1_test: gcc-3.2.3-linux* |wave| test_re2c_lexer: gcc-3.2.3-linux* gcc-3.3.6-linux gcc-3.4.4-linux intel-9.0-linux test_slex_lexer: gcc-3.2.3-linux* gcc-3.3.6-linux gcc-3.4.4-linux intel-9.0-linux testwave: cw-9_5-darwin gcc-3.4.4-linux intel-9.0-linux testwave_dll: cw-9_4 cw-9_5-darwin gcc-3.2.3-linux* gcc-3.3.6-linux gcc-3.4.4-linux intel-9.0-linux |test| test_fp_comparisons: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux test_tools_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux* gcc-3.3.6-linux gcc-3.3.6-linux gcc-3.4.4-linux gcc-3.4.4-linux gcc-3_3-darwin gcc-3_4_3-sunos gcc-4_0-darwin intel-9.0-linux mingw-3_4_2 mingw-3_4_2 tru64cxx71-006 |serialization| test_array_binary_archive: gcc-3.2.3-linux* test_array_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_array_text_archive: gcc-3.2.3-linux* test_array_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_array_text_warchive: gcc-3.2.3-linux* test_array_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_array_xml_archive: gcc-3.2.3-linux* test_array_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_array_xml_warchive: gcc-3.2.3-linux* test_array_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_binary_binary_archive: gcc-3.2.3-linux* test_binary_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_binary_text_archive: gcc-3.2.3-linux* test_binary_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_binary_text_warchive: gcc-3.2.3-linux* test_binary_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_binary_xml_archive: gcc-3.2.3-linux* test_binary_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_binary_xml_warchive: gcc-3.2.3-linux* test_binary_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_load_binary_archive: gcc-3.2.3-linux* test_class_info_load_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_load_text_archive: gcc-3.2.3-linux* test_class_info_load_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_load_text_warchive: gcc-3.2.3-linux* test_class_info_load_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_load_xml_archive: gcc-3.2.3-linux* test_class_info_load_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_load_xml_warchive: gcc-3.2.3-linux* test_class_info_load_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_save_binary_archive: gcc-3.2.3-linux* test_class_info_save_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_save_text_archive: gcc-3.2.3-linux* test_class_info_save_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_save_text_warchive: gcc-3.2.3-linux* test_class_info_save_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_save_xml_archive: gcc-3.2.3-linux* test_class_info_save_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_class_info_save_xml_warchive: gcc-3.2.3-linux* test_class_info_save_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_contained_class_binary_archive: gcc-3.2.3-linux* test_contained_class_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_contained_class_text_archive: gcc-3.2.3-linux* test_contained_class_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_contained_class_text_warchive: gcc-3.2.3-linux* test_contained_class_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_contained_class_xml_archive: gcc-3.2.3-linux* test_contained_class_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_contained_class_xml_warchive: gcc-3.2.3-linux* test_contained_class_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_cyclic_ptrs_binary_archive: gcc-3.2.3-linux* test_cyclic_ptrs_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_cyclic_ptrs_text_archive: gcc-3.2.3-linux* test_cyclic_ptrs_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_cyclic_ptrs_text_warchive: gcc-3.2.3-linux* test_cyclic_ptrs_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_cyclic_ptrs_xml_archive: gcc-3.2.3-linux* test_cyclic_ptrs_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_cyclic_ptrs_xml_warchive: gcc-3.2.3-linux* test_cyclic_ptrs_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_delete_pointer_binary_archive: gcc-3.2.3-linux* test_delete_pointer_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_delete_pointer_text_archive: gcc-3.2.3-linux* test_delete_pointer_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_delete_pointer_text_warchive: gcc-3.2.3-linux* test_delete_pointer_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_delete_pointer_xml_archive: gcc-3.2.3-linux* test_delete_pointer_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_delete_pointer_xml_warchive: gcc-3.2.3-linux* test_delete_pointer_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_demo: gcc-3.2.3-linux* test_demo_auto_ptr: gcc-3.2.3-linux* test_demo_auto_ptr_dll: cw-9_4 gcc-3.2.3-linux* test_demo_dll: gcc-3.2.3-linux* test_demo_exception: gcc-3.2.3-linux* test_demo_exception_dll: gcc-3.2.3-linux* test_demo_fast_archive: gcc-3.2.3-linux* test_demo_fast_archive_dll: cw-9_4 gcc-3.2.3-linux* test_demo_pimpl: gcc-3.2.3-linux* test_demo_pimpl_dll: cw-9_4 gcc-3.2.3-linux* test_demo_polymorphic: gcc-3.2.3-linux* test_demo_polymorphic_dll: cw-9_4 gcc-3.2.3-linux* test_demo_portable_archive: gcc-3.2.3-linux* test_demo_portable_archive_dll: cw-9_4 gcc-3.2.3-linux* test_demo_shared_ptr: gcc-3.2.3-linux* test_demo_shared_ptr_dll: gcc-3.2.3-linux* test_demo_xml: gcc-3.2.3-linux* test_demo_xml_dll: gcc-3.2.3-linux* test_demo_xml_load: gcc-3.2.3-linux* test_demo_xml_load_dll: gcc-3.2.3-linux* test_demo_xml_save: gcc-3.2.3-linux* test_demo_xml_save_dll: gcc-3.2.3-linux* test_deque_binary_archive: gcc-3.2.3-linux* test_deque_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_deque_text_archive: gcc-3.2.3-linux* test_deque_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_deque_text_warchive: gcc-3.2.3-linux* test_deque_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_deque_xml_archive: gcc-3.2.3-linux* test_deque_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_deque_xml_warchive: gcc-3.2.3-linux* test_deque_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_binary_archive: gcc-3.2.3-linux* test_derived_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_binary_archive: gcc-3.2.3-linux* test_derived_class_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_ptr_binary_archive: gcc-3.2.3-linux* test_derived_class_ptr_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_ptr_text_archive: gcc-3.2.3-linux* test_derived_class_ptr_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_ptr_text_warchive: gcc-3.2.3-linux* test_derived_class_ptr_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_ptr_xml_archive: gcc-3.2.3-linux* test_derived_class_ptr_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_ptr_xml_warchive: gcc-3.2.3-linux* test_derived_class_ptr_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_text_archive: gcc-3.2.3-linux* test_derived_class_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_text_warchive: gcc-3.2.3-linux* test_derived_class_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_xml_archive: gcc-3.2.3-linux* test_derived_class_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_class_xml_warchive: gcc-3.2.3-linux* test_derived_class_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_text_archive: gcc-3.2.3-linux* test_derived_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_text_warchive: gcc-3.2.3-linux* test_derived_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_xml_archive: gcc-3.2.3-linux* test_derived_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_derived_xml_warchive: gcc-3.2.3-linux* test_derived_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_diamond_binary_archive: gcc-3.2.3-linux* test_diamond_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_diamond_text_archive: gcc-3.2.3-linux* test_diamond_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_diamond_text_warchive: gcc-3.2.3-linux* test_diamond_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_diamond_xml_archive: gcc-3.2.3-linux* test_diamond_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_diamond_xml_warchive: gcc-3.2.3-linux* test_diamond_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_exported_binary_archive: gcc-3.2.3-linux* test_exported_binary_archive_dll: gcc-3.2.3-linux* test_exported_text_archive: gcc-3.2.3-linux* test_exported_text_archive_dll: gcc-3.2.3-linux* test_exported_text_warchive: gcc-3.2.3-linux* test_exported_text_warchive_dll: gcc-3.2.3-linux* test_exported_xml_archive: gcc-3.2.3-linux* test_exported_xml_archive_dll: gcc-3.2.3-linux* test_exported_xml_warchive: gcc-3.2.3-linux* test_exported_xml_warchive_dll: gcc-3.2.3-linux* test_list_binary_archive: gcc-3.2.3-linux* test_list_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_list_ptrs_binary_archive: gcc-3.2.3-linux* test_list_ptrs_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_list_ptrs_text_archive: gcc-3.2.3-linux* test_list_ptrs_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_list_ptrs_text_warchive: gcc-3.2.3-linux* test_list_ptrs_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_list_ptrs_xml_archive: gcc-3.2.3-linux* test_list_ptrs_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_list_ptrs_xml_warchive: gcc-3.2.3-linux* test_list_ptrs_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_list_text_archive: gcc-3.2.3-linux* test_list_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_list_text_warchive: gcc-3.2.3-linux* test_list_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_list_xml_archive: gcc-3.2.3-linux* test_list_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_list_xml_warchive: gcc-3.2.3-linux* test_list_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_map_binary_archive: gcc-3.2.3-linux* test_map_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_map_text_archive: gcc-3.2.3-linux* test_map_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_map_text_warchive: gcc-3.2.3-linux* test_map_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_map_xml_archive: gcc-3.2.3-linux* test_map_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_map_xml_warchive: gcc-3.2.3-linux* test_map_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_mi_binary_archive: gcc-3.2.3-linux* test_mi_binary_archive_dll: gcc-3.2.3-linux* test_mi_text_archive: gcc-3.2.3-linux* test_mi_text_archive_dll: gcc-3.2.3-linux* test_mi_text_warchive: gcc-3.2.3-linux* test_mi_text_warchive_dll: gcc-3.2.3-linux* test_mi_xml_archive: gcc-3.2.3-linux* test_mi_xml_archive_dll: gcc-3.2.3-linux* test_mi_xml_warchive: gcc-3.2.3-linux* test_mi_xml_warchive_dll: gcc-3.2.3-linux* test_mult_archive_types: gcc-3.2.3-linux* test_mult_archive_types_dll: gcc-3.2.3-linux* test_multiple_ptrs_binary_archive: gcc-3.2.3-linux* test_multiple_ptrs_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_multiple_ptrs_text_archive: gcc-3.2.3-linux* test_multiple_ptrs_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_multiple_ptrs_text_warchive: gcc-3.2.3-linux* test_multiple_ptrs_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_multiple_ptrs_xml_archive: gcc-3.2.3-linux* test_multiple_ptrs_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_multiple_ptrs_xml_warchive: gcc-3.2.3-linux* test_multiple_ptrs_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_no_rtti_binary_archive: gcc-3.2.3-linux* test_no_rtti_binary_archive_dll: gcc-3.2.3-linux* test_no_rtti_text_archive: gcc-3.2.3-linux* test_no_rtti_text_archive_dll: gcc-3.2.3-linux* test_no_rtti_text_warchive: gcc-3.2.3-linux* test_no_rtti_text_warchive_dll: gcc-3.2.3-linux* test_no_rtti_xml_archive: gcc-3.2.3-linux* test_no_rtti_xml_archive_dll: gcc-3.2.3-linux* test_no_rtti_xml_warchive: gcc-3.2.3-linux* test_no_rtti_xml_warchive_dll: gcc-3.2.3-linux* test_non_default_ctor2_binary_archive: gcc-3.2.3-linux* test_non_default_ctor2_binary_archive_dll: gcc-3.2.3-linux* test_non_default_ctor2_text_archive: gcc-3.2.3-linux* test_non_default_ctor2_text_archive_dll: gcc-3.2.3-linux* test_non_default_ctor2_text_warchive: gcc-3.2.3-linux* test_non_default_ctor2_text_warchive_dll: gcc-3.2.3-linux* test_non_default_ctor2_xml_archive: gcc-3.2.3-linux* test_non_default_ctor2_xml_archive_dll: gcc-3.2.3-linux* test_non_default_ctor2_xml_warchive: gcc-3.2.3-linux* test_non_default_ctor2_xml_warchive_dll: gcc-3.2.3-linux* test_non_default_ctor_binary_archive: gcc-3.2.3-linux* test_non_default_ctor_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_non_default_ctor_text_archive: gcc-3.2.3-linux* test_non_default_ctor_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_non_default_ctor_text_warchive: gcc-3.2.3-linux* test_non_default_ctor_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_non_default_ctor_xml_archive: gcc-3.2.3-linux* test_non_default_ctor_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_non_default_ctor_xml_warchive: gcc-3.2.3-linux* test_non_default_ctor_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_non_intrusive_binary_archive: gcc-3.2.3-linux* test_non_intrusive_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_non_intrusive_text_archive: gcc-3.2.3-linux* test_non_intrusive_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_non_intrusive_text_warchive: gcc-3.2.3-linux* test_non_intrusive_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_non_intrusive_xml_archive: gcc-3.2.3-linux* test_non_intrusive_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_non_intrusive_xml_warchive: gcc-3.2.3-linux* test_non_intrusive_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_null_ptr_binary_archive: gcc-3.2.3-linux* test_null_ptr_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_null_ptr_text_archive: gcc-3.2.3-linux* test_null_ptr_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_null_ptr_text_warchive: gcc-3.2.3-linux* test_null_ptr_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_null_ptr_xml_archive: gcc-3.2.3-linux* test_null_ptr_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_null_ptr_xml_warchive: gcc-3.2.3-linux* test_null_ptr_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_nvp_binary_archive: gcc-3.2.3-linux* test_nvp_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_nvp_text_archive: gcc-3.2.3-linux* test_nvp_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_nvp_text_warchive: gcc-3.2.3-linux* test_nvp_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_nvp_xml_archive: gcc-3.2.3-linux* test_nvp_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_nvp_xml_warchive: gcc-3.2.3-linux* test_nvp_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_object_binary_archive: gcc-3.2.3-linux* test_object_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_object_text_archive: gcc-3.2.3-linux* test_object_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_object_text_warchive: gcc-3.2.3-linux* test_object_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_object_xml_archive: gcc-3.2.3-linux* test_object_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_object_xml_warchive: gcc-3.2.3-linux* test_object_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_optional_binary_archive: gcc-3.2.3-linux* test_optional_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_optional_text_archive: gcc-3.2.3-linux* test_optional_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_optional_text_warchive: gcc-3.2.3-linux* test_optional_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_optional_xml_archive: gcc-3.2.3-linux* test_optional_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_optional_xml_warchive: gcc-3.2.3-linux* test_optional_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_polymorphic_binary_archive: gcc-3.2.3-linux* test_polymorphic_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_polymorphic_text_archive: gcc-3.2.3-linux* test_polymorphic_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_polymorphic_text_warchive: gcc-3.2.3-linux* test_polymorphic_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_polymorphic_xml_archive: gcc-3.2.3-linux* test_polymorphic_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_polymorphic_xml_warchive: gcc-3.2.3-linux* test_polymorphic_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_primitive_binary_archive: gcc-3.2.3-linux* test_primitive_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_primitive_text_archive: gcc-3.2.3-linux* test_primitive_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_primitive_text_warchive: gcc-3.2.3-linux* test_primitive_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_primitive_xml_archive: gcc-3.2.3-linux* test_primitive_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_primitive_xml_warchive: gcc-3.2.3-linux* test_primitive_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_private_ctor: gcc-3.2.3-linux* test_private_ctor_dll: cw-9_4 gcc-3.2.3-linux* test_recursion_binary_archive: gcc-3.2.3-linux* test_recursion_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_recursion_text_archive: gcc-3.2.3-linux* test_recursion_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_recursion_text_warchive: gcc-3.2.3-linux* test_recursion_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_recursion_xml_archive: gcc-3.2.3-linux* test_recursion_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_recursion_xml_warchive: gcc-3.2.3-linux* test_recursion_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_registered_binary_archive: gcc-3.2.3-linux* test_registered_binary_archive_dll: gcc-3.2.3-linux* test_registered_text_archive: gcc-3.2.3-linux* test_registered_text_archive_dll: gcc-3.2.3-linux* test_registered_text_warchive: gcc-3.2.3-linux* test_registered_text_warchive_dll: gcc-3.2.3-linux* test_registered_xml_archive: gcc-3.2.3-linux* test_registered_xml_archive_dll: gcc-3.2.3-linux* test_registered_xml_warchive: gcc-3.2.3-linux* test_registered_xml_warchive_dll: gcc-3.2.3-linux* test_reset_object_address: gcc-3.2.3-linux* test_reset_object_address_dll: cw-9_4 gcc-3.2.3-linux* test_set_binary_archive: gcc-3.2.3-linux* test_set_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_set_text_archive: gcc-3.2.3-linux* test_set_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_set_text_warchive: gcc-3.2.3-linux* test_set_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_set_xml_archive: gcc-3.2.3-linux* test_set_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_set_xml_warchive: gcc-3.2.3-linux* test_set_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_shared_ptr_132_binary_archive: gcc-3.2.3-linux* test_shared_ptr_132_binary_archive_dll: gcc-3.2.3-linux* test_shared_ptr_132_text_archive: gcc-3.2.3-linux* test_shared_ptr_132_text_archive_dll: gcc-3.2.3-linux* test_shared_ptr_132_text_warchive: gcc-3.2.3-linux* test_shared_ptr_132_text_warchive_dll: gcc-3.2.3-linux* test_shared_ptr_132_xml_archive: gcc-3.2.3-linux* test_shared_ptr_132_xml_archive_dll: gcc-3.2.3-linux* test_shared_ptr_132_xml_warchive: gcc-3.2.3-linux* test_shared_ptr_132_xml_warchive_dll: gcc-3.2.3-linux* test_shared_ptr_binary_archive: gcc-3.2.3-linux* test_shared_ptr_binary_archive_dll: gcc-3.2.3-linux* test_shared_ptr_text_archive: gcc-3.2.3-linux* test_shared_ptr_text_archive_dll: gcc-3.2.3-linux* test_shared_ptr_text_warchive: gcc-3.2.3-linux* test_shared_ptr_text_warchive_dll: gcc-3.2.3-linux* test_shared_ptr_xml_archive: gcc-3.2.3-linux* test_shared_ptr_xml_archive_dll: gcc-3.2.3-linux* test_shared_ptr_xml_warchive: gcc-3.2.3-linux* test_shared_ptr_xml_warchive_dll: gcc-3.2.3-linux* test_simple_class_binary_archive: gcc-3.2.3-linux* test_simple_class_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_ptr_binary_archive: gcc-3.2.3-linux* test_simple_class_ptr_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_ptr_text_archive: gcc-3.2.3-linux* test_simple_class_ptr_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_ptr_text_warchive: gcc-3.2.3-linux* test_simple_class_ptr_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_ptr_xml_archive: gcc-3.2.3-linux* test_simple_class_ptr_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_ptr_xml_warchive: gcc-3.2.3-linux* test_simple_class_ptr_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_text_archive: gcc-3.2.3-linux* test_simple_class_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_text_warchive: gcc-3.2.3-linux* test_simple_class_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_xml_archive: gcc-3.2.3-linux* test_simple_class_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_simple_class_xml_warchive: gcc-3.2.3-linux* test_simple_class_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_split_binary_archive: gcc-3.2.3-linux* test_split_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_split_text_archive: gcc-3.2.3-linux* test_split_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_split_text_warchive: gcc-3.2.3-linux* test_split_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_split_xml_archive: gcc-3.2.3-linux* test_split_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_split_xml_warchive: gcc-3.2.3-linux* test_split_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_tracking_binary_archive: gcc-3.2.3-linux* test_tracking_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_tracking_text_archive: gcc-3.2.3-linux* test_tracking_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_tracking_text_warchive: gcc-3.2.3-linux* test_tracking_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_tracking_xml_archive: gcc-3.2.3-linux* test_tracking_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_tracking_xml_warchive: gcc-3.2.3-linux* test_tracking_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_unregistered_binary_archive: gcc-3.2.3-linux* test_unregistered_binary_archive_dll: gcc-3.2.3-linux* test_unregistered_text_archive: gcc-3.2.3-linux* test_unregistered_text_archive_dll: gcc-3.2.3-linux* test_unregistered_text_warchive: gcc-3.2.3-linux* test_unregistered_text_warchive_dll: gcc-3.2.3-linux* test_unregistered_xml_archive: gcc-3.2.3-linux* test_unregistered_xml_archive_dll: gcc-3.2.3-linux* test_unregistered_xml_warchive: gcc-3.2.3-linux* test_unregistered_xml_warchive_dll: gcc-3.2.3-linux* test_variant_binary_archive: gcc-3.2.3-linux* test_variant_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_variant_text_archive: gcc-3.2.3-linux* test_variant_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_variant_text_warchive: gcc-3.2.3-linux* test_variant_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_variant_xml_archive: gcc-3.2.3-linux* test_variant_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_variant_xml_warchive: gcc-3.2.3-linux* test_variant_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_vector_binary_archive: gcc-3.2.3-linux* test_vector_binary_archive_dll: cw-9_4 gcc-3.2.3-linux* test_vector_text_archive: gcc-3.2.3-linux* test_vector_text_archive_dll: cw-9_4 gcc-3.2.3-linux* test_vector_text_warchive: gcc-3.2.3-linux* test_vector_text_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_vector_xml_archive: gcc-3.2.3-linux* test_vector_xml_archive_dll: cw-9_4 gcc-3.2.3-linux* test_vector_xml_warchive: gcc-3.2.3-linux* test_vector_xml_warchive_dll: cw-9_4 gcc-3.2.3-linux* test_void_cast: gcc-3.2.3-linux* test_void_cast_dll: cw-9_4 gcc-3.2.3-linux* |spirit| action_tests: gcc-3.2.3-linux* action_tests_debug: gcc-3.2.3-linux* ast_calc_tests: gcc-3.2.3-linux* ast_calc_tests_debug: gcc-3.2.3-linux* bug_000008: gcc-3.2.3-linux* bug_fixes: gcc-3.2.3-linux* bug_fixes_debug: gcc-3.2.3-linux* char_strings_test: gcc-3.2.3-linux* char_strings_test_debug: gcc-3.2.3-linux* chset_tests: gcc-3.2.3-linux* chset_tests_debug: gcc-3.2.3-linux* closure_tests: gcc-3.2.3-linux* closure_tests_debug: gcc-3.2.3-linux* confix_tests: gcc-3.2.3-linux* confix_tests_debug: gcc-3.2.3-linux* directives_tests: gcc-3.2.3-linux* directives_tests_debug: gcc-3.2.3-linux* distinct_tests: gcc-3.2.3-linux* distinct_tests_debug: gcc-3.2.3-linux* epsilon_tests: gcc-3.2.3-linux* epsilon_tests_debug: gcc-3.2.3-linux* escape_char_parser_tests: gcc-3.2.3-linux* escape_char_parser_tests_debug: gcc-3.2.3-linux* exception_tests: gcc-3.2.3-linux* exception_tests_debug: gcc-3.2.3-linux* for_p_as_parser_tests: gcc-3.2.3-linux* for_tests: gcc-3.2.3-linux* for_tests_debug: gcc-3.2.3-linux* fundamental_tests: gcc-3.2.3-linux* fundamental_tests_debug: gcc-3.2.3-linux* grammar_def_test: gcc-3.2.3-linux* grammar_def_test_debug: gcc-3.2.3-linux* grammar_mt_tests: gcc-3.2.3-linux* grammar_multi_instance_tst: gcc-3.2.3-linux* grammar_multi_instance_tst_debug: gcc-3.2.3-linux* grammar_tests: gcc-3.2.3-linux* grammar_tests_debug: gcc-3.2.3-linux* group_match_bug: gcc-3.2.3-linux* group_match_bug_debug: gcc-3.2.3-linux* if_p_as_parser_tests: gcc-3.2.3-linux* if_p_int_as_condition_test: gcc-3.2.3-linux* if_p_int_as_condition_test_debug: gcc-3.2.3-linux* if_tests: gcc-3.2.3-linux* if_tests_debug: gcc-3.2.3-linux* lazy_tests: gcc-3.2.3-linux* lazy_tests_debug: gcc-3.2.3-linux* loops_tests: gcc-3.2.3-linux* loops_tests_debug: gcc-3.2.3-linux* match_tests: gcc-3.2.3-linux* match_tests_debug: gcc-3.2.3-linux* multi_pass_compile_tests: gcc-3.2.3-linux* negated_eps_p_test: gcc-3.2.3-linux* negated_eps_p_test_debug: gcc-3.2.3-linux* numerics_tests: gcc-3.2.3-linux* numerics_tests_debug: gcc-3.2.3-linux* operators_tests: gcc-3.2.3-linux* operators_tests_debug: gcc-3.2.3-linux* parametric_tests: gcc-3.2.3-linux* parametric_tests_debug: gcc-3.2.3-linux* parser_context_test: gcc-3.2.3-linux* parser_context_test_debug: gcc-3.2.3-linux* parser_traits_tests: gcc-3.2.3-linux* parser_traits_tests_debug: gcc-3.2.3-linux* primitives_tests: gcc-3.2.3-linux* primitives_tests_debug: gcc-3.2.3-linux* repeat_ast_tests: gcc-3.2.3-linux* repeat_ast_tests_debug: gcc-3.2.3-linux* rule_tests: gcc-3.2.3-linux* rule_tests_debug: gcc-3.2.3-linux* scanner_tests: gcc-3.2.3-linux* scanner_tests_debug: gcc-3.2.3-linux* scanner_value_type_tests: gcc-3.2.3-linux* scanner_value_type_tests_debug: gcc-3.2.3-linux* scoped_lock_tests: gcc-3.2.3-linux* scoped_lock_tests_debug: gcc-3.2.3-linux* select_p_with_rule: gcc-3.2.3-linux* select_p_with_rule_debug: gcc-3.2.3-linux* shortest_alternative_tests: gcc-3.2.3-linux* shortest_alternative_tests_debug: gcc-3.2.3-linux* subrule_tests: gcc-3.2.3-linux* subrule_tests_debug: gcc-3.2.3-linux* switch_problem: gcc-3.2.3-linux* switch_problem_debug: gcc-3.2.3-linux* switch_tests_eps_default: gcc-3.2.3-linux* switch_tests_eps_default_debug: gcc-3.2.3-linux* switch_tests_general_def: gcc-3.2.3-linux* switch_tests_general_def_debug: gcc-3.2.3-linux* switch_tests_single: gcc-3.2.3-linux* switch_tests_single_debug: gcc-3.2.3-linux* switch_tests_wo_default: gcc-3.2.3-linux* switch_tests_wo_default_debug: gcc-3.2.3-linux* symbols_tests: gcc-3.2.3-linux* symbols_tests_debug: gcc-3.2.3-linux* traverse_tests: gcc-3.2.3-linux* traverse_tests_debug: gcc-3.2.3-linux* while_p_as_parser_tests: gcc-3.2.3-linux* while_tests: gcc-3.2.3-linux* while_tests_debug: gcc-3.2.3-linux* |xpressive| misc1: cw-9_4 cw-9_5-darwin regress: cw-9_5-darwin gcc-3.2.3-linux* gcc-3.3.6-linux gcc-3.4.4-linux intel-9.0-linux test1: cw-9_4 cw-9_5-darwin test10: cw-9_4 cw-9_5-darwin test10u: cw-9_4 cw-9_5-darwin test1u: cw-9_4 cw-9_5-darwin test2: cw-9_4 cw-9_5-darwin test2u: cw-9_4 cw-9_5-darwin test3: cw-9_4 cw-9_5-darwin test3u: cw-9_4 cw-9_5-darwin test4: cw-9_4 cw-9_5-darwin test4u: cw-9_4 cw-9_5-darwin test5: cw-9_4 cw-9_5-darwin test5u: cw-9_4 cw-9_5-darwin test6: cw-9_4 cw-9_5-darwin test6u: cw-9_4 cw-9_5-darwin test7: cw-9_4 cw-9_5-darwin test7u: cw-9_4 cw-9_5-darwin test8: cw-9_4 cw-9_5-darwin test8u: cw-9_4 cw-9_5-darwin test9: cw-9_4 cw-9_5-darwin test9u: cw-9_4 cw-9_5-darwin test_basic_regex: cw-9_5-darwin test_cycles: cw-9_4 test_dynamic: cw-9_4 test_match_results: cw-9_5-darwin test_non_char: cw-9_4 test_regex_compiler: cw-9_5-darwin test_regex_iterator: cw-9_5-darwin test_regex_token_iterator: cw-9_4 cw-9_5-darwin test_static: cw-9_4 |date_time| testgreg_serialize: gcc-3.2.3-linux* testgreg_serialize_dll: cw-9_4 gcc-3.2.3-linux* intel-win32-8_1 intel-win32-9_0 vc-7_1 vc-7_1 testgreg_serialize_xml: gcc-3.2.3-linux* testtime_serialize: gcc-3.2.3-linux* testtime_serialize_std_config: gcc-3.2.3-linux* testtime_serialize_xml: gcc-3.2.3-linux* testtime_serialize_xml_std_config: gcc-3.2.3-linux* |multi_array| access: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux index_bases: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux reshape: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux slice: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux |multi_index| test_serialization: gcc-3.2.3-linux* |ptr_container| incomplete_type_test: gcc-3.2.3-linux* indirect_fun: gcc-3.2.3-linux* iterator_test: gcc-3.2.3-linux* ptr_array: gcc-3.2.3-linux* ptr_deque: gcc-3.2.3-linux* ptr_list: gcc-3.2.3-linux* ptr_map: gcc-3.2.3-linux* ptr_set: gcc-3.2.3-linux* ptr_vector: gcc-3.2.3-linux* tree_test: gcc-3.2.3-linux* tut1: gcc-3.2.3-linux* view_example: gcc-3.2.3-linux* |typeof| function_ptr_from_tpl_emulation: vc-7_1 vc-7_1 function_ptr_from_tpl_native: vc-7_1 vc-7_1 |filesystem| convenience_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux fstream_test: gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux* large_file_support_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mbcopy: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux* mingw-3_4_2 mingw-3_4_2 mbpath: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux mingw-3_4_2 mingw-3_4_2 operations_test: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux* gcc-3.3.6-linux gcc-3.4.4-linux intel-9.0-linux operations_test_dll: cw-9_5-darwin gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux* gcc-3.3.6-linux gcc-3.4.4-linux intel-9.0-linux path_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux path_test_dll: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux simple_ls: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux wide_test: gcc-2.95.3-linux gcc-2.95.3-stlport-4.6.2-linux gcc-3.2.3-linux* mingw-3_4_2 mingw-3_4_2 tru64cxx71-006

1 0

asio formal review begins
by Jeff Garland 03 Jan '06

03 Jan '06

All - Today (Dec 10th) is the start of the format review of the Asynchronous I/O library (asio) library by Christopher Kohlhoff. The review will run until Friday December 23rd. I will be serving as review manager. From the library synopsis: Boost.Asio is a cross-platform C++ library for network programming that provides developers with a consistent asynchronous I/O model using a modern C++ approach. Downloads of the library as well as online documentation can be found at: http://asio.sourceforge.net/ (please refresh the page if you don't see "Boost Review Material" at the top) http://asio.sourceforge.net/boost-asio-proposal-0.3.6/libs/asio/doc/ As usual, please state in review comments how you reviewed the library and whether the you think the library should be accepted into Boost. Further guidelines for writing reviews can be found on the website at: http://www.boost.org/more/formal_review_process.htm#Comments Please review early and often! Thanks, Jeff ******************************************************* A Few Library Details: ******************************************************* Supported Platforms The following platforms and compilers have been tested: * Win32 using Visual C++ 7.1 and Visual C++ 8.0. * Win32 using Borland C++Builder 6 patch 4. * Win32 using MinGW. * Linux (2.4 or 2.6 kernels) using g++ 3.3 or later. * Solaris using g++ 3.3 or later. * Mac OS X 10.4 using g++ 3.3 or later. Rationale The Boost.Asio library is intended for programmers using C++ for systems programming, where access to operating system functionality such as networking is often required. In particular, Boost.Asio attempts to address the following goals: * Portability. The library should support, and provide consistent behaviour across, a range of commonly used operating systems. * Scalability. The library should allow, and indeed encourage, the development of network applications that scale to hundreds or thousands of concurrent connections. The library implementation for each operating system should use the mechanism that best enables this scalability. * Efficiency. The library should support techniques such as scatter-gather I/O, and allow protocol implementations that minimise data copying. * Model Berkeley sockets. The Berkeley sockets API is widely implemented and understood, as well as being covered in much literature. Other programming languages often use a similar interface for networking APIs. * Ease of use. Lower the entry barrier for new users by taking a toolkit, rather than framework, approach. That is, try to minimise the up-front investment in time to just learning a few basic rules and guidelines. After that, a library user should only need to understand the specific functions that are being used. * Basis for further abstraction. The library should permit the development of other libraries that provide higher levels of abstraction. For example, implementations of commonly used protocols such as HTTP. Although the current incarnation of Boost.Asio focuses primarily on networking, its concepts of asynchronous I/O can be extended to include other operating system resources such as files.

38 164

[asio] Formal Review
by Giovanni P. Deretta 03 Jan '06

03 Jan '06

Hi everybody, I hope not to have missed the review deadline... First of all I vote *not* to accept asio in boost yet. I think that the library is very promising but there are some issues. If the library is not accepted, is strongly encourage the author to subimit it again once the issues are resolved. - What is your evaluation of the design? Promising. I think that the most important innovation of asio is the dispatcher concept and the async call pattern. Everything else is just *extra*. It probably should be removed in some way from asio and made a separate boost library (or may be just rename asio to something like "asynch lib" or whatever). The interface provided by asio is very low level, but i think this is a strenght of asio, not a weakness. Higher level interfaces (iostreams, buffer management etc...) can be added later as external components or extensions to the library itself. The {datagram|stream}_socket interface is nice, but i have some issues with them. First of all the name "socket" is too much connected with the BSD socket API. I think that asio should go well beyond it and not limit itself to the system socket types (not that it does, but the names might seem to imply that). This is just a personal preference though. Also i think there should be *no* asio::stream_socket. This is my major The current stream socket should be in the namespace asio::ipv4, and should be a different type for example from an eventual asio::posix_pipe::stream_socket or asio::unix::stream_socket. Especially the last can be currently trivially implemented by defining the appropriate protocol. This means that a stream_socket initialized with a ipv4::tcp protocol will interoperate with a stream_socket initialized with a unix::stream protocol. For example, currently i can use my hipotethical unix::stream with ipv4::resolver. Asio should not be type unsafe only because the BSD API is. Of course both should share the same code, but it should be an implementation detail. I like the sync and asynch read/write interface and I have no problem with them being in the same object (i.e. no separation of asynch socket and sync socket). I agree that the proactor patter is the more portable than the reactor one, especially if asio is extended to filesystem i/o. I think the interface could be extended for better efficiency (i will try to describe later how), but this can be done at a later stage. I don't really like a lot the service concept. While I agree that the service repository is useful to hold the various proactor implementations (iocp_service, reactive_service<kqueue>, reactive_service<epoll>, etc...), i don't think that the streams should care about them. As long as the impl_type are interoperable, any stream should be bindable with any service. This also means that the binding with the demuxer should *not* be done at creation time, but at open time. This will make it possible to have different openers: connector, acceptor, unix::socket_pair, posix::pipe etc. The openers are instead created with a demuxer reference and will pass it to the socket when opened. By the way, the implementation of socket functions (accept, connect, read, write, etc) should not be members of the demuxer service but free functions or, better, static members of a policy class. The buffer concept does not really add much, simply using void pointers and size_t length parameters might require less conceptual overhead. They don't add much security (it should be the responsibility of higher layers along with buffer managements), and in practice don't help a lot with scatter/gather i/o: often you can't reuse an existing vector of iovecs, because you need to do an operation from/to the middle of it and thus you need to build a temporary one. As the iovector is usually small (16 elements may be?) and can be stack allocated, I think that having a global buffer type is a premature optimization. Instead there should be a *per stream type*, because a custom stream might use a different iovector implementation that the system one ( io_vec or whatever). It should have at least push_back(void*, size_t) and size() members. Scatter gather operations should accept an iterator to first element of the operation (usually the first element of the vector). The current interface let the user put a socket in non blocking mode, but there is not much that can be done with that, because no reactor is exported. The various reactors/proactor implementations should be removed from the detail namespace and be promoted to public interfaces, albeit in their own namespace (i.e. win32::iocp_proactor, posix::select_reactor, linux::epoll_reactor etc...). This change will make the library a lot more useful. The buffered stream is almost useless. Any operation requires two copies, one from kernel to user space, and one from the internal buffer to the user buffer. The internal buffer should be unlimited in length (using some kind of deque) and accessible to eliminate copies. An interface for i/o that does not require copying would be generally usefull and not limited to buffered streams. - What is your evaluation of the implementation? Good. The code is very clean and readable. Often is more useful than the documentation. There are inefficiencies caused by too much dynamic allocations, mutexes and unnecessary system calls, but they are not intrinsic in the desing and I see from other posting that they are currently being addresed by the author. Probably there should be more code reuse. For example the asio::ssl::stream duplicates much of the code of asio::stream_base. I think that the buffer function does not support vectors with custom allocators, but i might be missing something. On some systems there is already an asynch resolver call (glibc provides getaddrinfo_a). Asio should use them instead of its own thread based emulation. The glibc api still use threads, but a strictly single threaded implementation is theoretically possible. The implemenation is header only. It makes the library easier to use, but network system headers are known to pollute the enviroment :) - What is your evaluation of the documentation? Insufficient. One of the best thing of boost is the quality of its documentation. I don't think that asio is on par with boost standards. While the examples are good and well described, the API documentation is not very useful. It really shows its autogenerated-ness :) - What is your evaluation of the potential usefulness of the library? Extremely useful. There have been lots of requests and proposal for a boost.net library. Asio is certanly the most promising. - Did you try to use the library? While I didn't use all of it (No timers nor SSL), as an experiment I did write a simple continuation library using asio::demuxer as a scheduler and using asio callback pattern to restart coroutines waiting for i/o. Asio's demuxer cleaness and callback guarantees made the implementation very straightforward. If some one is interested i may upload the code somewhere. Currently it is posix only (it uses the makecontext family of system calls), but it should be fairly easy to implement win32 fiber support. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? In depth. I've read most of the documentation and studied the implementation, or at leas part of it. - Are you knowledgeable about the problem domain? Yes, a bit. I've written my own network library, although synchronous only. I've studied the asynch problem in depth, but I've only theorethical knowledge of it. I did not add async support to my library because I couldn't find a good async interface. ---- At this point the review if finished. I'will continue with a wish list of the things i would like to see in asio, but don't necessarily belong to a 1.0 version: - Asynchornous completion Tokens. While callbacks are useful most of the time, sometimes ACT are a bettere solution. It would be nice if asio did let the user specify an act instead of a callback to async functions. Then the demuxer would act as a container of ACTs that could be enumerated. - Lazy allocation of buffers. Instead of passing a buffer or a list of buffers to an async io function, a special allocator is passed. When the buffer is needed (before the async syscall on real proactors and before the non blocking call, but after polling on emulated proactors), the allocator is called and it will return a buffer to be used for the operation. The buffer is then passed to the handler. It will eliminate the need to commit buffer memory for inactive connections. This mostly makes sense for reading, but it might be extended to writing too. This optimization make it possible to add... - Multishot calls. Instead of the regular "exactly one callback for async_call", a client might register a callback for multiple wakeups. For example a async_multi_read_some will be called with a buffer allocator and a callback as parameter and will return a registration token. Every time some data is available from the socket, a buffer is allocated, data is read and a callback is done. Note that the same callback is reused, so there is no need to allocate and copy multiple callbacks. This optimization, for example, will greatly reduce the number of syscalls done in reactive demuxer. The notification of interest to the system demuxer is only done once, then as long as the read syscall does not block, no other syscalls need to be done. This will probably be useful mostly with datagram servers. The same optimization can be done to async_accept. - Relinquising ownership of buffers or lending them. While the normal BSD api requires the copying of buffers anyway, there are streams that can be implemented without copying. For example a process-local shared memory stream can be implemented by simply moving pointer to buffers between threads. A buffered stream might take ownership of a supplied buffer and add it to its own buffer list. Giving and taking ownership is not the only action possible, but a immutable buffer could be loaned to a stream. This is useful for caching. For example, when reading from a file a cached file stream can be used. The stream will check in the cache if the file page is present, and if so, it will return a shared, reference counted, pointer to the page as an immutable buffer. As long as the caller only reads from the supplied buffer (for example to send it to a remote host), no copying is required. I think that's all ... for now :). Sorry for the long review. --- Giovanni P. Deretta

5 10