- Boost - lists.boost.org

Performance test and memory usage
by axter 04 Jan '06

04 Jan '06

What boost libraries are available for running code performance test and memory usage (if any)?

3 2

Performance comparison between ptr_vector and vector<cow_ptr<Shape> >, vector<copy_ptr<Shape> >
by axter 04 Jan '06

04 Jan '06

This is a continuation on a thread discussion advocating replacing the boost pointer containers with cow_ptr as the default pointer containers. http://code.axter.com/boost_ptr_containers/maintest.cpp http://code.axter.com/shape_test.h http://code.axter.com/cow_ptr.h http://code.axter.com/copy_ptr.h The above code was used to make the comparison, and the following is the result using VC++ 7.1 on XP with a 2G processor. Test performance for interating through a container of pointers via []. vector<copy_ptr<Shape> > 2.20 s boost::ptr_vector<Shape> 3.80 s vector<cow_ptr<Shape> > 7.20 s Test performance for interating through a container of pointers via iterators. vector<copy_ptr<Shape> > 2.36 s boost::ptr_vector<Shape> 4.11 s vector<cow_ptr<Shape> > 6.70 s vector<copy_ptr<Shape> > 2.31 s boost::ptr_vector<Shape> 4.08 s vector<cow_ptr<Shape> > 7.09 s Test performance for initializing and copying container of pointers. vector<copy_ptr<Shape> > 2.39 s boost::ptr_vector<Shape> 2.81 s vector<cow_ptr<Shape> > 0.67 s vector<copy_ptr<Shape> > 2.84 s boost::ptr_vector<Shape> 4.28 s vector<cow_ptr<Shape> > 0.61 s Test performance for populating container of pointers via factory method. vector<copy_ptr<Shape> > 7.00 s boost::ptr_vector<Shape> 1.55 s vector<cow_ptr<Shape> > 3.91 s Press any key to continue . . . I like to see if any one can test this out on other platforms and/or compilers to see if the results differ.

2 2

FW: ptr_container: ptr_map_adapter interface
by David Maisonave 04 Jan '06

04 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dpglgo$cb1$1(a)sea.gmane.org>... > axter wrote: > > "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > > news:<dpgi92$18k$1(a)sea.gmane.org>... > > > >>axter wrote: > >> > >> > >>>>The pointer-containers don't slica anything on their own. If you > >>>>insist on not making your class hierarchy non-copyable, I can't > >>>>help you. > >>>> > >>> > >>> > >>>I don't see that making a difference, but could you please post a > >>>small example class that is non-copyable, so that I can test it > >>>out. > >> > >>struct Foo > >>{ > >>private: > >> Foo( const Foo& ); > >> Foo& operator=( const Foo& ); > >>}; > >> > >>or > >> > >>#include <boost/utility.hpp> > >> > >>struct Bar : boost::noncopyable > >>{ > >>}; > >> > >>In addition, an explicit copy-constructor will prohibit slicing on > >>compliant compilers. > >> > > > > > > No, it doesn't. > > That's what I thought you where talking about, but I wanted to make > > sure before possibly putting my foot in my mouth. > > > > Both the above methods prevent slicing of concrete types. However, > > it does not prevent slicing in pointer idiom. See following example > > code using booost::ptr_vector, and non-copyable types that get > > slice, where BasesS1 uses the first non-copyable method, and BasesS2 > > uses the boost::noncopyable method. Both end up getting slice when > > the container gets copied. > > > > > > class BasesS1 > > { > > public: > > virtual BasesS1* do_clone()const=0; > > virtual string WhoAmI()const=0; > > BasesS1(int i = 0):m_i(i){} > > private: > > BasesS1( const BasesS1& ); > > BasesS1& operator=( const BasesS1& ); > > protected: > > int m_i; > > }; > > > > class DerivedS1 : public BasesS1 > > { > > public: > > DerivedS1(int i = 0):BasesS1(i){} > > BasesS1* do_clone()const{return new DerivedS1();} > > string WhoAmI()const{return "DerivedS1";} > > }; > > > > class DerivedDerivedS1 : public DerivedS1 > > { > > public: > > DerivedDerivedS1(int i = 0):DerivedS1(i){} > > string WhoAmI()const{return "DerivedDerivedS1";} > > }; > > [snip] > > > int main(int, char**) > > { > > boost::ptr_vector<BasesS1> vBaseS1_cpy1; > > vBaseS1_cpy1.push_back(new DerivedDerivedS1(123)); > > boost::ptr_vector<BasesS1> vBaseS1_cpy2(vBaseS1_cpy1.begin(), > > vBaseS1_cpy1.end()); > > cout << vBaseS1_cpy2[0].WhoAmI() << endl; > > Note that DerivedDerivedS1/S2 does not implement do_clone(). > Yes. That's exactly the point I'm trying to make. Both the boost pointer containers and the cow_ptr/copy_ptr method can result in splicing via improper usage. Both methods can produce splicing via derive-derive type, and both methods can produce splicing via derive type of a non-abstract type. Furthermore, making the class non-copyable does not prevent the splicing in a pointer idiom.

