Re: Ada containers and custom allocators

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcclk6zc91o.fsf@shell01.TheWorld.com...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
>
> > 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).
>
> That seems easy enough to fix.  Simply have a predefined function:
>
>     type Storage_Pool_Pointer is access all Root_Storage_Pool'Class;
>     function Default_Storage_Pool return Storage_Pool_Pointer;
>
> and use that for the default in the generic.
>
> Default_Storage_Pool must be general enough to support any size.
> There's no requirement that this be the same pool used by
> default for misc access types.

Maybe, but that could be a substantially worse pool on some implementations
than used for normal access types. So I'm unsure if that is a good idea.

> >... And we needed to keep the number of standard
> > containers manageable.
>
> I suppose, but we weren't shy about writing macros in English -- see for
> example package Float_Text_IO.  It would take one paragraph in the RM
> to double the number of container packages by having versions with
> a Pool parameter.  Pretty ugly, but there's precedent.

OK, but only if you are willing to leave absolutely everything about how the
pool is used implementation-defined. At which point, I have to wonder what
the point is: you couldn't do anything at all portably.

Otherwise, you're going to have to have wording about where user-defined
pool operations can be called, what happens to the exceptions that they
propagate, and possibly other issues that I haven't thought about yet. This
isn't going to be a single sentence change -- maybe more like the magnitude
of "Wide String Handling" (A.4.7).

...
> > Moreover, there is no requirement in Ada that objects be laid out
> > continuously.
>
> Perhaps there should be!

Over my dead body. A serious attempt to propose that would get very, very
nasty.

> But anyway, given this fact, user-defined storage pools need to be fully
> general (accept any size), or else depend on details of the Ada
> implementation.  This is not specific to containers.

Correct. But it means that little useful can be done with custom pools on
the predefined containers libraries. The needed generality prevents using
any optimizations in the pool, so it pretty much limits you to tracking the
allocations and deallocations.

...
> > We'd also have to define what operations can calls the allocators.
>
> I don't see why.

The current containers library spends quite a bit of effort defining the
places where objects can be destroyed (that is, where Finalize can be
called). Admittedly, a lot of that effort is to say that it isn't defined
closely. But one thing we don't do is allow random calls to reading
operations to call Finalize. Similarly, we always have wording to define
what and where exceptions are propagated.

If we allow user storage pools, we'd need the definitions of where those
operations can be called (hopefully not in operations that merely read and
return something!) and wording to say that the exceptions are propagated.
And probably other things as well.

> > 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.
>
> It can work -- you just can't take advantage of (say) fixed sized
> chunks.  I guess what you're saying is that that defeats the main
> purpose!

The OP claimed that fixed-size allocators could be used, and my lengthy
reply was intended to rebut that. Surely, they can't be used portably or
generally. It is true that you probably could do it on a specific
implementation for a specific element type (it would even work on Janus/Ada
that way). But as soon as you move to a different compiler (or even
potentially an update for the same compiler with an "improved" containers
library), it will no longer work. That might make sense to do for debugging,
but it can't be used for anything long term.

All of which begs the question of whether it is worth the work to
accomplish.

                                  Randy.



Of