Question about C++ Allocatars

[Cy Edmunds]

I have a quastion for the C++ professionals and members of the C++

standartization commetee.

I'm not a member of the standards committee but I suppose I am a C++
professional.

As i know C++ standart requires an allocator to be a templated parameter in every STL container.
Besides that one can pass reference to allocatior into every STL

container. This raises the following questions:

1. Containers that were templatized with different allocators are

considered different types and thus cannot be assigned to each other. Should
this be considered a drawback or a feature?

It is extremely easy to copy one STL container to another -- even a list to
a vector, for instance. If you like to see the = sign, you can write your
own operator = for two specific types. Hence this point doesn't seem like a
problem to me.

2. It is hard to implement pool/shared memory allocation logic since every

instance of any STL container will has its own copy of an allocator.

I don't know enough about writing allocators to comment on this.

[snip]

 

[Cy Edmunds]

Writing separate function where you will iterate through entire
container to copy its elements one by one, as you suggested is extremely
slow. Try as an example to copy one vector into another using ==
operator or copy constructor and you will see that it works hundreds of
times faster then iterating throug elements to copy them. It IS
therefore an issue.

You have an implementation of the standard library which does something else
for operator = other than copy the elements one at a time? What does it do
instead?

My implementation copies the objects one at a time whether you use a copy
constructor or an assignment operator. I don't see how it could be
otherwise.

 

[regisser]

I have a quastion for the C++ professionals and members of the C++ standartization commetee.

As i know C++ standart requires an allocator to be a templated parameter in every STL container.
Besides that one can pass reference to allocatior into every STL container. This raises the following questions:
1. Containers that were templatized with different allocators are considered different types and thus cannot be assigned to each other. Should this be considered a drawback or a feature?
2. It is hard to implement pool/shared memory allocation logic since every instance of any STL container will has its own copy of an allocator.

I am not entirely sure whether the first one should be qualified as a drawback or as a feature. Suppose that instead of the way STL implements allocators currently, custom allocators would be inherited from a common base class and every container would have a pointer to that base class. In this case we could easily assign containers created with different allocators to each other. Hoever, I dont know whether we should consider allocators(or pointers to allocators) part of the container data. That is, if allocators were implemented as pointers to base class, would we copy them when one container is assigned to another? Probably not, since the allocation scheme is something given to container at the initialization time and changing that does not make much sense? If we dont consider allocators part of container data, then it is a drawback that in STL we cannot assign containers to each other if they were templatized with different allocators.

As far as the second item is concerned, if allocators were implemented as pointers to base class, it would be easier to share the complicated allocation schemes (such as pool or shared memory allocation) among containers.
Currently each container gets its own copy of alolocator.

Please i would like to hear you opinion regarding this matter (allocators as template parameters vs. allocators inherited from common base class, pointer to which containers can share).
Thanks in advance,

OM

 

[Cy Edmunds]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous).

"Copy in blocks?" You mean like memcopy? That is only safe for POD types.

If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.

[snip]

OK, please post the program you used to determine the speed differences you
claim. Or show the code of a std::vector implementation which does not copy
item for item in its assignment operator.

 

[OM]

Writing separate function where you will iterate through entire
container to copy its elements one by one, as you suggested is extremely
slow. Try as an example to copy one vector into another using ==
operator or copy constructor and you will see that it works hundreds of
times faster then iterating throug elements to copy them. It IS
therefore an issue.

OM

I have a quastion for the C++ professionals and members of the C++

standartization commetee.

I'm not a member of the standards committee but I suppose I am a C++
professional.

As i know C++ standart requires an allocator to be a templated parameter

in every STL container.

Besides that one can pass reference to allocatior into every STL

container. This raises the following questions:

1. Containers that were templatized with different allocators are

considered different types and thus cannot be assigned to each other. Should
this be considered a drawback or a feature?

It is extremely easy to copy one STL container to another -- even a list to
a vector, for instance. If you like to see the = sign, you can write your
own operator = for two specific types. Hence this point doesn't seem like a
problem to me.

2. It is hard to implement pool/shared memory allocation logic since every

instance of any STL container will has its own copy of an allocator.

I don't know enough about writing allocators to comment on this.

[snip]

 

[OM]

error: using operator =

Writing separate function where you will iterate through entire
container to copy its elements one by one, as you suggested is extremely
slow. Try as an example to copy one vector into another using ==
operator or copy constructor and you will see that it works hundreds of
times faster then iterating throug elements to copy them. It IS
therefore an issue.

OM

I have a quastion for the C++ professionals and members of the C++

standartization commetee.

