[shifted_ptr] __normal_iterator ..?
Hi, Upon trying to create the new shifted_allocator class that is instead to be passed as a template parameter on STL containers, I got stuck in a circle or errors. I came to realize there was not way to replace internal pointers used by containers with smart pointers... which is very unfortunate. There are different solution I could take but hopefully I won't need them. By trying compiling shifted_ptr_test2.cpp in the Sandbox we'll get the following errors. I believe shifted_allocator (in shifted_allocator.hpp) should be represented the way it is but I may likely got something wrong because I haven't followed the verdict on this in previous posts: ...stl_vector.h: In member function `__gnu_cxx::__normal_iterator<typename _Alloc::const_pointer, std::vector<_Tp, _Alloc> > std::vector<_Tp, _Alloc>::begin() const [with _Tp = boost::detail::sh::shifted_ptr<vector>, _Alloc = boost::shifted_allocator<boost::detail::sh::shifted_ptr<vector>
]': ...stl_vector.h:221: instantiated from `std::vector<_Tp, _Alloc>::vector(const std::vector<_Tp, _Alloc>&) [with _Tp = boost::detail::sh::shifted_ptr<vector>, _Alloc = boost::shifted_allocator<boost::detail::sh::shifted_ptr<vector> >]' shifted_ptr_test2.cpp:66: instantiated from here
...stl_vector.h:322: error: no matching function for call to `__gnu_cxx::__normal_iterator<const boost::detail::sh::shifted<boost::detail::sh::shifted_ptr<vector> >*, std::vector<boost::detail::sh::shifted_ptr<vector>, boost::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >
::__normal_iterator(boost::detail::sh::shifted_ptr<vector>* const&)'
...stl_iterator.h:587: note: candidates are: __gnu_cxx::__normal_iterator<const boost::detail::sh::shifted<boost::detail::sh::shifted_ptr<vector> >*, std::vector<boost::detail::sh::shifted_ptr<vector>, boost::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >
::__normal_iterator(const __gnu_cxx::__normal_iterator<const boost::detail::sh::shifted<boost::detail::sh::shifted_ptr<vector> >*, std::vector<boost::detail::sh::shifted_ptr<vector>, boost::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > > >&) ...stl_iterator.h:603: note: __gnu_cxx::__normal_iterator<_Iterator, _Container>::__normal_iterator(const _Iterator&) [with _Iterator = const boost::detail::sh::shifted<boost::detail::sh::shifted_ptr<vector> >*, _Container = std::vector<boost::detail::sh::shifted_ptr<vector>, boost::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >] ...stl_iterator.h:600: note: __gnu_cxx::__normal_iterator<_Iterator, _Container>::__normal_iterator() [with _Iterator = const boost::detail::sh::shifted<boost::detail::sh::shifted_ptr<vector> >*, _Container = std::vector<boost::detail::sh::shifted_ptr<vector>, boost::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >]
The Vault version presents the same code except the comment of line 67 & 68 in shifted_ptr_test2.cpp will need to be swapped: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=shifted_ptr.zip&directory=Memory -Phil
On 06/20/08 03:36, Phil Bouchard wrote:
Hi,
Upon trying to create the new shifted_allocator class that is instead to be passed as a template parameter on STL containers, I got stuck in a circle or errors. I came to realize there was not way to replace internal pointers used by containers with smart pointers... which is very unfortunate. There are different solution I could take but hopefully I won't need them.
By trying compiling shifted_ptr_test2.cpp in the Sandbox we'll get the following errors. I believe shifted_allocator (in shifted_allocator.hpp) should be represented the way it is but I may likely got something wrong because I haven't followed the verdict on this in previous posts:
...stl_vector.h: In member function `__gnu_cxx::__normal_iterator<typename _Alloc::const_pointer, std::vector<_Tp, _Alloc> > std::vector<_Tp, _Alloc>::begin() const [with _Tp = boost::detail::sh::shifted_ptr<vector>, _Alloc = boost::shifted_allocator<boost::detail::sh::shifted_ptr<vector>
]': ...stl_vector.h:221: instantiated from `std::vector<_Tp,
Hi Phil, Even if you could find some way for your allocator to work for vector, I don't think it would work for other stl containers. These other containers, e.g. std::list<_Tp>, use Allocator<_Tp>::pointer to point to other elements in the container. AFAICT, what's needed for garbage collections is Allocator<_Tp>::root_pointer. This would be a *smart* pointer to the head of the list in the case of std::list<_Tp> and all other pointer would just be _Tp*. In the case of std::vector<_Tp>, I guess the start of the vector would be a *smart* pointer to _Tp[]. The iterators for a GC'ed vector would have to retain a copy of the root_pointer, I guess, in order to keep the whole vector alive if even 1 iterator were still around. Anyway, I encountered a similar problem with the policy_ptr library I worked on years ago. The code used to be in the sandbox; hoever, I can't find it now. However, FWIW, there's this post: http://article.gmane.org/gmane.comp.lib.boost.devel/155407/match=policy_ptr -regards, Larry
"Larry Evans" <cppljevans@suddenlink.net> wrote in message news:g3gp99$9a2$1@ger.gmane.org... [...]
Hi Phil,
Even if you could find some way for your allocator to work for vector, I don't think it would work for other stl containers. These other containers, e.g. std::list<_Tp>, use Allocator<_Tp>::pointer to point to other elements in the container. AFAICT, what's needed for garbage collections is Allocator<_Tp>::root_pointer. This would be a *smart* pointer to the head of the list in the case of std::list<_Tp> and all other pointer would just be _Tp*. In the case of std::vector<_Tp>, I guess the start of the vector would be a *smart* pointer to _Tp[]. The iterators for a GC'ed vector would have to retain a copy of the root_pointer, I guess, in order to keep the whole vector alive if even 1 iterator were still around.
[...] Hey Larry how have you been doing? I moved to the South West and thus couldn't work on this for some years. But it sounds we violate [20.1.5/4] by doing so as stated by Kai-Uwe Bux: "Implementations of containers described in this International Standard are permitted to assume that their Allocator template parameter meets the following two additional requirements beyond those in Table 32. [...] ? The typedef members pointer, const_pointer, size_type, and difference_type are required to be T*,T const*, size_t, and ptrdiff_t, respectively." How strange is that because one might ask why these typedefs exists in the first place if we can't change them. Besides licensing I don't see why we couldn't cut & paste the whole STL and make these changes; I'll try that out tomorrow. [On the other hand STL should have explicit access to nodes but intrusive containers are already on their way and hopefully intrusive stacks too]
Anyway, I encountered a similar problem with the policy_ptr library I worked on years ago. The code used to be in the sandbox; hoever, I can't find it now. However, FWIW, there's this post:
http://article.gmane.org/gmane.comp.lib.boost.devel/155407/match=policy_ptr
Yeah there is a way to stack up the information I need by creating a separate list of pointers and will bypass all of this but creates messy code and I think STL changes is a better approach. -Phil
On 06/21/08 12:40, Phil Bouchard wrote:
"Larry Evans" <cppljevans@suddenlink.net> wrote in message news:g3gp99$9a2$1@ger.gmane.org...
[snip]
[...] Hey Larry how have you been doing?
OK. Thanks.
I moved to the South West and thus couldn't work on this for some years.
Yeah. Back then I thought shifted_ptr did something like allocate the count and point in one block of code: template<class T> struct shifted_obj { int ref_count, T pointee; }; and then wrapped that in: template<class T> struct shifted_ptr { shifted_obj<T>* pointer; T* get(void)const{return &(pointer->T); }; Ah! Looking at the api doc: <root>/libs/smart_ptr/doc/api/index.html I'd guess that the ref_count is in boost::sh::detail::owned_base along with some other data having something to do with the 'Memory segment' mentioned in section 3.3 of: <root>/libs/smart_ptr/doc/index.html Also, it appears, from your other reply to me: http://article.gmane.org/gmane.comp.lib.boost.devel/176531 that you're using some sort of forwarding of CTOR args to the pointee's CTOR: shifted_ptr<int> p = new shifted<int>(9); Why not use the forwarding library that was recently approved? A relevant post is: http://lists.boost.org/Archives/boost/2007/12/131699.php
But it sounds we violate [20.1.5/4] by doing so as stated by Kai-Uwe Bux:
"Implementations of containers described in this International Standard
[snip]
How strange is that because one might ask why these typedefs exists in the first place if we can't change them. Besides licensing I don't see why we couldn't cut & paste the whole STL and make these changes; I'll try that out tomorrow.
[On the other hand STL should have explicit access to nodes but intrusive containers are already on their way and hopefully intrusive stacks too]
Anyway, I encountered a similar problem with the policy_ptr library I worked on years ago. The code used to be in the sandbox; hoever, I can't find it now. However, FWIW, there's this post:
http://article.gmane.org/gmane.comp.lib.boost.devel/155407/match=policy_ptr
Yeah there is a way to stack up the information I need by creating a separate list of pointers and will bypass all of this but creates messy code and I think STL changes is a better approach.
I had the same conclusion. I had two versions of template classes to handle stl containers. One version, in: namespace container_extern used a thin wrapper around the existing stl containers to workaround the limitation. The other version, in: namespace container_intern actually rewrite std::vector to use a new defintion of std::allocator template which provided different pointer types. One type was for the root pointer of the container, the other was for all other pointers used in the container. The default value of std::allocator simply made root_pointer the same as pointer. The specialized version of std::allocator made the root_pointer a smart_pointer. Obviously the 2nd one would be very hard (or at least take very long) to get into the standard.
"Larry Evans" <cppljevans@suddenlink.net> wrote in message news:g3liss$ubd$1@ger.gmane.org... [...]
Ah! Looking at the api doc:
<root>/libs/smart_ptr/doc/api/index.html
I'd guess that the ref_count is in boost::sh::detail::owned_base along with some other data having something to do with the 'Memory segment' mentioned in section 3.3 of:
<root>/libs/smart_ptr/doc/index.html
Precisely, owned_base derives from sp_counted_base which contains the counter. [...]
Why not use the forwarding library that was recently approved? A relevant post is:
Thanks I will; I am aware of the moving semantics on their way up the standards I just need to have all the code exposed while working on the allocator before using anything else. [...]
namespace container_intern
actually rewrite std::vector to use a new defintion of std::allocator template which provided different pointer types. One type was for the root pointer of the container, the other was for all other pointers used in the container. The default value of std::allocator simply made root_pointer the same as pointer. The specialized version of std::allocator made the root_pointer a smart_pointer.
Obviously the 2nd one would be very hard (or at least take very long) to get into the standard.
How fortunate! I could get use of that code... On the other hand shifted_ptr is done and STL containers support is extracurricular so I would vote for the latter. It can take all the time at that level, but we are simply requiring lessening the standards... -Phil
On 06/20/08 03:36, Phil Bouchard wrote: [snip]
The Vault version presents the same code except the comment of line 67 & 68 in shifted_ptr_test2.cpp will need to be swapped: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=shifted_ptr.zip&directory=Memory
Hi Phil. I just downloaded the vault and in the docs: libs/smart_ptr/doc/index.html there's: Cons: Requires usage of new_sh<T>() However, I couldn't find new_sh: {--- cut here--- -*- mode: compilation; default-directory: "~/prog_dev/boost-svn/ro/branches-proto-v4/sandbox/shifted_ptr/shifted_ptr/boost/" -*- Compilation started at Fri Jun 20 13:59:33 find . -name \*.h\* -exec grep new {} \; -ls #include <new.h> void * operator new (size_t s) void * operator new (size_t s, set * p) ps_ = new set(); ps_ = new set(); ps_ = new set(); ps_ = new set(); new (ps_) set(); ps_ = new set(); 4181803 8 -rw-r--r-- 1 evansl evansl 7179 Jun 20 01:02 ./shifted_ptr.hpp void * operator new( std::size_t ) void * operator new( std::size_t ) void * operator new( std::size_t ) void * operator new( std::size_t ) 4181800 8 -rw-r--r-- 1 evansl evansl 4987 May 3 13:01 ./detail/sh_owned_impl.h alloc_.reset(new lpp()); constr_.reset(new lpp()); void * operator new (size_t s) 4181799 8 -rw-r--r-- 1 evansl evansl 6665 Jun 19 09:09 ./detail/sh_owned_base_nt.hpp return shifted<T>::operator new(s); ::new (p) T(x); 4181802 4 -rw-r--r-- 1 evansl evansl 2748 Jun 20 00:45 ./shifted_allocator.hpp Compilation finished at Fri Jun 20 13:59:33 }--- cut here --- Where is new_sh defined? -regards, Larry
"Larry Evans" <cppljevans@suddenlink.net> wrote in message news:g3guec$qlk$1@ger.gmane.org... [...]
Where is new_sh defined?
No I changed it for shifted<> (which was class owned<>), now we have to type the following. I just forgot updating that page: shifted_ptr<int> p = new shifted<int>(9); Cheers, -Phil
participants (2)
-
Larry Evans -
Phil Bouchard