std::ext STL (was: Re: design doc on alternative pointer support)

[Phil Bouchard]

----- Original Message ----- 
From: "Bob Walters" <bob.s.walters@gmail.com>
To: "Phil Bouchard" <philippe@fornux.com>; <libstdc++@gcc.gnu.org>
Sent: Tuesday, August 12, 2008 6:59 PM
Subject: std::ext STL (was: Re: design doc on alternative pointer support)

[...]

> However, after reviewing your code, I noticed all the stuff commented
> out in clear(), and other commented out calls to _M_put_node
> (deallocation), and I assume that is because you specifically are
> working with a smart pointer.  Is this version of list<> intended to
> work only with a smart pointer approach?  Have you given any thought
> to how this template could be made to work in general, with any
> pointer type, possibly by requiring that the allocator implement empty
> destroy() and deallocate() methods to accomodate the smart pointer?

 I just want to make sure you are referring to the latest version of the 
patches.  You will find them attached.  I think stl_list.h.patch is close to 
my last version but I haven't completed list.tcc.patch yet.  In the latter 
we can see I reworked:
- _List_node_base<_Alloc>::hook to work with any pointer's logic.

I think this function is the worse case scenario because it's the only one 
handling at the same time the three different types:
- shifted<T> *
- T &
- shifted_ptr<T>

This is why I was saying previously that the smart pointer I am using will 
help define the standards better because of its "value_type" not being of 
type "T" but "shifted<T>":

Old code:
template<typename _Alloc> void _List_node_base<_Alloc>::hook(value_type * 
const __position)
{
    this->_M_next = __position;
    this->_M_prev = __position->_M_prev;
    __position->_M_prev->_M_next = this;
    __position->_M_prev = this;
}

New code:
template<typename _Alloc> void _List_node_base<_Alloc>::hook(value_type * 
const __position)
{
    static_cast<_List_node_base &>(*__position)._M_next = 
this->_M_next->_M_prev;
    static_cast<_List_node_base &>(*__position)._M_prev = this->_M_prev;
    this->_M_prev->_M_next = __position;
    this->_M_prev = __position;
}

FYI shifted<T> looks like:
template <typename T> class shifted : public ...
{
    typedef T data_type;

    T elem_;

    public:
        ...
        operator data_type & ()             { return elem_; }
        operator data_type const & () const { return elem_; }
        ...
};

I am using the cast operator inside class shifted<T> but it is not dangerous 
since shifted<T> should be referred to thru a pointer (shifted<T> *), not by 
value (shifted<T> &) hence no implicit cast will occur.  This is isn't the 
ideal solution but it's a temporary one until I adapt hook() properly.

The other function _M_clear() will ne to be rewritten.  It is a interesting 
one because the nodes of a list will not disappear if we delete the first 
node pointer because the first node still is refered to by the second node, 
etc.  We need to take a better "smart pointer" approach here.


Regards,
-Phil
-------------- next part --------------
A non-text attachment was scrubbed...
Name: list.tcc.patch
Type: application/octet-stream
Size: 3181 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20080813/603cce24/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stl_list.h.patch
Type: application/octet-stream
Size: 15624 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20080813/603cce24/attachment-0001.obj>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: shifted_allocator.hpp
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20080813/603cce24/attachment.ksh>