I'm not a member of the standards committee but I suppose I am a C++
professional.

As i know C++ standart requires an allocator to be a templated parameter

in every STL container.

Besides that one can pass reference to allocatior into every STL

container. This raises the following questions:

1. Containers that were templatized with different allocators are

considered different types and thus cannot be assigned to each other.
Should
this be considered a drawback or a feature?

It is extremely easy to copy one STL container to another -- even a
list to
a vector, for instance. If you like to see the = sign, you can write your
own operator = for two specific types. Hence this point doesn't seem
like a
problem to me.

2. It is hard to implement pool/shared memory allocation logic since
every

instance of any STL container will has its own copy of an allocator.

I don't know enough about writing allocators to comment on this.

[snip]

 

[Jeff Schwab]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous).

"Copy in blocks?" You mean like memcopy? That is only safe for POD types.

If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.

[snip]

OK, please post the program you used to determine the speed differences you
claim. Or show the code of a std::vector implementation which does not copy
item for item in its assignment operator.

Take a look at your headers. My library's vectors (g++/libstdc++) use
memmove for POD types.

Anyway, the point is that the type of the allocator really is part of
the type of the container. It's not contained by the container; it
doesn't even have to be instantiated. The container can get everything
it needs through the static methods of an allocator class. Would it
make sense to be able to assign a list to a vector? Well, it certainly
could have been part of the standard, but there are good reasons it's
not, all of which come down to the fact that a list and a vector are not
of the same type. Similarly, two containers that were instantiated
from the same template, but with different template arguments, are not
the same type.

 

[Cy Edmunds]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous).

"Copy in blocks?" You mean like memcopy? That is only safe for POD types.

If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.

[snip]

OK, please post the program you used to determine the speed differences you
claim. Or show the code of a std::vector implementation which does not copy
item for item in its assignment operator.

Take a look at your headers. My library's vectors (g++/libstdc++) use
memmove for POD types.

Hehe, somebody told me not long ago that my compiler was stupid. It doesn't
have any specializations for POD types further confirming this assessment.


OK, getting back to the original point, if you're using POD data and your
library uses memmove to copy but your allocators are different you can't
take advantage of this optimization. It's not the kind of thing that keeps
me awake at night.

Anyway, the point is that the type of the allocator really is part of
the type of the container. It's not contained by the container; it
doesn't even have to be instantiated. The container can get everything
it needs through the static methods of an allocator class. Would it
make sense to be able to assign a list to a vector? Well, it certainly
could have been part of the standard, but there are good reasons it's
not, all of which come down to the fact that a list and a vector are not
of the same type. Similarly, two containers that were instantiated
from the same template, but with different template arguments, are not
the same type.

Right -- assigning a list to a vector would be logically inconsistent, but
provisions have still been made to copy the elements from one to another
which gives you the same capability without the logical disconnect. And I
agree that the same reasoning should apply to containers which differ only
in template arguments.

 

[OM]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous). If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.

OM

 

[Jeff Schwab]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous).


"Copy in blocks?" You mean like memcopy? That is only safe for POD

types.

If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.


[snip]

OK, please post the program you used to determine the speed differences

you

claim. Or show the code of a std::vector implementation which does not

copy

item for item in its assignment operator.

Take a look at your headers. My library's vectors (g++/libstdc++) use
memmove for POD types.

Hehe, somebody told me not long ago that my compiler was stupid. It doesn't
have any specializations for POD types further confirming this assessment.


OK, getting back to the original point, if you're using POD data and your
library uses memmove to copy but your allocators are different you can't
take advantage of this optimization. It's not the kind of thing that keeps
me awake at night.

Nor should it. Assignment of vectors of non-POD elements wasn't
disallowed just because memmove couldn't be used.

Right -- assigning a list to a vector would be logically inconsistent, but
provisions have still been made to copy the elements from one to another
which gives you the same capability without the logical disconnect. And I
agree that the same reasoning should apply to containers which differ only
in template arguments.

You can copy vectors in the same way.

#include <memory>
#include <vector>

namespace
{
template< typename T >
class Allocator: public std::allocator< T >
{

};

template< typename C1, typename C2 >
C1& assign( C1& c1, C2 const& c2 )
{
c1.clear( );
std::copy( c2.begin( ), c2.end( ),
std::back_inserter( c1 ) );
}
}

int main( )
{
std::vector< int, std::allocator< int > > v1( 3, '1' );
std::vector< int, Allocator< int > > v2( 5, '2' );

// v = w; // Won't compile.

assign( v1, v2 );
}

 

[tom_usenet]