2 1

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

04 Jan '06

"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message news:<dpglgo$cb1$1(a)sea.gmane.org>... > axter wrote: > > "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > > news:<dpgi92$18k$1(a)sea.gmane.org>... > > > >>axter wrote: > >> > >> > >>>>The pointer-containers don't slica anything on their own. If you > >>>>insist on not making your class hierarchy non-copyable, I can't > >>>>help you. > >>>> > >>> > >>> > >>>I don't see that making a difference, but could you please post a > >>>small example class that is non-copyable, so that I can test it > >>>out. > >> > >>struct Foo > >>{ > >>private: > >> Foo( const Foo& ); > >> Foo& operator=( const Foo& ); > >>}; > >> > >>or > >> > >>#include <boost/utility.hpp> > >> > >>struct Bar : boost::noncopyable > >>{ > >>}; > >> > >>In addition, an explicit copy-constructor will prohibit slicing on > >>compliant compilers. > >> > > > > > > No, it doesn't. > > That's what I thought you where talking about, but I wanted to make > > sure before possibly putting my foot in my mouth. > > > > Both the above methods prevent slicing of concrete types. However, > > it does not prevent slicing in pointer idiom. See following example > > code using booost::ptr_vector, and non-copyable types that get > > slice, where BasesS1 uses the first non-copyable method, and BasesS2 > > uses the boost::noncopyable method. Both end up getting slice when > > the container gets copied. > > > > > > class BasesS1 > > { > > public: > > virtual BasesS1* do_clone()const=0; > > virtual string WhoAmI()const=0; > > BasesS1(int i = 0):m_i(i){} > > private: > > BasesS1( const BasesS1& ); > > BasesS1& operator=( const BasesS1& ); > > protected: > > int m_i; > > }; > > > > class DerivedS1 : public BasesS1 > > { > > public: > > DerivedS1(int i = 0):BasesS1(i){} > > BasesS1* do_clone()const{return new DerivedS1();} > > string WhoAmI()const{return "DerivedS1";} > > }; > > > > class DerivedDerivedS1 : public DerivedS1 > > { > > public: > > DerivedDerivedS1(int i = 0):DerivedS1(i){} > > string WhoAmI()const{return "DerivedDerivedS1";} > > }; > > [snip] > > > int main(int, char**) > > { > > boost::ptr_vector<BasesS1> vBaseS1_cpy1; > > vBaseS1_cpy1.push_back(new DerivedDerivedS1(123)); > > boost::ptr_vector<BasesS1> vBaseS1_cpy2(vBaseS1_cpy1.begin(), > > vBaseS1_cpy1.end()); > > cout << vBaseS1_cpy2[0].WhoAmI() << endl; > > Note that DerivedDerivedS1/S2 does not implement do_clone(). > Yes. That's exactly the point I'm trying to make. Both the boost pointer containers and the cow_ptr/copy_ptr method can result in splicing via improper usage. Both methods can produce splicing via derive-derive type, and both methods can produce splicing via derive type of a non-abstract type. Furthermore, making the class non-copyable does not prevent the splicing in a pointer idiom.

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:<dpgi92$18k$1(a)sea.gmane.org>... > axter wrote: > > >>The pointer-containers don't slica anything on their own. If you > >>insist on not making your class hierarchy non-copyable, I can't help > >>you. > >> > > > > > > I don't see that making a difference, but could you please post a > > small example class that is non-copyable, so that I can test it out. > > struct Foo > { > private: > Foo( const Foo& ); > Foo& operator=( const Foo& ); > }; > > or > > #include <boost/utility.hpp> > > struct Bar : boost::noncopyable > { > }; > > In addition, an explicit copy-constructor will prohibit slicing on > compliant compilers. > No, it doesn't. That's what I thought you where talking about, but I wanted to make sure before possibly putting my foot in my mouth. Both the above methods prevent slicing of concrete types. However, it does not prevent slicing in pointer idiom. See following example code using booost::ptr_vector, and non-copyable types that get slice, where BasesS1 uses the first non-copyable method, and BasesS2 uses the boost::noncopyable method. Both end up getting slice when the container gets copied. class BasesS1 { public: virtual BasesS1* do_clone()const=0; virtual string WhoAmI()const=0; BasesS1(int i = 0):m_i(i){} private: BasesS1( const BasesS1& ); BasesS1& operator=( const BasesS1& ); protected: int m_i; }; class DerivedS1 : public BasesS1 { public: DerivedS1(int i = 0):BasesS1(i){} BasesS1* do_clone()const{return new DerivedS1();} string WhoAmI()const{return "DerivedS1";} }; class DerivedDerivedS1 : public DerivedS1 { public: DerivedDerivedS1(int i = 0):DerivedS1(i){} string WhoAmI()const{return "DerivedDerivedS1";} }; inline BasesS1* new_clone( const BasesS1& a ) { return a.do_clone(); } class BasesS2 : boost::noncopyable { public: virtual BasesS2* do_clone()const=0; virtual string WhoAmI()const=0; BasesS2(int i = 0):m_i(i){} protected: int m_i; }; class DerivedS2 : public BasesS2 { public: DerivedS2(int i = 0):BasesS2(i){} BasesS2* do_clone()const{return new DerivedS2();} string WhoAmI()const{return "DerivedS2";} }; class DerivedDerivedS2 : public DerivedS2 { public: DerivedDerivedS2(int i = 0):DerivedS2(i){} string WhoAmI()const{return "DerivedDerivedS2";} }; inline BasesS2* new_clone( const BasesS2& a ) { return a.do_clone(); } int main(int, char**) { boost::ptr_vector<BasesS1> vBaseS1_cpy1; vBaseS1_cpy1.push_back(new DerivedDerivedS1(123)); boost::ptr_vector<BasesS1> vBaseS1_cpy2(vBaseS1_cpy1.begin(), vBaseS1_cpy1.end()); cout << vBaseS1_cpy2[0].WhoAmI() << endl; boost::ptr_vector<BasesS2> vBaseS2_cpy1; vBaseS2_cpy1.push_back(new DerivedDerivedS2(123)); boost::ptr_vector<BasesS2> vBaseS2_cpy2(vBaseS2_cpy1.begin(), vBaseS2_cpy1.end()); cout << vBaseS2_cpy2[0].WhoAmI() << endl;

