«

Within the container library I have ignored (more or less) the problem
of the allocator and memory allocation.

I have a simple macro that has two values: either you use the garbage
collector and you have GC_malloc as allocator, or you use the
malloc/free system for maximum portability.

The problem with this simple approach is that many other solutions
exist. For instance you could want to pass a pointer to an allocator
of your own, or whatever...

I could make things more flexible by adding the allocator system
to every container by putting it in the container header.

Or I could add it to the virtual functions table of every container,
supposing tat you wouldn't want to change allocation for single
containers but for a class of containers, for instance all lists
or all hash tables, etc.

Obviously I do not want to make the interface heavier than it is now,
so the constructor functions will use a default allocator that will be
either GC_malloc or malloc according to how the library was compiled.

You can change the default allocator later.

If you have the allocator in the header you just do:

List->Allocator = myNewAllocator;

and only THAT list will use the myNewAllocator. There would be no way
to change the behavior of all lists.

If you have the allocator in the virtual functions table, you do

List->lpVtbl->Allocator = myNewAllocator;

and ALL lists will use the "myNewAllocator" function, even the new ones
since you have changed the value in the master vtable. That change will
be valid until the program ends (or you restore the old value of course)

If that is too sweeping change, you can still do:
(1) Make a copy of the vtable
(2) change the copy
(3) Put the copy in the lists you want to use the new allocator.

I think the second behavior is better design. t is more flexible, and
uses less space.

What do you think?

Thanks in advance for your attention.

P.S. the library of GNU (libavl) has an allocator pointer in each
container.

jacob navia <> writes:

> Within the container library I have ignored (more or less) the problem
> of the allocator and memory allocation.

One approach that you may not have considered is to make the
library's client do all the memory allocation work. This works
out OK for some kinds of containers where allocation corresponds
directly to client operations. For example, it works fine for
binary tree-based containers, where the client can be made to
provide memory for a node each time it wants to do an insertion
operation. The balanced tree library here works that way:
http://git.savannah.gnu.org/cgit/psp...c/libpspp/bt.h
http://git.savannah.gnu.org/cgit/psp...c/libpspp/bt.c

> P.S. the library of GNU (libavl) has an allocator pointer in each
> container.

If I had time to work on libavl, I'd probably switch to
client-allocated memory.
--
char a[]="\n .CJacehknorstu";int putchar(int);int main(void){unsigned long b[]
={0x67dffdff,0x9aa9aa6a,0xa77ffda9,0x7da6aa6a,0xa6 7f6aaa,0xaa9aa9f6,0x11f6},*p
=b,i=24;for(;p+=!*p;*p/=4)switch(0[p]&3)case 0:{return 0;for(p--;i--;i--)case+
2:{i++;if(i)break;else default:continue;if(0)case 1utchar(a[i&15]);break;}}}

On 2010-01-29, jacob navia <> wrote:
> Or I could add it to the virtual functions table of every container,
> supposing tat you wouldn't want to change allocation for single
> containers but for a class of containers, for instance all lists
> or all hash tables, etc.

Hmm.

My suggestion would be that the choice of allocator (and you should
probably have both an alloc and a free) should be made at the time of
creating a container. There is a reason for this: Consider what
happens if I add several items to a container, change its allocator,
add several more items to it, and then request that it free itself.
How will it know which allocator to use for which bits?

> Obviously I do not want to make the interface heavier than it is now,
> so the constructor functions will use a default allocator that will be
> either GC_malloc or malloc according to how the library was compiled.

I think this basically makes sense -- allow per-container overrides with
a configurable default used if none is provided.

> and only THAT list will use the myNewAllocator. There would be no way
> to change the behavior of all lists.

That seems reasonable enough -- it's not obvious that "all lists" would
be a good granularity. "each list" or "all containers" make more sense.

-s
--
Copyright 2010, all wrongs reversed. Peter Seebach / usenet-
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

jacob navia wrote:
> Within the container library I have ignored (more or less) the problem
> of the allocator and memory allocation.
>
> I have a simple macro that has two values: either you use the garbage
> collector and you have GC_malloc as allocator, or you use the
> malloc/free system for maximum portability.

Can your GC be specified at link time? The one I use is built as a
library and replaces malloc and free. I don't know if this is a common
trick on windows, but it's widely used on Unix and Unix like platforms.