I have a quastion for the C++ professionals and members of the C++ standartization commetee.

As i know C++ standart requires an allocator to be a templated parameter in every STL container.
Besides that one can pass reference to allocatior into every STL container. This raises the following questions:
1. Containers that were templatized with different allocators are considered different types and thus cannot be assigned to each other. Should this be considered a drawback or a feature?

I suppose it's not that important. You can always do:

vector<params> v2(v1.begin(), v1.end());
or
v2.assign(v1.begin(), v1.end());

2. It is hard to implement pool/shared memory allocation logic since every instance of any STL container will has its own copy of an allocator.

I don't quite understand this. It is quite simple to write a pool
allocator. You can use reference counting semantics if you want the
share a pool, or use a global pool that the the allocator has a
non-counted pointer to.

I am not entirely sure whether the first one should be qualified as a drawback or as a feature. Suppose that instead of the way STL implements allocators currently, custom allocators would be inherited from a common base class and every container would have a pointer to that base class. In this case we could easily assign containers created with different allocators to each other. Hoever, I dont know whether we should consider allocators(or pointers to allocators) part of the container data. That is, if allocators were implemented as pointers to base class, would we copy them when one container is assigned to another? Probably not, since the allocation scheme is something given to container at the initialization time and changing that does not make much sense? If we dont consider allocators part of container data, then it is a drawback that in STL we cannot assign containers to each other if they were templatized with different allocators.

As far as the second item is concerned, if allocators were implemented as pointers to base class, it would be easier to share the complicated allocation schemes (such as pool or shared memory allocation) among containers.
Currently each container gets its own copy of alolocator.

Please i would like to hear you opinion regarding this matter (allocators as template parameters vs. allocators inherited from common base class, pointer to which containers can share).

allocators can't be pointers, so I don't understand your use of
inheritence. Unless you mean reference semantics:

template <class T>
class myallocator
{
//myactualallocator not a template
shared_ptr<myactualallocator> m_actualallocator;
public:
//...

T* allocate(size_type n)
{
return m_actualallocator->allocate(n * sizeof(T));
}

//...
};

Now myactualallocator could of course be an abstract base class. I
don't think that's particularly useful though, although the above
scheme is useful to use a common allocator for all types.

Tom

C++ FAQ: http://www.parashift.com/c++-faq-lite/
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html

 

[OM]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous).

"Copy in blocks?" You mean like memcopy? That is only safe for POD types.

If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.

[snip]

OK, please post the program you used to determine the speed differences you
claim. Or show the code of a std::vector implementation which does not copy
item for item in its assignment operator.

Take a look at your headers. My library's vectors (g++/libstdc++) use
memmove for POD types.

Anyway, the point is that the type of the allocator really is part of
the type of the container. It's not contained by the container; it
doesn't even have to be instantiated. The container can get everything
it needs through the static methods of an allocator class. Would it
make sense to be able to assign a list to a vector? Well, it certainly
could have been part of the standard, but there are good reasons it's
not, all of which come down to the fact that a list and a vector are not
of the same type. Similarly, two containers that were instantiated
from the same template, but with different template arguments, are not
the same type.

Not only the type of the allocator is part of the type of the
container, but also every STL container contains the allocator
INSTANCE, reference to which can be passed into constructor of any STL
container. Take a look at the standard or any STL implementation, and
you will see that allocator IS contained by any container. Not always
can the container get "everything it needs through the static methods
of an allocator class" because allocators are not always stateless.
Therefore, allocators were not implemented as traits with static
methods in STL. Sometimes an allocator should contain state and keep
for example a handle to pool from which memory is allocated. Such an
allocator is supposed to be shared between different instances of the
same container type.

OM

 

[P.J. Plauger]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous).

"Copy in blocks?" You mean like memcopy? That is only safe for POD types.

If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.

[snip]

OK, please post the program you used to determine the speed differences you
claim. Or show the code of a std::vector implementation which does not copy
item for item in its assignment operator.

Take a look at your headers. My library's vectors (g++/libstdc++) use
memmove for POD types.

I suspect it still copies one element at a time.

Anyway, the point is that the type of the allocator really is part of
the type of the container. It's not contained by the container;

Yes it does.

it
doesn't even have to be instantiated.

Yes it does.

The container can get everything
it needs through the static methods of an allocator class.

Template class allocator has no static methods.

Would it
make sense to be able to assign a list to a vector?

On an element by element basis, yes.

Well, it certainly
could have been part of the standard, but there are good reasons it's
not, all of which come down to the fact that a list and a vector are not
of the same type. Similarly, two containers that were instantiated
from the same template, but with different template arguments, are not
the same type.

