January 2006 - Boost - lists.preview.boost.org

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

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