What would be the right decision?

[jacob navia]

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.

 

[Ben Pfaff]

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/pspp.git/tree/src/libpspp/bt.h
http://git.savannah.gnu.org/cgit/pspp.git/tree/src/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.

 

[Seebs]

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

 

[Ian Collins]

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.

 

[tea leaf]

Ian Collins:

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.

 

[jacob navia]

tea leaf a écrit :

Ian Collins:

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.

 

[Ian Collins]

Ian Collins:

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.

 

[Nobody]

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/wg21/docs/papers/2007/n2271.html

 

[Keith Thompson]

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.

 

[Antoninus Twink]

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.

 

[Ian Collins]

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.

True, but I had a chuckle at someone using the handle "tea leaf"
effectively accusing someone of theft. I guess you have to come form my
part of the world to appreciate the joke.

 

[lawrence.jones]

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

And you're clearly jacob navia. Unless you have some real proof of your
delusions, give it a rest.

 

[Seebs]

And you're clearly jacob navia.

I was about to argue with this, but...

Unless you have some real proof of your
delusions, give it a rest.

It occurred to me that this was probably in the manner of a way of
illustrating a point. Ironic, that "Lawrence Jones" (we all know who
posts under THAT name, right?*) would make such an observation.

-s
[*] It's a nom-de-usenet for Larry Jones.

 

[Antoninus Twink]

I've just checked the headers for the "tea leaf" article. At the time
it was posted (using an ISP to which I have never subscribed), I was
89 miles[1] away from my Internet connection, standing in the frosty
London air outside St Luke's Community Centre in London, waiting
(somewhat impatiently) for the guy with the key, and in company with
seven eyewitnesses (two of whom I had not previously met, if that's
relevant). I think I could probably prove in a court of law that I
didn't post that article.

You know what? I believe you, Heathfield.

You've got all the self-righteous indignation of a man who's accused of
robbing a bank in Brooklyn, when at the time he was actually busy
robbing a bank in Manhattan.

So "tea leaf" isn't one of your many sock puppets, after all.

Of course, that will never be sufficient for a troll. They think what
they think, and let the facts go swing.

As usual, you've underestimated this "troll". Unlike you, my mind is not
closed and I'm willing to be convinced by the force of reason.