Now that I agree with.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[P.J. Plauger]

OK, getting back to the original point, if you're using POD data and your
library uses memmove to copy but your allocators are different you can't
take advantage of this optimization. It's not the kind of thing that keeps
me awake at night.

Well, you can to copy an individual element, but probably not a block
of elements.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Jeff Schwab]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous).


"Copy in blocks?" You mean like memcopy? That is only safe for POD types.
If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.


[snip]

OK, please post the program you used to determine the speed differences you
claim. Or show the code of a std::vector implementation which does not copy
item for item in its assignment operator.

Take a look at your headers. My library's vectors (g++/libstdc++) use
memmove for POD types.

Anyway, the point is that the type of the allocator really is part of
the type of the container. It's not contained by the container; it
doesn't even have to be instantiated. The container can get everything
it needs through the static methods of an allocator class. Would it
make sense to be able to assign a list to a vector? Well, it certainly
could have been part of the standard, but there are good reasons it's
not, all of which come down to the fact that a list and a vector are not
of the same type. Similarly, two containers that were instantiated
from the same template, but with different template arguments, are not
the same type.

Not only the type of the allocator is part of the type of the
container, but also every STL container contains the allocator
INSTANCE, reference to which can be passed into constructor of any STL
container. Take a look at the standard or any STL implementation, and
you will see that allocator IS contained by any container. Not always
can the container get "everything it needs through the static methods
of an allocator class" because allocators are not always stateless.
Therefore, allocators were not implemented as traits with static
methods in STL. Sometimes an allocator should contain state and keep
for example a handle to pool from which memory is allocated. Such an
allocator is supposed to be shared between different instances of the
same container type.

OM

Thanks for pointing that out! I misused the word "static." I mean that
the resources of the standard allocators are shared between instances.

For the record, though, my vector implementation does *not* contain the
default allocator as a member. Here's how the vector gets an instance,
when one is needed:

allocator_type
get_allocator() const { return allocator_type(); }

A traits class is used to determine whether the containter
implementations must maintain their allocators as members:

// The fully general version.
template<typename _Tp, typename _Allocator>
struct _Alloc_traits
{
static const bool _S_instanceless = false;
typedef typename _Allocator::template rebind<_Tp>:ther
allocator_type;
};

template<typename _Tp, typename _Allocator>
const bool _Alloc_traits<_Tp, _Allocator>::_S_instanceless;

/// The version for the default allocator.
template<typename _Tp, typename _Tp1>
struct _Alloc_traits<_Tp, allocator<_Tp1> >
{
static const bool _S_instanceless = true;
typedef __simple_alloc<_Tp, __alloc> _Alloc_type;
typedef allocator<_Tp> allocator_type;
};

...

/// Versions for the predefined "SGI" style allocators.

...


-Jeff

 

[Jeff Schwab]

It definately can be otherwise. Since the container known its internals
it can take advantage of that knowledge and for example instead of
copying elements one by one, copy them in blocks (as vector may very
well do since memory occupied by element is contugous).


"Copy in blocks?" You mean like memcopy? That is only safe for POD

types.

If you write a
free function outside of a container, you cannot take advantage of
container internals, and, therefore, all you can do is copy elements one
by one. In any case if try to assign one vector object to another you
will see how much faster it will be, compared to writing you own free
copy function.


[snip]

OK, please post the program you used to determine the speed differences

you

claim. Or show the code of a std::vector implementation which does not

copy

item for item in its assignment operator.

Take a look at your headers. My library's vectors (g++/libstdc++) use
memmove for POD types.

I suspect it still copies one element at a time.

Nope. It uses this:

inline char*
uninitialized_copy(const char* __first,
const char* __last,
char* __result)
{
memmove(__result, __first, __last - __first);
return __result + (__last - __first);
}

Yes it does.

You mean "yes it is?" The answer is that it may or may not be. Please
see my recent reply to OM.

Yes it does.

I stand corrected.

Template class allocator has no static methods.

Do you mean to tell me that static methods are not allowed in
allocators? Why would that be?

On an element by element basis, yes.

Right, the same way that it makes sense to copy vectors of two different
allocator types.

Now that I agree with.

Whew!

 

[P.J. Plauger]

Nope. It uses this:

inline char*
uninitialized_copy(const char* __first,
const char* __last,
char* __result)
{
memmove(__result, __first, __last - __first);
return __result + (__last - __first);
}

