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

["Phil Bouchard" <philippe at fornux dot com>]

Gcc,

We would like some advise from your part as to know the possibility of copy 
and pasting all STL containers into some std::ext headers-only supporting 
allocator::pointer to be of smart_ptr<> type.  For example we could have:

namespace std::ext
{
    template <typename _Tp, class _Alloc, typename _Tp2>
    struct _List_switch : std::ext::_List_base<_Tp, _Alloc>
    {
        [...]
    };

    template <typename _Tp, class _Alloc>
    struct _List_switch<_Tp, _Alloc, _Tp *> : std::_List_base<_Tp, _Alloc>
    {
        [...]
    };

    template <typename _Tp, class _Alloc>
    class list : public _List_switch<_Tp, _Alloc, typename _Alloc::pointer>
    {
        [...]
    };
}

Where:
- std::_List_base<_Tp, _Alloc> is the standard ABI
- std::ext::_List_base<_Tp, _Alloc> being the new one

This way all allocators using raw pointers as their pointer type will use 
the standard ABI and is perfectly backwards compatile.  In this example I am 
not considering all duplicated member function code but we could get around 
it differently.  We could then use it the following way:

std::ext::list<int, smart_ptr_allocator<int> > l;
std::list<int, std::allocator<int> > m = std::ext::list<int, 
std::allocator<int> >();
std::ext::list<int, std::allocator<int> > n = std::list<int, 
std::allocator<int> >();

As for object n we'll need a new copy contructor std::ext::list(std::list 
const &).


Regards,
-Phil

----- Original Message ----- 
From: "Bob Walters" <bob.s.walters@gmail.com>
To: "Phil Bouchard" <philippe@fornux.com>
Sent: Wednesday, July 23, 2008 3:21 PM
Subject: Re: design doc on alternative pointer support

[...]

> I see what you mean.  The first problem with this is that it breaks
> the ABI, and the GNU maintainers will not allow this change.  i.e. To
> provide a simplified explanation: after all changes made to the code,
> if a shared library using the new code passes a container or an
> iterator to a shared library compiled using the old code it should
> still work.  (So long as the container used a standard pointer type).
> All changes must meet that ABI constraint, or wait for the next major
> version of libstdc++.
>
> Another thing about that change which bugs me a little is how we make
> sure that any change like this would keep.  Someone 6 months later,
> working on efficiency optimizations would change the code to put it
> back on the stack, because that is more efficient, and it wouldn't be
> obvious why it wasn't like that already.
>
> A way you can get around this, for your shared_ptr, would be to have
> it recognize when an address it has been given is an address on the
> stack.  This is somewhat OS dependent, but most OSes put the stack
> segment in the highest part of the virtual address space of the app,
> and grow it downward.  So if you assume that anything in the highest
> 1GB of memory is on the stack, it will probably work.  Your shared
> pointer would be smart enough to know not to delete anything on the
> stack.

Well firstly I don't think portable OS segment detection routines are yet to
be available.  Segments are very different from OSes and CPUs, not to
mention memory swapping, etc.  The best we can do at this time is to use
some local pool such as boost::pool<> which doesn't yet support variadic
memory allocations in constant time BTW.  It might take some time for that
to happen.  There are solutions out there but are far from being
officialized.

I don't see why we couldn't copy & paste existing libstdc++ code (stl_*.h,
*.tcc & *.cc) into headers only and let the user decides which namespace to
use ("std" or "ext::stl" for example).  We could even detect at compile time
if myalloc::pointer really is a raw pointer or not.  If it is a raw pointer
then a specialized wrapper class could be called which would be consist of
the old code.  That means the wrapper class inside "ext::stl" could call old
"std" containers on demand.

[...]


Regards,
-Phil