I have a basic implementation question on allocators:

  In Bjarne Stroustrup's  3rd edition, in section 19.4.1  on page 567,
  allocator is shown as a  template with one type parameter.  However,
  in  section  19.4.3,   under  Generalized  Allocators  an  allocator
  template called my_alloc is illustrated with 2 type parameters.  The
  first is a  contained type parameter (int, char,  double, etc. ) and
  the  second   is  an  allocator  type   parameter  (shared,  pooled,
  persistent, etc.)  which helps  to define the allocator itself.

I am now happily using  pooled shared memory allocators with linux and
gcc  which I  really  like.   My implementation  conforms  to the  one
parameter type,  as stlport  and gcc  seem to work  well with  it, but
logically I  prefer a  two parameter allocator  type.  Has  this issue
been reviewed?  Was there any discussion along this line?

marc

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Meyers" <smeyers@aristeia.com> wrote in message
news:MPG.13e6ee34299045e698972d@news.supernews.com...
> On Tue, 25 Jul 2000 09:03:24 CST, Dennis Yelle wrote:
> > containers of objects in non-shared memory, and can't use swap or
splice,
> > when the two containers are not of the same type.  list<... shared>,
> > and list<... unshared> have to be treated as different types.
>
> If they are of different types, the code must not compile, but my concern
> is when they are the same type but access different heaps.  Look again at
> what Andrew wrote:
>
>   Similarly, you might have multiple varieties of memory, such as
>   shared and unshared memory, with different allocators for each,
>   and you might want to allow your users to have different container
>   objects of the same type that store their elements in different
>   kinds of memory.
>
> Note that two objects of the same type might be using different areas of
> memory.  Andrew seemed to suggest that this can be made to work.  My claim
> is that it can't without help from the container implementations, i.e.,
> writing custom allocators is not enough.

Recap:
Two instances of the same allocator type must be interchangable.

Which means that it's obvious how to write different allocators for
different memory types (eg far/near/huge, which was probably the original
inspiration), but hard to write an allocator
that uses the same type of memory but in different pools.

So we need to get two memory pools have different *types* of allocator, not
just different instances.



So how about

template < typename T, int pool_id > pooled_allocator;

This means that with a different pool id, you get a new type of allocator.

The only limitation of this is that you'd have to decide on your pool id's
at compile time unless someone has a nifty way of instantiating templates
based on the value of a variable a runtime....


I agree that the extra assumption in 20.1.5/4 is limiting. Unfortunately,
splice makes it tricky to remove.

Or, is it more subtle than that?
"Implementations of containers described in this International Standard are
permitted to assume that *their*

Allocator template parameter meets the following two additional requirements
beyond those in Table 32."