Well, yes. That's the specialization for uninitialized_copy
when you know you're copying arrays of char. The real
question is whether vector can determine if it's okay to
use it. I just spent a few minutes staring at stl/_vector.h,
which is the SGI STL code common to libstdc++, STLPort, and
several other libraries. If I read it correctly, then it
does indeed end up performing a single memmove call when
assigning an entire vector. But the chain of logic is not
all that easy to follow. (And unfortunately, the code also
seems to perform this optimization even for a vector with a
user-supplied allocator. That rules out all sorts of smart
allocators once touted as an advantage of having allocators
separate from containers. I suspect the C++ Standard allows
this simplification, but it encourages implementors to do
better. We do, and we still do the single memmove when it's
completely safe to do so.)

You mean "yes it is?" The answer is that it may or may not be. Please
see my recent reply to OM.

Sorry, the answer was far from clear. It is true that the type of
the allocator is part of the type of the container. An
implementation that supports only memoryless allocators (which
is permitted, though not encouraged, as I mentioned above)
can construct an allocator object every time it needs it, and
hence need not store a copy of the allocator within the container
object. Implicit in this simplification is the assumption that
such construction is weightless, or at least cheap, which may
or may not be true even for memoryless allocators.

I stand corrected.


Do you mean to tell me that static methods are not allowed in
allocators? Why would that be?

I didn't say that. What I said was the prototypical allocator,
supplied in the library as template class allocator, has no
static methods. The entire user interface is in terms of calls
on non-static member functions. Hence, you have to create an
allocator object to do all the things that allocators do for
you. You're free to add static functions, but they're not part
of the defined interface. Any container you write that makes
use of them won't conform to the rules for extending STL
containers.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

 

[Gene Wirchenko]

Writing separate function where you will iterate through entire
container to copy its elements one by one, as you suggested is extremely
slow. Try as an example to copy one vector into another using ==

^^
I have seen = used when == was meant, but until now, I had not
seen the reverse.

[snip]

Sincerely,

Gene Wirchenko

 

[Jeff Schwab]

Well, yes. That's the specialization for uninitialized_copy
when you know you're copying arrays of char. The real
question is whether vector can determine if it's okay to
use it. I just spent a few minutes staring at stl/_vector.h,
which is the SGI STL code common to libstdc++, STLPort, and
several other libraries. If I read it correctly, then it
does indeed end up performing a single memmove call when
assigning an entire vector. But the chain of logic is not
all that easy to follow.

Agreed. I am indeed using the SGI implementation, and it sometimes
drives me to curse the notation gods. I've started using the Sun
compiler more and more, just because the headers are so much nicer. Of
course, then not all the implementation code is available for browsing
at all...

(And unfortunately, the code also
seems to perform this optimization even for a vector with a
user-supplied allocator. That rules out all sorts of smart
allocators once touted as an advantage of having allocators
separate from containers. I suspect the C++ Standard allows
this simplification, but it encourages implementors to do
better. We do, and we still do the single memmove when it's
completely safe to do so.)

I've heard vague mentions of this sort of thing... Could you give me an
example of a "smart" allocator that's been ruled out? By "we," you mean
Dinkumware?

Sorry, the answer was far from clear. It is true that the type of
the allocator is part of the type of the container. An
implementation that supports only memoryless allocators (which
is permitted, though not encouraged, as I mentioned above)
can construct an allocator object every time it needs it, and
hence need not store a copy of the allocator within the container
object. Implicit in this simplification is the assumption that
such construction is weightless, or at least cheap, which may
or may not be true even for memoryless allocators.

The STL implementation lets you define an Alloc_traits class to tell
whether it's worth keeping a local (member) instance of the allocator.
The default is to keep the allocator as a member, so I think any
assumption like "construction is cheap" is not implicit, but based on
explicit advice from the implementor of the allocator.

I didn't say that. What I said was the prototypical allocator,
supplied in the library as template class allocator, has no
static methods. The entire user interface is in terms of calls
on non-static member functions. Hence, you have to create an
allocator object to do all the things that allocators do for
you. You're free to add static functions, but they're not part
of the defined interface. Any container you write that makes
use of them won't conform to the rules for extending STL
containers.

Now I see what you mean, and of course you're absolutely right. Thanks
for clarifying!

-Jeff

 

[OM]

Well, you can to copy an individual element, but probably not a block
of elements.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

As i have just found out STLPort implementation of STL as well as STL
from some other vendors implement a copy algorithm in such a way that
they determine whether the type ypu are working with is POD and if it
is so, does memmove. Is not it great? Essentially this gives me the
ability efficiently copy containers of PODs even if they have
different types (created with different allocators).
lexographical_compare also uses memcmp if it finds that data is POD.

OM