"James Kuyper" <kuyper@wizard.net> wrote in message
news:397A17C9.1E6110BB@wizard.net...
> 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.
>
Yes, it's feasible, no, MS hasn't done it, and no, nobody is likely to do
it. You've really been out of Windows programming for a while, eh? :-)
'Near' and 'far' are prehistoric concepts from the days of 16-bit Windows.
32-bit Windows uses the flat memory model, so the segmented memory model is
passe.

However, Win32 does have the concept of heaps, and I have at one time
implemented an allocator that encapsulates a Windows heap. It's use is
limited, of course, because of the per-object allocator prohibition. It can
only allocate all objects of one type on their own heap. This does mean such
heaps will never get fragmented, which may be a performance improvement in
some cases - but still, I implemented it more as a theoretical experiment
than anything else.

I don't think this really adds to the discussion of allocators in general,
though.

X.


---
[ 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              ]