In the right light, 'their' could refer to the container, *or* the
implementors. If the latter, then they can't assume anything about other
(user supplied) allocators. (I think that's stretching things a bit though.)


Ric


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Meyers" <smeyers@aristeia.com> wrote in message
news:MPG.13e768871359266a98972e@news.supernews.com...
> On Wed, 26 Jul 2000 01:25:37 CST, Mark Rodgers wrote:
> It's my understanding that a conforming implementation may store only a
> single allocator for every object of a particular type, e.g., all objec=
ts
> of type vector<Widget> would share a single allocator.  Furthermore, it=
's
> my understanding that some STL implementation actually work this way.  =
The
> portion of the standard that makes this possible is paragraph 4 of 20.1=
.5:
>
>   Implementations of containers described in this International Standar=
d
>   are permitted to assume that their Allocator template parameter meets
>   the following two additional requirements beyond those in Table 32.
>
>     =97 All instances of a given allocator type are required to be
>     interchangeable and always compare equal to each other.

My understanding was that all objects of type vector<Widget> may indeed
use the same allocator because they are using std::allocator, so the
implementation is free to treat this differently.  SGI, for example, use
a traits class and to identify allocators that don't need individual
instances and thus eliminate the extra copies.  By default (allocators
that haven't specialised the traits) you'll get your own copy.

However, I believe an implementation _must_ store separate allocators
along with each vector<Widget,MyAllocator<Widget> >.  I don't think the
above clause eliminates that responsibility; it just add constraints
on me that one MyAllocator<Widget> must be interchangeable with another
(by which I assume that means the must be able to free each other's
memory), and that they must compare equal.  Those requirements don't
mean they have to be the same object.

23.1p8 is quite explicit

  "A copy of this argument is used for any memory allocation performed,
  by these constructors and by all member functions, during the lifetime
  of each container object."

It doesn't say, "A copy of this argument, or some other allocator that
is interchangeable and compares equal, ..."

However, you may be right.  I seldom have much luck interpreting the
standard, and my strict "the implementation must do exactly what the
standard says" interpretations are invariably wrong.  :-(  If so, I
agree that per-object allocators are a complete waste of time, and it
would be better if the standard hadn't included them.  The STL didn't.

Mark




---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Matthew Austern wrote:
....
> Similarly, some possibilities for swap():
>  (1) C1.swap(C2) is forbidden unless C1.get_allocator() ==
>      C2.get_allocator().  Again, "forbidden" might mean a couple
>      of different things.
>  (2) If C1.get_allocator() != C2.get_allocator(), then swap is
>      required to use the less efficient method that involves 3N
>      assignments.
>  (3) swap() should swap both the containers' data and the containers'
>      allocators.

It don't think anything other than (3) would be legal, given the
definition of swap(). In any event, it's IMHO the most convenient
option, with no defects that are obvious to me.

> I tend to favor option (1) in both cases.  There hasn't been any
> recent discussion of this in the LWG, however, so I'm not sure what
> the other people in the LWG think.

Why do you favor (1) for swap()? It unnecessarily disallows something
that can be done very efficiently using option (3).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Andrew Koenig wrote:
>
> In article <MPG.13e6ee34299045e698972d@news.supernews.com>,
> Scott Meyers <smeyers@aristeia.com> wrote:
>
> >If they are of different types, the code must not compile, but my concern
> >is when they are the same type but access different heaps.  Look again at
> >what Andrew wrote:
>
> >  Similarly, you might have multiple varieties of memory, such as
> >  shared and unshared memory, with different allocators for each,
> >  and you might want to allow your users to have different container
> >  objects of the same type that store their elements in different
> >  kinds of memory.
>
> >Note that two objects of the same type might be using different areas of
> >memory.  Andrew seemed to suggest that this can be made to work.  My claim
> >is that it can't without help from the container implementations, i.e.,
> >writing custom allocators is not enough.
>
> ... but that's no problem if you are the library vendor, which is what
> I assumed when I wrote the paragraph above.
> --
> Andrew Koenig, ark@research.att.com, http://www.research.att.com/info/ark

Please clarify what you meant in that paragraph above when
you said, "of the same type".
When I read it, I thought you were just speaking casually, and
Scott misunderstood because he thought you were talking precisely.
Now, I am not sure what you really meant.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  http://table.jps.net/~vert

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marc D Bumble wrote:
>
> I have a basic implementation question on allocators:
>
>   In Bjarne Stroustrup's  3rd edition, in section 19.4.1  on page 567,
>   allocator is shown as a  template with one type parameter.  However,
>   in  section  19.4.3,   under  Generalized  Allocators  an  allocator
>   template called my_alloc is illustrated with 2 type parameters.  The
>   first is a  contained type parameter (int, char,  double, etc. ) and
>   the  second   is  an  allocator  type   parameter  (shared,  pooled,
>   persistent, etc.)  which helps  to define the allocator itself.
>
> I am now happily using  pooled shared memory allocators with linux and
> gcc  which I  really  like.   My implementation  conforms  to the  one
> parameter type,  as stlport  and gcc  seem to work  well with  it, but
> logically I  prefer a  two parameter allocator  type.  Has  this issue
> been reviewed?  Was there any discussion along this line?

The standard doesn't say anthing about the template parameters of
allocators. They can have as many or as few as you want (though it's
hard to imagine how rebind<T>::other can be implemented without at least
one templated class).

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

This implies that the STL should work with allocator taking more than
one template parameter.  However, that was not the case the last time
I tested stlport.

marc
>>>>> "James" == James Kuyper <kuyper@wizard.net> writes:

    James> Marc D Bumble wrote:
    James> The standard doesn't say anthing about the template
    James> parameters of allocators. They can have as many or as few
    James> as you want (though it's hard to imagine how
    James> rebind<T>::other can be implemented without at least one
    James> templated class).


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Marc D Bumble wrote:
>
> This implies that the STL should work with allocator taking more than
> one template parameter.  However, that was not the case the last time
> I tested stlport.

What precisely went wrong?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> For these and other reasons, I can't generate much enthusiasm for
> allocators.  Still, I have this lurking suspicion that people have managed
> to find legitimate uses for them anyway.  For example, allocators do seem
> to offer a reasonable way to guarantee that every object in a container is
> located in the same heap (though I recognize that there's no way to
> guarantee that the internal data structures for the container itself are
> located in that heap).

On a previous Windows NT project that required a kernel-level network
driver, we used STL extensively.  When working at the kernel level we
couldn't rely on the default allocator and instead one of the programmers
wrote an allocator that returned memory from non-paged pool memory using the
NDIS memory routines.  I believe that this would fall under your example of
guaranteeing that the memory comes from the same (or correct) heap.

As for different objects of the same container type having different
allocator objects (but of the same type), I have tried to be conservative in
assuming that the allocator objects are not necessarily the same.

Of course, I am still waiting for Microsoft to get their STL implementation
in line with the standard.  As a learning process I coded an STL hash table
(I know that SGI already has one) and to my dismay realized that I could not
make things work by writing a standards-compliant allocator that supported
rebind because that code would break the compiler with an internal compiler
error.  There is a workaround...otherwise list<T>, and other containers that
have to allocate memory chunks that are not the same size of T, would not
work.  Their allocator has a method called charalloc that allocates chunks
of any size.

Jamie


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers wrote:
[...]
> Does the standard really guarantee that this will work?  Suppose you have
> two lists, L1 and L2, of the same type, but with different allocator
> objects, one for shared memory, one for unshared memory.  Assume L1 is
> supposed to be in shared memory and L2 is supposed to be in unshared
> memory.  Now we splice some nodes from L1 to L2, so L2 now has some nodes
> in shared memory and some nodes in unshared memory.

That would be illegal, even if the compiler does not catch it.

> Or consider something even simpler:
>
>   L1.swap(L2);

That too would be illegal.

> I've heard of implementations that don't swap allocator objects in the
> above, because there's no point.  After all, L1's and L2's allocators must
> be equivalent.
>
> I think in order for these kinds of things to work, you can't just provide
> some new allocator types, you have to actually reimplement all the standard
> containers so that they no longer take advantage of the assumptions they
> are allowed to make.
>
> Scott

No, it is just that in the situation you describe (shared memory vs.
unshared memory) the programmer has to keep track of which containers
are containers of objects in shared memory, and which containers are
containers of objects in non-shared memory, and can't use swap or splice,
when the two containers are not of the same type.  list<... shared>,
and list<... unshared> have to be treated as different types.
In just the same way, one cannot expect to be able to use swap or splice
on two lists if one is a list of int and the other is a list of double.

Dennis Yelle
--
I am a computer programmer and I am looking for a job.
There is a link to my resume here:  http://table.jps.net/~vert

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.13e65719593cf3e098972b@news.supernews.com>,
smeyers@aristeia.com (Scott Meyers) wrote:

| On Tue, 25 Jul 2000 06:36:28 CST, Andrew Koenig wrote:
| > Similarly, you might have multiple varieties of memory, such as
| > shared and unshared memory, with different allocators for each,
| > and you might want to allow your users to have different container
| > objects of the same type that store their elements in different
| > kinds of memory.  The notion that each container object holds
| > its own allocator would give you a basis for extending the
| > standard library to provide those facilities.
|
| Does the standard really guarantee that this will work?  Suppose you have
| two lists, L1 and L2, of the same type, but with different allocator
| objects, one for shared memory, one for unshared memory.  Assume L1 is
| supposed to be in shared memory and L2 is supposed to be in unshared
| memory.  Now we splice some nodes from L1 to L2, so L2 now has some nodes
| in shared memory and some nodes in unshared memory.

I might be wrong, but the way I read Andy was that "different allocators"
meant different types of allocators. i.e. shared_mem_allocator<T> and
unshared_mem_allococator<T>.  If that's the case, then L1 and L2 are also
of different types, so you can't splice between them.

-Howard

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Scott Meyers" <smeyers@aristeia.com> wrote in message
news:MPG.13e2b992f3c48ec5989728@news.supernews.com...
> Allocators are weird.  They have typedefs called "pointer" and "reference"
> that suggest you can create your own pointer and reference types, but you
> can't: library implementers are permitted to assume that
> allocator<T>::pointer is T* and allocator<T>::reference is T&.

I strongly suspect that allocators exist primarily because of Win16.
Back in the old days, the HP STL provided near, far and huge allocators
in which pointer would be T __near*, T __far*, and T __huge*
respectively.  So although they were all T*, they were different kinds
of T*.

This was extremely useful.  At the time I was using vector<graphic*>
in many places in my CAD system.  Since it was using __far pointers
(able to address blocks upto 64K in size), I could only hold 16384
graphics.  When customers ran into this limit I was forced to rethink.
By changing to a huge allocator, I was able to remove the limit.
(Admittedly, I could also have used a deque or a list instead, and
did change to a list later).

Two lessons I learned were:

1. On segmented architectures in particular, allocators are your
   friends.
2. Do not litter your code with "vector<Foo>" if there is any danger
   that you might want to change it to "vector<Foo,SomeOtherAllocator>"
   or "list<Foo>"; write "vector<Foo>" once in a typedef, and use the
   new name everywhere else.

Unfortunately the C++ of 1995 was not as powerful as today, so
switching allocators was achieved with macro wizardry (and the result
was "huge_vector<graphic*>" rather than "vector<graphic*,
huge_allocator<graphic*> >" - some might call that a bonus!).
Nowadays, I can well imagine that segmented architectures would
still benefit from the ability to define different sorts of
allocators for the different sorts of pointers, and that it would be
relatively painless to do so.  OTOH, using the STL on such a platform
without this ability would be a real pain.

> If you have two Container<T> objects, x and y, you can pass different
> allocators to the constructors for x and y, but library implementers are
> permitted to assume that all objects of the same type use the same
> allocator.  So per-object allocators are pretty useless.

I don't understand what you mean here.  AFAIK, all containers have their
own allocator, which is normally a newly constructed instance of the
default allocator (std::allocator<T>).  In the case of copy constructors,
the allocator is _copied_ from the source container; the allocator used
by the new container is not the same allocator as in the original.

The only limitation I know of is that one instance of an allocator
must be prepared to free memory allocated by another allocator of the
same type, otherwise you wouldn't be able to splice lists, but that
doesn't mean the two lists have to be using the exact same allocator -
they certainly won't be.

Mark


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers wrote:
....
> Does the standard really guarantee that this will work?  Suppose you have
> two lists, L1 and L2, of the same type, but with different allocator
> objects, one for shared memory, one for unshared memory.  Assume L1 is
> supposed to be in shared memory and L2 is supposed to be in unshared
> memory.  Now we splice some nodes from L1 to L2, so L2 now has some nodes
> in shared memory and some nodes in unshared memory.
>
> Or consider something even simpler:
>
>   L1.swap(L2);

Keep in mind that L1 has type std::list<T,SharedAllocator>, and L2 has
type std::list<T,UnsharedAllocator>. These are different types, so the
swap call is not allowed. The same objection applies to splice().

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Tue, 25 Jul 2000 09:03:24 CST, Dennis Yelle wrote:
> containers of objects in non-shared memory, and can't use swap or splice,
> when the two containers are not of the same type.  list<... shared>,
> and list<... unshared> have to be treated as different types.

If they are of different types, the code must not compile, but my concern
is when they are the same type but access different heaps.  Look again at
what Andrew wrote:

  Similarly, you might have multiple varieties of memory, such as
  shared and unshared memory, with different allocators for each,
  and you might want to allow your users to have different container
  objects of the same type that store their elements in different
  kinds of memory.

Note that two objects of the same type might be using different areas of
memory.  Andrew seemed to suggest that this can be made to work.  My claim
is that it can't without help from the container implementations, i.e.,
writing custom allocators is not enough.

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Wed, 26 Jul 2000 01:25:37 CST, Mark Rodgers wrote:
> I don't understand what you mean here.  AFAIK, all containers have their
> own allocator, which is normally a newly constructed instance of the
> default allocator (std::allocator<T>).  In the case of copy constructors,
> the allocator is _copied_ from the source container; the allocator used
> by the new container is not the same allocator as in the original.

It's my understanding that a conforming implementation may store only a
single allocator for every object of a particular type, e.g., all objects
of type vector<Widget> would share a single allocator.  Furthermore, it's
my understanding that some STL implementation actually work this way.  The
portion of the standard that makes this possible is paragraph 4 of 20.1.5:

  Implementations of containers described in this International Standard
  are permitted to assume that their Allocator template parameter meets the
  following two additional requirements beyond those in Table 32.

        All instances of a given allocator type are required to be
    interchangeable and always compare equal to each other.

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Allocators are weird.  They have typedefs called "pointer" and "reference"
that suggest you can create your own pointer and reference types, but you
can't: library implementers are permitted to assume that
allocator<T>::pointer is T* and allocator<T>::reference is T&.

If you have two Container<T> objects, x and y, you can pass different
allocators to the constructors for x and y, but library implementers are
permitted to assume that all objects of the same type use the same
allocator.  So per-object allocators are pretty useless.

For these and other reasons, I can't generate much enthusiasm for
allocators.  Still, I have this lurking suspicion that people have managed
to find legitimate uses for them anyway.  For example, allocators do seem
to offer a reasonable way to guarantee that every object in a container is
located in the same heap (though I recognize that there's no way to
guarantee that the internal data structures for the container itself are
located in that heap).

I'm quite interested in allocator success stories.  If you've used STL
allocators successfully, I encourage you to post here or send me mail and
let me know about it.  I'm also interested in the kinds of tasks for which
allocators are well suited.  If you have something good to say about
allocators, please say it now!

Thanks,

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <MPG.13e2b992f3c48ec5989728@news.supernews.com>, Scott Meyers
<smeyers@aristeia.com> writes
>I'm quite interested in allocator success stories.  If you've used STL
>allocators successfully, I encourage you to post here or send me mail and
>let me know about it.  I'm also interested in the kinds of tasks for which
>allocators are well suited.  If you have something good to say about
>allocators, please say it now!

I do not know if Sean Corfield takes this newsgroup, but I am pretty
certain that he is one of the few people in the World to make
constructive use of allocators. I think we were pretty close to taking
them out of the Standard at one time had it not been that a couple of
experts in the arcane had been using them:)


Francis Glassborow      Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Scott Meyers wrote:
>
> Allocators are weird.  They have typedefs called "pointer" and "reference"
> that suggest you can create your own pointer and reference types, but you
> can't: library implementers are permitted to assume that
> allocator<T>::pointer is T* and allocator<T>::reference is T&.
>
> If you have two Container<T> objects, x and y, you can pass different
> allocators to the constructors for x and y, but library implementers are
> permitted to assume that all objects of the same type use the same
> allocator.  So per-object allocators are pretty useless.
....

I've often wondered whether allocators could be used to wrap nmalloc()
and fmalloc() (allocation from the 'near' and 'far' heaps respectively)
in MSVC++. However, since I've escaped the need to worry about
programming for Windows, I've no idea whether that's actually feasible,
or even whether MS has already done it. They would necessarily be
implementation-specific, so MS could in principle deliver a standard
library specialized to do the right thing, at least with those
particular allocators.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

I heard about an allocator that synchronizes access to heaps.
This allows some containers (may be all) to be thread safe, only by
instanciating them with this allocator.

Allocators are also intersting by them selves. I mean: without using them in
a container. For instance, given a buffer (for instance a shared memory
buffer), we may imagine an allocator that manages this buffer as a heap.

Hicham BOUHMADI  hicham@citeweb.net

Scott Meyers <smeyers@aristeia.com> a    crit dans le message :
MPG.13e2b992f3c48ec5989728@news.supernews.com...
> Allocators are weird.  They have typedefs called "pointer" and "reference"
> that suggest you can create your own pointer and reference types, but you
> can't: library implementers are permitted to assume that
> allocator<T>::pointer is T* and allocator<T>::reference is T&.
>
> If you have two Container<T> objects, x and y, you can pass different
> allocators to the constructors for x and y, but library implementers are
> permitted to assume that all objects of the same type use the same
> allocator.  So per-object allocators are pretty useless.
>
> For these and other reasons, I can't generate much enthusiasm for
> allocators.  Still, I have this lurking suspicion that people have managed
> to find legitimate uses for them anyway.  For example, allocators do seem
> to offer a reasonable way to guarantee that every object in a container is
> located in the same heap (though I recognize that there's no way to
> guarantee that the internal data structures for the container itself are
> located in that heap).
>
> I'm quite interested in allocator success stories.  If you've used STL
> allocators successfully, I encourage you to post here or send me mail and
> let me know about it.  I'm also interested in the kinds of tasks for which
> allocators are well suited.  If you have something good to say about
> allocators, please say it now!
>
> Thanks,
>
> Scott
>
> ---
> [ comp.std.c++ is moderated.  To submit articles, try just posting with ]
> [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
> [              --- Please see the FAQ before posting. ---               ]
> [ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]
>


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On Tue, 25 Jul 2000 06:36:28 CST, Andrew Koenig wrote:
> Similarly, you might have multiple varieties of memory, such as
> shared and unshared memory, with different allocators for each,
> and you might want to allow your users to have different container
> objects of the same type that store their elements in different
> kinds of memory.  The notion that each container object holds
> its own allocator would give you a basis for extending the
> standard library to provide those facilities.

Does the standard really guarantee that this will work?  Suppose you have
two lists, L1 and L2, of the same type, but with different allocator
objects, one for shared memory, one for unshared memory.  Assume L1 is
supposed to be in shared memory and L2 is supposed to be in unshared
memory.  Now we splice some nodes from L1 to L2, so L2 now has some nodes
in shared memory and some nodes in unshared memory.

Or consider something even simpler:

  L1.swap(L2);

I've heard of implementations that don't swap allocator objects in the
above, because there's no point.  After all, L1's and L2's allocators must
be equivalent.

I think in order for these kinds of things to work, you can't just provide
some new allocator types, you have to actually reimplement all the standard
containers so that they no longer take advantage of the assumptions they
are allowed to make.

Scott

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]