In article <9517719.16930@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU (Fergus Henderson) writes:
>An STL memory model is not just an address type, it is also a way of
>dynamically allocating and deallocating memory.
>
>You should be able to use STL Allocators to select your own custom
>memory management package for an STL collection.  For example, you
>might need to allocate certain data structures in shared memory.
>Or you might want to use a mark/release style memory management technique
>like GNU obstacks or Andrew Koenig's clusters, for efficiency.
>Or you might want to use a garbage-collecting allocator.
>
>(Well... you _should_ be able to do these things, presuming the
>committee got the details right.  I haven't had a close look myself yet.)

I've had a close look, and we don't have the details quite right yet, at
least for garbage collection. We need to move the destroy function template
into the allocator requirements, and specify that collections must use the
allocator for all allocations. Nathan Meyers has a proposal for this, which
I expect we will vote in next week.

In article <3s1st0$rv7@hustle.rahul.net>,
Ronald F. Guilmette <rfg@rahul.net> wrote:
>In article <AC08D938966825D93@sleipner.nts.mh.se>,
>Lars Farm <lars.farm@nts.mh.se> wrote:
>>... Why is a "memory model" mentioned in the draft? ...
>
>Don't get confused.  In the draft standard, the term ``memory model''
>is used only to refer to the programmer's conceptual view of memory,
>and how it behaves (or how it is used, allocated, etc) in various
>situations.  For example, a given hunk of memory might be in an
>``initialized'' state, or in an ``uninitialized'' state.
>
>In the draft, the term ``memory model'' bears no relationship to the
>kinds of ``memory models'' which are so familiar to x86 programmers.

 Don't get confused. The term "memory model" in the draft
describes, in the first instance, the semantics of part of the abstract
machine relating to kinds of memory (const/volatile), addressability,
validity of pointers, and pointer comparisons: it deals with allocation
and deallocation as well.

 In STL "allocator" types/objects can be used to
construct systems for extended memomry models above and
beyond the basic one mandated for the core language.

 They can be constructed by modelling _within_
the core language framework, or by hookikng to operating
system or vendor extensions (outside the normative
requirements of the Standard).

 That is, "memory model" has the SAME meaning
in both these cases.

 Example: the core memory model requires
that if a block of n bytes of memory is allocated,
then n+1 addresses are valid. Only n of these are dereferenceable.
This is an unusual feature.

 Example: the behaviour of < on addresses not of
the same allocation block is undefined.

 Example: copying an invalid pointer is undefined.

 Example: the memory allocated by

 malloc/realloc
 operator new
 operator new[]

can be of different kinds--

 realloc/free
 operator delete
 operator [] delete

can only delete memory of the appropriate kind.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <9517719.16930@mulga.cs.mu.oz.au>,
Fergus Henderson <fjh@munta.cs.mu.OZ.AU> wrote:
>
>You should be able to use STL Allocators to select your own custom
>memory management package for an STL collection.  For example, you
>might need to allocate certain data structures in shared memory.
>Or you might want to use a mark/release style memory management technique
>like GNU obstacks or Andrew Koenig's clusters, for efficiency.
>Or you might want to use a garbage-collecting allocator.
>
>(Well... you _should_ be able to do these things, presuming the
>committee got the details right.  I haven't had a close look myself yet.)
>

In theory, yes, it is trivial to add a new allocator (however
complicated the allocator design may be) to STL, but the current HP
implementation leaves a lot to be desired. I've looked at adding
persistence to STL containers using Texas Persistence Store, and the
only thing I've had to do was to create an allocator that creates
container elements in the persistent heap. The current HP implementation
(and all the others that follow it) uses a preprocessor define to switch
allocators, and that makes it very hard to mix and match different
allocators in your code (eg., transient and persistent in the same code).
ObjectSpace uses a dynamic allocator scheme that is much more effective
in cases like this -- you simply pass the allocator when you create the
container and the container then uses that allocator instead of the
default one.

Take a look at proto Persistent STL (pstl v0.1.1) for an example at:

  http://www.xraylith.wisc.edu/~khan/software/stl/STL.newbie.html#pers_stl

The STL spec is pretty clear, but I wonder how long it's going to take for
the implementations to catch up and do it right.

regards
mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

Cc: Fergus Henderson <fjh@munta.cs.mu.OZ.AU>

lars.farm@nts.mh.se (Lars Farm) writes:

>[...] there is only _one_ memory model on the machines I use,
>common to all these machines (68K and PPC). Every pointer is represented
>and interpreted the same way at the machine/OS level, convertible to/from
>each other without loss of information and without speed penalty. Hence my
>confusion, an address is an address is an address...

An STL memory model is not just an address type, it is also a way of
dynamically allocating and deallocating memory.

You should be able to use STL Allocators to select your own custom
memory management package for an STL collection.  For example, you
might need to allocate certain data structures in shared memory.
Or you might want to use a mark/release style memory management technique
like GNU obstacks or Andrew Koenig's clusters, for efficiency.
Or you might want to use a garbage-collecting allocator.

(Well... you _should_ be able to do these things, presuming the
committee got the details right.  I haven't had a close look myself yet.)

--
Fergus Henderson
fjh@cs.mu.oz.au
http://www.cs.mu.oz.au/~fjh
"The Internet interprets censorship as damage and routes around it" - anon.

In article <3rs9a9$eto@news.doit.wisc.edu>,
khan@xraylith.wisc.edu (Mumit Khan) wrote:

>In article <AC04B79696687055@sleipner.nts.mh.se>,
>Lars Farm <lars.farm@nts.mh.se> wrote:

>>What are the rules for converting pointers between "memory models"?
>>
>
>Fortunately so such thing in my world :-)

Not in mine either, there is only _one_ memory model on the machines I use,
common to all these machines (68K and PPC). Every pointer is represented
and interpreted the same way at the machine/OS level, convertible to/from
each other without loss of information and without speed penalty. Hence my
confusion, an address is an address is an address...

If I need allocators to model memory there must be different kinds of raw
addresses. If there are, I will stumble on some memory references that are
incompatible with other memory references. Unless I know what
differentiates them.

What differences could that be?

> Can you actually mix the memory
>models in STL in the same program?

All such incompatibilities are artificial, created and maintained only by
STL allocators. So yes, on these machines I can. On these machines I can
factor common code without penalty. I already know this. What about other
machines? What is a "memory model" mentioned in the draft?

Since the requirement by STL to model memory with allocators introduces a
cost (can't factor common code). I want to know what I'm paying for and
possibly how to _portably_ avoid this penalty.

 - lars

--
lars.farm@nts.mh.se

In article <AC08D938966825D93@sleipner.nts.mh.se>,
Lars Farm <lars.farm@nts.mh.se> wrote:
>... Why is a "memory model" mentioned in the draft? ...

Don't get confused.  In the draft standard, the term ``memory model''
is used only to refer to the programmer's conceptual view of memory,
and how it behaves (or how it is used, allocated, etc) in various
situations.  For example, a given hunk of memory might be in an
``initialized'' state, or in an ``uninitialized'' state.

In the draft, the term ``memory model'' bears no relationship to the
kinds of ``memory models'' which are so familiar to x86 programmers.

--

-- Ron Guilmette, Sunnyvale, CA ---------- RG Consulting -------------------
---- E-mail: rfg@segfault.us.com ----------- Purveyors of Compiler Test ----
---- finger: rfg@rahul.net ----------------- Suites and Bullet-Proof Shoes -

In article <AC04B79696687055@sleipner.nts.mh.se>,
Lars Farm <lars.farm@nts.mh.se> wrote:
>
>What benefits are there with allocators? Some have mentioned persistant
>objects, but must every vector<T> be punished for that? On the machines I
>use (68K and PowerPC) every pointer is an addres, every address is 32 bits,
>four byte aligned. The draft talks about "memory models". What is a "memory
>model"?

Persistence and object transportability are 2 (related) things that
allocators make much easier to do. Eg., I have an allocator that does
quite a bit of magic to transport STL containers over the net. I just
wanted to play with it and see how much work it took, and getting the
first result (it's a *extremeley* crude prototype implementation I did
as a consultant, so can't release it as is) was quite easy. With dynamic
allocators like ObjectSpace STL<ToolKit>'s, you can make these shared
among containers of *same* type and hence alleviate *some* of the bloat,
but still pay a penalty for each new type defined.

Currently I'm investigating using Texas Persistent Store to create a
Persistent STL, and if I can figure out the guts of Texas in the near
future, I'll have a proto release shortly thereafter.

>
>What are the rules for converting pointers between "memory models"?
>

Fortunately so such thing in my world :-) Can you actually mix the memory
models in STL in the same program?

mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/

I have a hard time understanding the benefits of allocators. The cost is
obvious: severely bloated code. Cheating with allocators I can do (and have
done):

class list_base {
    //  this class does all pointer manipulations
    //  can do since this is independant of stored data
    //  this class is unaware of allocators
...
    struct link {
        link *next;
        link *prev;
    };
...
    link *first();
    void insert( link *here, link *item );
    etc...
};

template <class T, class Allocator_for_Formal_Reasons>
class list {
    list_base base;
    struct node : list_base::link {
        T data;
        node( const T&x ) :data(x) {}
    };
    node *new_node( const T&x );    // use allocator
public:
    void push_front( const T& ) { base.insert( new_node(x) ); }
    etc...
    lot's of typedefs as required...

this saves _lots_ of duplicated code! In a tiny test pg with list<char> and
list<int> the diff between HP's list and the above was 30K. I should
mention that this list is just as capable as HP's except the list_base (and
only the list_base) is unaware of allocators. What numbers will I get when
there are lots of different lists, maps, sets, vectors and so on?

So the cost of allocators is obvious and real. Can this cost be avoided? Is
it possible to implement an STL container with common code factored like
above? I assume that a requirement is that all "link *" above really should
be templatized?

What benefits are there with allocators? Some have mentioned persistant
objects, but must every vector<T> be punished for that? On the machines I
use (68K and PowerPC) every pointer is an addres, every address is 32 bits,
four byte aligned. The draft talks about "memory models". What is a "memory
model"?

What are the rules for converting pointers between "memory models"?

Is there a solution to this problem?

 - lars




--
lars.farm@nts.mh.se

In article <AC04B79696687055@sleipner.nts.mh.se>, lars.farm@nts.mh.se (Lars Farm) says:
>
>I have a hard time understanding the benefits of allocators. The cost is
>obvious: severely bloated code. Cheating with allocators I can do (and have
>done):
...
>
>So the cost of allocators is obvious and real. Can this cost be avoided? Is
>it possible to implement an STL container with common code factored like
>above?
>--
>lars.farm@nts.mh.se

STL<ToolKit>, ObjectSpace's STL implementation, support dynamic
allocators so that a single instantation of a container may be used
with a variety of different allocators. Therefore, you don't recompile
the class for each kind of allocator. For more information, send email
to info@objectspace.com

- Graham