Re: Ada containers and custom allocators

"Maciej Sobczak" <see.my.homepage@xxxxxxxxx> wrote in message
news:fb7764c5-31f9-488d-a0e6-53ffd6c96182@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On 8 Sty, 02:54, "Randy Brukardt" <ra...@xxxxxxxxxxxxxx> wrote:
....
The standard Ada containers do not provide any mechanism to control
how/were the container allocates memory.

This limitation prevents programmers from doing many interesting
optimizations. Even if we put performance issues aside, I might want
to control the memory allocation for reliability.

Yes, of course. It could be used for performance monitoring as well. But I
wouldn't characterize it as "many" interesting optimizations, it's more like
a few interesting things. But it isn't valuable enough to force every user
of a container to define a storage pool (since there is no name for a
standard storage pool). And we needed to keep the number of standard
containers manageable.

[...]
(or, the
storage pool passed would have to be completely general, allowing any
size
allocation, which would eliminate the vast majority of interesting
things
that you can do with storage pools).

There are ways to overcome this problem, at least for some container
types. Node-based containers could use fixed-size allocators, but of
course it is the container which would then instantiate the allocator
with the proper node size. It was possible in C++.

Only if you put severe limits on the implementations. For one thing, you
would need to know the fixed node size in the storage pool in order to take
any realistic advantage of it, but you couldn't ask the container's
implementation for that size since you'd have to pass the storage pool to
the instance. The only practical way to do that is to *require* a particular
node layout. We might as well just standardize the source code of the
container body in that case.

Moreover, there is no requirement in Ada that objects be laid out
continuously. Janus/Ada will often make several allocator calls when
allocating parts of an object, and those calls will all be different sizes.
That's especially true inside of a generic body, where essentially
everything that depends on a formal type is of an unknown size and thus has
to be allocated separately. Even if you had the source code of the body, it
probably would make different calls to Storage_Pool.Allocate on Janus/Ada
and on GNAT.

We'd also have to define what operations can calls the allocators.
Currently, there are no such restrictions on the containers implementation.

Also, of course, it would only work for a couple of the containers. All of
the hashed forms also are going to allocate the hash table, so there are
going to be odd-size allocations (more than just nodes). And the vectors are
likely to allocate chunks of various sizes.

The net effect is that this is not possible to define (or use) in any
useful, portable way. (If you're willing to stick to a single vendor, then
it is more possible, but that of course has nothing to do with the
standard.) Combined with the inability to name the standard storage pool,
there isn't much point in doing this for the primary containers.

The basic idea of the containers was to define a specification, and allow
implementers to innovate on the implementations. (They don't even have to be
in Ada.) The extra specification required to allow passing in a storage pool
would seriously reduce these possibilities.

The bounded forms seem to allow even better control over dynamic allocation
(by not having any in the common case, although that surely wouldn't be true
for Janus/Ada), are much easier to use (don't have to write a storage pool),
and would work for the high-intergrity types that cannot allow an allocator
near their program. Thus, they're the first focus of work. There are a lot
of other ideas, but I can't say what if anything will come of them.

Randy.


.

Relevant Pages

  • Re: allocator requirements
    ... >> the allocator for vector at least. ... This seems to directly contradict ... >> several containers with different value types. ... from the standard it cannot have the correct value type for all these ...
    (comp.lang.cpp)
  • allocator question (reposted here... sorry for the mistake)
    ... when passing an allocator to SEVERAL containers at the same time, ... template ... class MyContainer ...
    (microsoft.public.vc.stl)
  • allocator question
    ... when passing an allocator to SEVERAL containers at the same time, ... template ... class MyContainer ...
    (microsoft.public.vc.language)
  • Re: operator= in allocators
    ... But that makes no logical sense if containers own their allocator. ... vectorfoo() ... SomeAllocator a; ...
    (comp.lang.cpp)
  • Re: size_t and size_type
    ... the standard allocator). ... > implementations of the standard library to assume that vector<T, ... > In other words you cannot pass an allocator to a standard library container ... containers are required to define size_type as size_t. ...
    (comp.lang.cpp)