2 1

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:<dpg7m4$vi6$1(a)sea.gmane.org>... > axter wrote: > > "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > > news:<dpf849$bne$1(a)sea.gmane.org>... > > > >>axter wrote: > >> > >>>"Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > >>>news:<dpdofv$434$1(a)sea.gmane.org>... > >> > >>>>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. > >> > >>No, I'm saying that you should make you class hiararchy noncopyable > >>by default because it doesn't make sense to copy such types. I > >>believe Steven Dewhurst has an item on that in his "Common > >>Knowledge" book. > >> > >>Your argumentation is weird...in the same manner I could prove your > >>cow pointer (or any smart pointer) is worse because it allows > >>slicing: > >> > >>cow_ptr<T> p1, p2; > >>... > >>*p1 = *p2; > > > > > > Did you test the cow_ptr out, to prove this? > > The above code will not cause slicing using the following cow_ptr: > > http:://code.axter.com/cow_ptr.h > > > > I recommend you test it, so you can fully understand why I'm > > recommending it over the current boost pointer container as the > > default method for creating a container of pointers. > > > > If you have an abstract base pointer, the only way to get slicing on > > this type of smart pointer is if you pass a derive-derive type via a > > derive pointer. > > right, so you can get slicing. but the poiint I was making is that a > user action that slices, not the library. > > > DerivedType * p = new DerivedDerivedType; > > cow_ptr<base> p1(p); > > cow_ptr<base> p2(p1);//This would produce slicing > > Of course the above logic would not be in keeping with clone logic in which > > a clone pointer is suppose to have sole ownership of a pointer from > > conception to deletion. The clone pointer will only slice if you pass it the > > wrong type on the constructor. > > > > Similar type of slicing can occur with the current boost pointer > > container. If a derived-derived type does not implement a clone > > method, then it will get sliced when cloning. > > The pointer-containers don't slica anything on their own. > If you insist on not making your class hierarchy non-copyable, I can't > help you. > I don't see that making a difference, but could you please post a small example class that is non-copyable, so that I can test it out.

