Hello. I've been reading allocators from the working draft and
comparing them to those in the
EASTL (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/
n2271.html) implementation. I have a doubt left: is it possible (and
practical) in c++0x to define an allocator with no template argument?
This could be useful in order to share an allocator between several
types.

And the second one: will allocators remain class based instead of
instance based? Because I saw that allocators are returned by value,
which I think it's a bad thing, although I guess it's done for
compatibility. Thanks in advance.

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@netlab.cs.rpi.edu]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]

Am 23.10.2010 10:06, schrieb german diago:

> Hello. I've been reading allocators from the working draft and
> comparing them to those in the EASTL
> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/
> n2271.html) implementation. I have a doubt left: is it possible (and
> practical) in c++0x to define an allocator with no template argument?
> This could be useful in order to share an allocator between several
> types.
>

A C++0x allocator is still a value type-specific type. This does not
mean that the allocator itself is required to be a template, but it
usually makes the implementation much easier. In C++0x the required
associated types and function are strongly reduced over C++03, which
simplifies it much more to provide your own allocator.

If you want to share an allocator between several types, this is
very easily done by defining first a type-independent raw-memory-
allocator, e.g.

class raw_memory_allocator {
 raw_memory_allocator(/ctor args/);
 void* do_allocate(std::size_t n_bytes);
 void do_deallocate(void* p, std::size_t n_bytes);
};

and to build your type-specific allocator-template on top of this,
which is not much work given the required interface:

template <class T>
struct SimpleAllocator {
 typedef T value_type;
 SimpleAllocator(/ctor args/);
 template <class U>
 SimpleAllocator(const SimpleAllocator<U>& other);
 T* allocate(std::size_t n);
 void deallocate(T* p, std::size_t n);
};

Several strategies are possible to realize this: Private inheritance
or member ship are the first ideas that come into my mind.

And the second one: will allocators remain class based instead of
> instance based?
>

I'm not sure what you precisely mean with that, but an allocator
is initially assigned to a container and is part of the life-cycle
of this container. Container constructors take them by reference to
const, but this means they need to copy the originally provided one
(we have one exception I'm aware of this signature pattern: shared_ptr
accepts the allocator by value, but funnily allocate_shared by reference
to const again. Given move-semantics a consistent per-value signature
would probably make more sense). The usual get_allocator function
returns a copy of the allocator. If you need identity-control you
probably would need to use the same idioms as for function objects with
state.

Because I saw that allocators are returned by value, which I think
> it's a bad thing, although I guess it's done for compatibility.
> Thanks in advance.
>

Yes, I think that is the reason for this signature.

HTH & Greetings from Bremen,

Daniel Kr=FCgler

--
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use
mailto:std-c++@netlab.cs.rpi.edu<std-c%2B%2B@netlab.cs.rpi.edu>
]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html                      ]