Hi folks....

   Im using STL by several months now...and I found it very exciting...

   but I was disapointed when I tried to implement a new allocator.

   The idea was to implement an allocator that reserves space into
   a shared memory...

   According to my understandig of the standard allocators were
   introduced to allow different allocation strategies and for
   alternative 'pointer' types.

   An allocator must provide both methods to allocate/delete
   objects and methods to return address/reference of the
   allocated objects...

   now, all the STL implementation I tried (SGI/RW/ObjectSpace)
   any container use the address/references methods provided by
   the allocator..

   ...so why are there?



-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

ivano@starway.tm.fr wrote:
>
>    Im using STL by several months now...and I found it very exciting...
>
>    but I was disapointed when I tried to implement a new allocator.
>
>    The idea was to implement an allocator that reserves space into
>    a shared memory...
>
>    According to my understandig of the standard allocators were
>    introduced to allow different allocation strategies and for
>    alternative 'pointer' types.
>
>    An allocator must provide both methods to allocate/delete
>    objects and methods to return address/reference of the
>    allocated objects...
>
>    now, all the STL implementation I tried (SGI/RW/ObjectSpace)
>    any container use the address/references methods provided by
>    the allocator..
>
>    ...so why are there?

You're message would make more sense if "any container use" was replaced
by "no container uses". Assuming that's the case, the reason is probably
in section 20.1.5, "Allocator requirements", paragraphs 4&5:

 |4 Implementations of containers described in this International Standard
 |  are  permitted to assume that their Allocator template parameter meets
 |  the following two additional requirements beyond those in Table 32.
 |
 |  --All instances of a given allocator type are required  to  be inter-
 |    changeable and always compare equal to each other.
 |
 |  --The  typedef  members pointer, const_pointer, size_type, and differ-
 |    ence_type are required to be T*, T const*,  size_t,  and ptrdiff_t,
 |    respectively.
 |
 |5 Implementors  are encouraged to supply libraries that can accept allo-
 |  cators that encapsulate more general memory models  and  that support
 |  non-equal   instances.   In  such  implementations,  any requirements
 |  imposed on allocators by containers  beyond  those  requirements that
 |  appear  in  Table  32,  and the semantics of containers and algorithms
 |  when  allocator  instances  compare  non-equal,  are  implementation-
 |  defined.

I suspect that there are very few implementations out there that don't
take advantage of these assumptions. Strictly conforming code therefore
can't violate those assumptions, while maximally portable templates that
take Allocator arguments shouldn't use those assumptions. It's a bit of
a mess.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote in article <35DB19B1.41C6@wizard.net>...
> >    According to my understandig of the standard allocators were
> >    introduced to allow different allocation strategies and for
> >    alternative 'pointer' types.

Once upon a time, yes. That was several compromises back, however.

>  |4 Implementations of containers described in this International Standard
>  |  are  permitted to assume that their Allocator template parameter meets
>  |  the following two additional requirements beyond those in Table 32.
>  |
>  |  --All instances of a given allocator type are required  to  be inter-
>  |    changeable and always compare equal to each other.

Thus, no per-object private storage for allocators.

>  |  --The  typedef  members pointer, const_pointer, size_type, and differ-
>  |    ence_type are required to be T*, T const*,  size_t,  and ptrdiff_t,
>  |    respectively.

Thus, no fancy pointer arithmetic or cacheing.

>  |5 Implementors  are encouraged to supply libraries that can accept allo-
>  |  cators that encapsulate more general memory models  and  that support
>  |  non-equal   instances.   In  such  implementations,  any requirements
>  |  imposed on allocators by containers  beyond  those  requirements that
>  |  appear  in  Table  32,  and the semantics of containers and algorithms
>  |  when  allocator  instances  compare  non-equal,  are  implementation-
>  |  defined.
>
> I suspect that there are very few implementations out there that don't
> take advantage of these assumptions.

True, but the Dinkum C++ Library tries harder than most to be accommodating.
It tests allocator objects for equality, and it constructs and destroys pointers.
You don't have much latitude with references, and any substitute you supply
for an integer type had better support integer-style arithmetic, but it's otherwise
pretty tolerant.

>  Strictly conforming code therefore
> can't violate those assumptions, while maximally portable templates that
> take Allocator arguments shouldn't use those assumptions.

Still true.

>  It's a bit of a mess.

An understatement.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com/hot_news.html



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]