2 1

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:<dpf7ec$9kl$1(a)sea.gmane.org>... > axter wrote: > > > > > > 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. > > Their primary purpose is to facilitate OOP in C++. This domain is > sufficiently different from the value-based domain that different > programming idioms apply. > > > > 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. > > Listen, when you said you could get it to work with an abstract type, > I > tried it out. > > It works fine, but one gets errors if one does not define new_clone() > for the abstract type: > > namespace Foo > { > struct abtract_base { ... }; > > inline new_clone( const abstract_base& r ) > { return r.clone(); } > } > > My guess is that most of the other compile problems go away when you > define this. > > Did you not read > > http://www.boost.org/libs/ptr_container/doc/reference.html#the-clonabl > e-concept I did read it, and if you read my code, you would see that the new_clone function is in the shape.h header. I just tested it again, and again it fails to compile. I even went through the trouble of taking out all the compiler directives, and cleaning the code so-as to remove any possible noise, but it still fails to compile. One of the compile errors is becaue boost::ptr_map class requires the object have a default constructor. After I added a default constructor for test purposes, it still fail to compile, by giving the following error: **************************************************************************** ********************************************************* c:\lib\boost_1_33_0\boost\ptr_container\ptr_map_adapter.hpp(171) : error C2259: 'Shape' : cannot instantiate abstract class due to following members: 'void Shape::draw(void) const' : pure virtual function was not defined m:\__Current\PolymorphicContainersDemo\shape_test.h(12) : see declaration of 'Shape::draw' 'std::string Shape::GetShapeName(void) const' : pure virtual function was not defined m:\__Current\PolymorphicContainersDemo\shape_test.h(13) : see declaration of 'Shape::GetShapeName' 'Shape *Shape::do_clone(void) const' : pure virtual function was not defined m:\__Current\PolymorphicContainersDemo\shape_test.h(33) : see declaration of 'Shape::do_clone' c:\lib\boost_1_33_0\boost\ptr_container\ptr_map_adapter.hpp(161) : while compiling class-template member function 'boost::ptr_container_detail::ptr_map_adapter_base<T,VoidPtrMap,CloneAllocat or>::reference boost::ptr_container_detail::ptr_map_adapter_base<T,VoidPtrMap,CloneAllocato r>::insert_lookup(const boost::ptr_container_detail::ptr_map_adapter_base<T,VoidPtrMap,CloneAllocato r>::key_type &)' **************************************************************************** ********************************************************* I get the above error from the following four lines of code: boost::ptr_map<int, Shape> mIntToShape; int i123 = 123; mIntToShape.insert(i123, new Circle("blue")); mIntToShape[i123].draw(); //This line is what causes the error You can download the shape class from following link: http://code.axter.com/shape_test.h Have you tested this code with an abstract type, and if so, can you post the test code?

2 1

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:<dpf849$bne$1(a)sea.gmane.org>... > axter wrote: > > "Thorsten Ottosen" <tottosen(a)dezide.com> wrote in message > > news:<dpdofv$434$1(a)sea.gmane.org>... > > >>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. > > No, I'm saying that you should make you class hiararchy noncopyable by > default because it doesn't make sense to copy such types. I believe > Steven Dewhurst has an item on that in his "Common Knowledge" book. > > Your argumentation is weird...in the same manner I could prove your > cow pointer (or any smart pointer) is worse because it allows slicing: > > cow_ptr<T> p1, p2; > ... > *p1 = *p2; Did you test the cow_ptr out, to prove this? The above code will not cause slicing using the following cow_ptr: http:://code.axter.com/cow_ptr.h I recommend you test it, so you can fully understand why I'm recommending it over the current boost pointer container as the default method for creating a container of pointers. If you have an abstract base pointer, the only way to get slicing on this type of smart pointer is if you pass a derive-derive type via a derive pointer. DerivedType * p = new DerivedDerivedType; cow_ptr<base> p1(p); cow_ptr<base> p2(p1);//This would produce slicing Of course the above logic would not be in keeping with clone logic in which a clone pointer is suppose to have sole ownership of a pointer from conception to deletion. The clone pointer will only slice if you pass it the wrong type on the constructor. Similar type of slicing can occur with the current boost pointer container. If a derived-derived type does not implement a clone method, then it will get sliced when cloning. Neither the cow_ptr nor the copy_ptr requires that the pointee have a clone function, or any other additional clone methods from the user. So in this respect, I consider the cow_ptr and copy_ptr easier to use, and safer.

2 1

property_tree library revision 4 in vault
by Marcin Kalicinski 04 Jan '06

04 Jan '06

With: - JSON parser - extended cmdline parser - more docs - more tests - more examples Without: - some previously unspotted bugs cheers, Marcin

2 1

[foreach] [Revision 1.27] tiny problem under eVC4 (and maybe VC6)
by MB 04 Jan '06

04 Jan '06

Hi, Under eVC++4, foreach_detail_::is_array/is_const causes name conflict with boost::is_array/is_const. (I don't know why.) I hear VC++6 has the same compiler as eVC++4. I renamed them to 'is_array_' and 'is_const_', then it works fine. Regards, MB p-stade.sourceforge.net

2 2