Re: [boost] [shifted_ptr] __normal_iterator ..?

From: Larry Evans (cppljevans_at_[hidden])
Date: 2008-06-22 09:18:00

On 06/21/08 12:40, Phil Bouchard wrote:
> "Larry Evans" <cppljevans_at_[hidden]> wrote in message 
> news:g3gp99$9a2$1_at_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.