Re: [allocator.concept] smart pointer clarifications
"Phil Bouchard" <phil@fornux.com> wrote in message
news:g8b4ng$a05$1@aioe.org...
[...]
The latter is necessary to make changes to either the smart pointer itself
or the object pointed to in case raw pointer are used. We can see my
personnal implementation here and I would like to propose the following
function signatures:
template <typename T>
class shifted_allocator
{
public:
typedef shifted<T> value_type;
typedef shifted_ptr<T> pointer;
typedef shifted_ptr<const T> const_pointer;
value_type * allocate(size_type s, const void * = 0);
void deallocate(pointer & p, size_type);
void construct(value_type * p, const T & x);
void destroy(pointer & p);
...
};
[...]
Moreover it turns out this will become an even bigger problem if the new
rule of virtualizing allocator is accepted because the parameters will be
totaly different:
namespace std
{
class allocator_implementation
{
typedef void * pointer;
virtual void deallocate(pointer p, size_type) = 0;
...
};
}
template <typename T>
class shifted_allocator : std::allocator_implementation
{
public:
typedef shifted<T> value_type;
typedef shifted_ptr<T> pointer;
typedef shifted_ptr<const T> const_pointer;
virtual void deallocate(pointer & p, size_type) // won't override
{
}
...
};
I think the idea of virtualizing the allocators should not be accepted
because it will be irreversible. Correct me if I'm wrong but I don't see
why we couldn't virtualize containers instead. Everybody thinks this means
slower performance but most of today's compilers are smart enough to bypass
the virtual tables. Let's consider the following:
template <typename T>
class list_base : public ...{ /* common operations */ ... };
template <typename T, typename Alloc>
class list : public list_base<T> { ... };
-Phil
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]