Question about C++ Allocatars

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

Re: Question about C++ Allocatars

"regisser" <omoroz01@hotma il.com> wrote in message
news:X_NFb.1047 6$_1.3114@fe03. private.usenets erver.com...[color=blue]
> I have a quastion for the C++ professionals and members of the C++[/color]
standartization commetee.

I'm not a member of the standards committee but I suppose I am a C++
professional.
[color=blue]
>
> As i know C++ standart requires an allocator to be a templated parameter[/color]
in every STL container.[color=blue]
> Besides that one can pass reference to allocatior into every STL[/color]
container. This raises the following questions:[color=blue]
> 1. Containers that were templatized with different allocators are[/color]
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.
[color=blue]
> 2. It is hard to implement pool/shared memory allocation logic since every[/color]
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

http://home.rochester.rr.com/cyhome/

[OM]

Re: Question about C++ Allocatars

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

Cy Edmunds wrote:[color=blue]
> "regisser" <omoroz01@hotma il.com> wrote in message
> news:X_NFb.1047 6$_1.3114@fe03. private.usenets erver.com...
>[color=green]
>>I have a quastion for the C++ professionals and members of the C++[/color]
>
> standartization commetee.
>
> I'm not a member of the standards committee but I suppose I am a C++
> professional.
>
>[color=green]
>>As i know C++ standart requires an allocator to be a templated parameter[/color]
>
> in every STL container.
>[color=green]
>>Besides that one can pass reference to allocatior into every STL[/color]
>
> container. This raises the following questions:
>[color=green]
>>1. Containers that were templatized with different allocators are[/color]
>
> 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.
>
>[color=green]
>>2. It is hard to implement pool/shared memory allocation logic since every[/color]
>
> 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]
>
>[/color]

[OM]

Re: Question about C++ Allocatars

error: using operator =

OM wrote:
[color=blue]
> 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
>
> Cy Edmunds wrote:
>[color=green]
>> "regisser" <omoroz01@hotma il.com> wrote in message
>> news:X_NFb.1047 6$_1.3114@fe03. private.usenets erver.com...
>>[color=darkred]
>>> I have a quastion for the C++ professionals and members of the C++[/color]
>>
>>
>> standartization commetee.
>>
>> I'm not a member of the standards committee but I suppose I am a C++
>> professional.
>>
>>[color=darkred]
>>> As i know C++ standart requires an allocator to be a templated parameter[/color]
>>
>>
>> in every STL container.
>>[color=darkred]
>>> Besides that one can pass reference to allocatior into every STL[/color]
>>
>>
>> container. This raises the following questions:
>>[color=darkred]
>>> 1. Containers that were templatized with different allocators are[/color]
>>
>>
>> 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.
>>
>>[color=darkred]
>>> 2. It is hard to implement pool/shared memory allocation logic since
>>> every[/color]
>>
>>
>> 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]
>>
>>[/color]
>
>[/color]

[Cy Edmunds]

Re: Question about C++ Allocatars

"OM" <omoroz01@hotma il.com> wrote in message
news:fROFb.3783 $8a.2511@fe14.p rivate.usenetse rver.com...[color=blue]
> 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.[/color]

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.

--
Cy

http://home.rochester.rr.com/cyhome/

[snip]

[OM]

Re: Question about C++ Allocatars

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

Cy Edmunds wrote:
[color=blue]
> "OM" <omoroz01@hotma il.com> wrote in message
> news:fROFb.3783 $8a.2511@fe14.p rivate.usenetse rver.com...
>[color=green]
>>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.[/color]
>
>
> 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.
>[/color]

[Cy Edmunds]

Re: Question about C++ Allocatars

"OM" <omoroz01@hotma il.com> wrote in message
news:6aQFb.5253 $If.2820@fe09.p rivate.usenetse rver.com...[color=blue]
> 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).[/color]

"Copy in blocks?" You mean like memcopy? That is only safe for POD types.
[color=blue]
> 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.
>[/color]
[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.

--
Cy

http://home.rochester.rr.com/cyhome/

[Jeff Schwab]

Re: Question about C++ Allocatars

Cy Edmunds wrote:[color=blue]
> "OM" <omoroz01@hotma il.com> wrote in message
> news:6aQFb.5253 $If.2820@fe09.p rivate.usenetse rver.com...
>[color=green]
>>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).[/color]
>
>
> "Copy in blocks?" You mean like memcopy? That is only safe for POD types.
>[color=green]
>>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.
>>[/color]
>
> [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.
>[/color]

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]

Re: Question about C++ Allocatars

"Jeff Schwab" <jeffplus@comca st.net> wrote in message
news:dZOdnVx8sM rDdHqi4p2dnA@co mcast.com...[color=blue]
> Cy Edmunds wrote:[color=green]
> > "OM" <omoroz01@hotma il.com> wrote in message
> > news:6aQFb.5253 $If.2820@fe09.p rivate.usenetse rver.com...
> >[color=darkred]
> >>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).[/color]
> >
> >
> > "Copy in blocks?" You mean like memcopy? That is only safe for POD[/color][/color]
types.[color=blue][color=green]
> >[color=darkred]
> >>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.
> >>[/color]
> >
> > [snip]
> >
> > OK, please post the program you used to determine the speed differences[/color][/color]
you[color=blue][color=green]
> > claim. Or show the code of a std::vector implementation which does not[/color][/color]
copy[color=blue][color=green]
> > item for item in its assignment operator.
> >[/color]
>
> Take a look at your headers. My library's vectors (g++/libstdc++) use
> memmove for POD types.[/color]

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.
[color=blue]
>
> 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.
>[/color]

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.

--
Cy

http://home.rochester.rr.com/cyhome/

