Craig Perras <craigp@wolfenet.com> writes:

> 2 - i've been using SGI's STL library, where they use static functions in
> their allocators. this means you can't actually pass in an allocator
> object, but the static allocate and deallocate functions are used.
> however, i noticed in the standard that you pass in an allocator
> object. passing in an allocator object means you need to keep a reference
> to that object, increasing the size of all containersi (including
> strings!). this size increase may be unacceptable.
>
> is the SGI implementation conforming to the standard (or, more precisely,
> by a subset of the standard)? i think their implementation is superior -
> there is no space or run-time overhead. the only side-effect is you can't
> use run-time polymorphism. but considering it's an allocator, which
> presumably needs to have good performance, who would want to?

No, it doesn't precisely conform to the draft standard.

One problem is that allocators as defined in the draft standard are
unimplementable without member templates (take a look at the "rebind"
member), and compilers that support member templates are still
uncommon.  The SGI implementation uses a design that doesn't require
member templates.

The situation with member-specific data in the draft standard is a bit
more complicated.  What it boils down to is that allocators in the
draft are allowed to have non-static member functions, but standard
containers are allowed to assume that they have no member-specific
data.  Containers, as defined in the draft, are allowed to act as if
all allocators of the same type are interchangeable.
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Matt Austern <austern@sgi.com> wrote:

>No, it doesn't precisely conform to the draft standard.
>
>One problem is that allocators as defined in the draft standard are
>unimplementable without member templates (take a look at the "rebind"
>member), and compilers that support member templates are still
>uncommon.  The SGI implementation uses a design that doesn't require
>member templates.
>
>The situation with member-specific data in the draft standard is a bit
>more complicated.  What it boils down to is that allocators in the
>draft are allowed to have non-static member functions, but standard
>containers are allowed to assume that they have no member-specific
>data.  Containers, as defined in the draft, are allowed to act as if
>all allocators of the same type are interchangeable.

Hmm, unless I am misreading CD2, I think the last statement should be a
little stronger.  Containers, as defined in the draft, are (implicitly)
*required* to act as if all allocators of the same type are
interchangeable.  This precludes precisely conforming standard library
containers from having/using per-instance private pools of memory.

While private pools are something you won't want to use all the time,
when you do need them, they can be tremendously faster than shared
pools.

The XTL implementation extends the allocators and containers to permit
private pools, and do the right thing when they are used.

--Bob

====================================================================
Bob Steagall                                 steagall@deltalogic.com
DeltaLogic, Inc.                           http://www.deltalogic.com
1537 Kew Road                                   Voice (216) 321-8200
Cleveland Hts, OH 44118-1204                    Fax   (216) 321-6976
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

i am trying to implement a simplistic persistence scheme for standard
library components. i have therefore created a PAlloc (persistent
allocator) type, designed to be used with STL containers.

i would like to make persistence the property of objects, not classes.
the only way i can think of doing this is to parameterize all classes
which use STL components with class ALLOC. for instance, if i have an
Invoice class which keeps a list of Entries, i would do this if i
didn't care about hard-coding persistence:

class Invoice {
public:
 ...

private:
 list< Entry, less<Entry>, PAlloc > m_entries;
};

to make persistence a property of individual objects, i do this:

template <class Alloc>
class Invoice {
public:
 ...

private:
 list< Entry, less<Entry>, Alloc > m_entries;
};


is this how the standard libraries were meant to be used? at first glance,
this doesn't appear to be much of a hardship except for 2 things:

1 - std::strings are paramaterized by allocators. i use strings in nearly
all my classes.

2 - i've been using SGI's STL library, where they use static functions in
their allocators. this means you can't actually pass in an allocator
object, but the static allocate and deallocate functions are used.
however, i noticed in the standard that you pass in an allocator
object. passing in an allocator object means you need to keep a reference
to that object, increasing the size of all containersi (including
strings!). this size increase may be unacceptable.

is the SGI implementation conforming to the standard (or, more precisely,
by a subset of the standard)? i think their implementation is superior -
there is no space or run-time overhead. the only side-effect is you can't
use run-time polymorphism. but considering it's an allocator, which
presumably needs to have good performance, who would want to?


any ideas or advice is greatly appreciated.

--craig
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]