- 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:<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

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