[Jeff Schwab]

Re: Question about C++ Allocatars

Cy Edmunds wrote:[color=blue]
> "Jeff Schwab" <jeffplus@comca st.net> wrote in message
> news:dZOdnVx8sM rDdHqi4p2dnA@co mcast.com...
>[color=green]
>>Cy Edmunds wrote:
>>[color=darkred]
>>>"OM" <omoroz01@hotma il.com> wrote in message
>>>news:6aQFb.5 253$If.2820@fe0 9.private.usene tserver.com...
>>>
>>>
>>>>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[/color][/color]
>
> types.
>[color=green][color=darkred]
>> >[/color]
>>[color=darkred]
>>>>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[/color][/color]
>
> you
>[color=green][color=darkred]
>>>claim. Or show the code of a std::vector implementation which does not[/color][/color]
>
> copy
>[color=green][color=darkred]
>>>item for item in its assignment operator.
>>>[/color]
>>
>>Take a look at your headers. My library's vectors (g++/libstdc++) use
>>memmove for POD types.[/color]
>
>
> 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.[/color]

Nor should it. Assignment of vectors of non-POD elements wasn't
disallowed just because memmove couldn't be used. :)
[color=blue][color=green]
>>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.
>>[/color]
>
>
> 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.[/color]

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_inser ter( 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]

Re: Question about C++ Allocatars

On Mon, 22 Dec 2003 21:36:17 -0800, "regisser" <omoroz01@hotma il.com>
wrote:
[color=blue]
>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?[/color]

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

vector<params> v2(v1.begin(), v1.end());
or
v2.assign(v1.be gin(), v1.end());
[color=blue]
>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.[/color]

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.
[color=blue]
>
>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).[/color]

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

template <class T>
class myallocator
{
//myactualallocat or not a template
shared_ptr<myac tualallocator> m_actualallocat or;
public:
//...

T* allocate(size_t ype n)
{
return m_actualallocat or->allocate(n * sizeof(T));
}

//...
};

Now myactualallocat or 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]

Re: Question about C++ Allocators

Jeff Schwab <jeffplus@comca st.net> wrote in message news:<dZOdnVx8s MrDdHqi4p2dnA@c omcast.com>...[color=blue]
> Cy Edmunds wrote:[color=green]
> > "OM" <omoroz01@hotma il.com> wrote in message
> > news:6aQFb.5253 $If.2820@fe09.p rivate.usenetse rver.com...
> >[color=darkred]
> >>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).[/color]
> >
> >
> > "Copy in blocks?" You mean like memcopy? That is only safe for POD types.
> >[color=darkred]
> >>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.
> >>[/color]
> >
> > [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.
> >[/color]
>
> 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.[/color]

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]

Re: Question about C++ Allocatars

"Jeff Schwab" <jeffplus@comca st.net> wrote in message
news:dZOdnVx8sM rDdHqi4p2dnA@co mcast.com...
[color=blue]
> Cy Edmunds wrote:[color=green]
> > "OM" <omoroz01@hotma il.com> wrote in message
> > news:6aQFb.5253 $If.2820@fe09.p rivate.usenetse rver.com...
> >[color=darkred]
> >>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).[/color]
> >
> >
> > "Copy in blocks?" You mean like memcopy? That is only safe for POD[/color][/color]
types.[color=blue][color=green]
> >[color=darkred]
> >>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.
> >>[/color]
> >
> > [snip]
> >
> > OK, please post the program you used to determine the speed differences[/color][/color]
you[color=blue][color=green]
> > claim. Or show the code of a std::vector implementation which does not[/color][/color]
copy[color=blue][color=green]
> > item for item in its assignment operator.
> >[/color]
>
> Take a look at your headers. My library's vectors (g++/libstdc++) use
> memmove for POD types.[/color]

I suspect it still copies one element at a time.
[color=blue]
> 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;[/color]

Yes it does.
[color=blue]
> it
> doesn't even have to be instantiated.[/color]

Yes it does.
[color=blue]
> The container can get everything
> it needs through the static methods of an allocator class.[/color]

Template class allocator has no static methods.
[color=blue]
> Would it
> make sense to be able to assign a list to a vector?[/color]

On an element by element basis, yes.
[color=blue]
> 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.[/color]

Now that I agree with.

P.J. Plauger
Dinkumware, Ltd.

http://www.dinkumware.com

[P.J. Plauger]

Re: Question about C++ Allocatars

"Cy Edmunds" <cedmunds@spaml ess.rochester.r r.com> wrote in message
news:xrSFb.5006 4$JW3.457@twist er.nyroc.rr.com ...
[color=blue]
> 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.[/color]

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]

Re: Question about C++ Allocators

OM wrote:[color=blue]
> Jeff Schwab <jeffplus@comca st.net> wrote in message news:<dZOdnVx8s MrDdHqi4p2dnA@c omcast.com>...
>[color=green]
>>Cy Edmunds wrote:
>>[color=darkred]
>>>"OM" <omoroz01@hotma il.com> wrote in message
>>>news:6aQFb.5 253$If.2820@fe0 9.private.usene tserver.com...
>>>
>>>
>>>>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.[/color]
>>[color=darkred]
>> >[/color]
>>[color=darkred]
>>>>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.
>>>[/color]
>>
>>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.[/color]
>
>
> 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[/color]

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<typena me _Tp, typename _Allocator>
struct _Alloc_traits
{
static const bool _S_instanceless = false;
typedef typename _Allocator::tem plate rebind<_Tp>::ot her
allocator_type;
};

template<typena me _Tp, typename _Allocator>
const bool _Alloc_traits<_ Tp, _Allocator>::_S _instanceless;

/// The version for the default allocator.
template<typena me _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