On 18 Oct 2000, at 14:21, Alex Rousskov <rousskov@measurement-factory.com> wrote:
> On Wed, 18 Oct 2000, Andres Kroonmaa wrote:
>
> > On Tue, Oct 17, 2000, Alex Rousskov wrote:
> > >
> > > -- Split Array into Array and PooledArray? MemPools will use Array that
> > > does not use MemPools. PooledArray can use MemPools.
> >
> > This is the same as implement array within mempools itself as private.
> > Would we need two public libs for arrays?
>
> I am not 100% sure what you mean, but there may be Array users that
> allocate objects that do/can/should not use mempools. So two kinds of
> arrays seems to be an appropriate approach.
actually, my plan to convert Arrays to mempools was limited in scope.
It is very difficult to create a memPool with expandable object size.
Pools are meant strictly for fixed sized objects.
What I was planning to do with Arrays was to allocate Array's internal
overhead memory from mempools, and also initial prealloced array data.
When array is grown, we get rid of Pool-based data, copy it to newly
xmalloced data, and revert back to current realloc based Arrays further
on. This is simple to do.
This would give memPool based Arrays for vast majority of cases, but
also does not interfere with Array functionality.
My problem was just that memPool itself was using Arrays, resulting
recursive reference. I think I'd better scrap use of arrays in memPools
to resolv this issue.
So I think we don't need PooledArray in addition to old Array api.
------------------------------------
Andres Kroonmaa <andre@online.ee>
Delfi Online
Tel: 6501 731, Fax: 6501 708
Pärnu mnt. 158, Tallinn,
11317 Estonia
Received on Wed Oct 18 2000 - 15:16:32 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:51 MST