> The problem with this simple approach is that many other solutions
> exist. For instance you could want to pass a pointer to an allocator
> of your own, or whatever...
>
> I could make things more flexible by adding the allocator system
> to every container by putting it in the container header.
>
> Or I could add it to the virtual functions table of every container,
> supposing tat you wouldn't want to change allocation for single
> containers but for a class of containers, for instance all lists
> or all hash tables, etc.

The ability to specify an allocator for each instance of a container is
one of the features that make the C++ STL very flexible, so you should
include it. In the absence of templates, using your virtual functions
tables would be the most flexible approach.

> Obviously I do not want to make the interface heavier than it is now,
> so the constructor functions will use a default allocator that will be
> either GC_malloc or malloc according to how the library was compiled.
>
> You can change the default allocator later.
>
> If you have the allocator in the header you just do:
>
> List->Allocator = myNewAllocator;
>
> and only THAT list will use the myNewAllocator. There would be no way
> to change the behavior of all lists.
>
> If you have the allocator in the virtual functions table, you do
>
> List->lpVtbl->Allocator = myNewAllocator;
>
> and ALL lists will use the "myNewAllocator" function, even the new ones
> since you have changed the value in the master vtable. That change will
> be valid until the program ends (or you restore the old value of course)

Ah, in that case my comment above was wrong, putting the allocator in
the header would be more flexible.

--
Ian Collins

Ian Collins:
> jacob navia wrote:
>> Within the container library I have ignored (more or less) the problem
>> of the allocator and memory allocation.
>>
>> I have a simple macro that has two values: either you use the garbage
>> collector and you have GC_malloc as allocator, or you use the
>> malloc/free system for maximum portability.
>
> Can your GC be specified at link time?

It is not "his" GC. He took it off Boehm, like he took "his" compiler off
Fraser and Hansen.

tea leaf a écrit :
> Ian Collins:
>> jacob navia wrote:
>>> Within the container library I have ignored (more or less) the problem
>>> of the allocator and memory allocation.
>>>
>>> I have a simple macro that has two values: either you use the garbage
>>> collector and you have GC_malloc as allocator, or you use the
>>> malloc/free system for maximum portability.
>> Can your GC be specified at link time?
>
> It is not "his" GC. He took it off Boehm, like he took "his" compiler off
> Fraser and Hansen.

Dear anonymous coward:

I did not "took it off". In the documentation, here in this discussion
group, and everywhere I have repeated that I adapted the work of Mr
Boehm, that explictly allows for copying and distributing.

tea leaf wrote:
> Ian Collins:
>> jacob navia wrote:
>>> Within the container library I have ignored (more or less) the problem
>>> of the allocator and memory allocation.
>>>
>>> I have a simple macro that has two values: either you use the garbage
>>> collector and you have GC_malloc as allocator, or you use the
>>> malloc/free system for maximum portability.
>> Can your GC be specified at link time?
>
> It is not "his" GC. He took it off Boehm, like he took "his" compiler off
> Fraser and Hansen.

I was making a suggestion, not starting a flame war. The suggestion
still stands.

--
Ian Collins

On Sat, 30 Jan 2010 17:52:35 +1300, Ian Collins wrote:

> The ability to specify an allocator for each instance of a container is
> one of the features that make the C++ STL very flexible,

Although the STL's approach to allocators isn't quite flexible enough for
some applications. EA developed their own version of the STL for this
reason; you might want to look at it to see if any of it is relevant
for your purposes.

http://www.open-std.org/jtc1/sc22/wg...007/n2271.html

Ian Collins <ian-> writes:
> tea leaf wrote:
>> Ian Collins:
>>> jacob navia wrote:
>>>> Within the container library I have ignored (more or less) the problem
>>>> of the allocator and memory allocation.
>>>>
>>>> I have a simple macro that has two values: either you use the garbage
>>>> collector and you have GC_malloc as allocator, or you use the
>>>> malloc/free system for maximum portability.
>>> Can your GC be specified at link time?
>>
>> It is not "his" GC. He took it off Boehm, like he took "his"
>> compiler off Fraser and Hansen.
>
> I was making a suggestion, not starting a flame war. The suggestion
> still stands.

This "tea leaf" is probably the same person as the "tea pot" troll
who's been harassing jacob. If so, I'd say he's best ignored.

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On 30 Jan 2010 at 19:31, Keith Thompson wrote:
> This "tea leaf" is probably the same person as the "tea pot" troll
> who's been harassing jacob.

As they're both clearly Richard HeathField, they are obviously also the
same as each other.