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.