By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,002 Members | 1,425 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,002 IT Pros & Developers. It's quick & easy.

allocator requirements

P: n/a
If you specify an allocator in an STL container is it a requirement that
the allocator allocates object of the right type, or can you assume that
the container will rebind the allocator to the correct type?

For example I tried the following code which uses a 'wrong' allocator and
was slightly surrised to find it compiles on the three compilers I tried
it on

#include <vector>
#include <memory>

int main()
{
std::vector<int, std::allocator<double> > vec;
vec.push_back(1);
}

john
Jul 22 '05 #1
Share this Question
Share on Google+
13 Replies


P: n/a
John Harrison wrote:
If you specify an allocator in an STL container is it a requirement
that the allocator allocates object of the right type, or can you
assume that the container will rebind the allocator to the correct type?
It's quite possible that the container uses 'construct' member
function, which accepts the memory of any type (for placement
new) and double* is good enough for int values to be constructed
in. You probably get some excessive memory use that way, but
not any serious problem. Try it in reverse, have a vector of
double and use allocator<char> just for kicks...

As to 'rebind', I can't find any reference to it in the chapter
on containers. Assume you can, rely upon... I wouldn't.

For example I tried the following code which uses a 'wrong' allocator
and was slightly surrised to find it compiles on the three compilers I
tried it on

#include <vector>
#include <memory>

int main()
{
std::vector<int, std::allocator<double> > vec;
vec.push_back(1);
}


V
Jul 22 '05 #2

P: n/a
On Fri, 09 Jul 2004 20:20:34 GMT, Victor Bazarov <v.********@comAcast.net>
wrote:
John Harrison wrote:
If you specify an allocator in an STL container is it a requirement
that the allocator allocates object of the right type, or can you
assume that the container will rebind the allocator to the correct
type?


It's quite possible that the container uses 'construct' member
function, which accepts the memory of any type (for placement
new) and double* is good enough for int values to be constructed
in. You probably get some excessive memory use that way, but
not any serious problem. Try it in reverse, have a vector of
double and use allocator<char> just for kicks...

As to 'rebind', I can't find any reference to it in the chapter
on containers. Assume you can, rely upon... I wouldn't.
For example I tried the following code which uses a 'wrong' allocator
and was slightly surrised to find it compiles on the three compilers I
tried it on
#include <vector>
#include <memory>
int main()
{
std::vector<int, std::allocator<double> > vec;
vec.push_back(1);
}


V


As a corrolary I tried the following

#include <iostream>
#include <vector>
#include <memory>

typedef std::vector<int, std::allocator<double> >::allocator_type X;

void test(std::allocator<double> const&)
{
std::cout << "double\n";
}

void test(std::allocator<int> const&)
{
std::cout << "int\n";
}

int main()
{
test(X());
}

What would you expect the output to be, 'int' or 'double'? Both compilers
I tried it on the output was 'int'. Which means those versions of the STL
are rebinding the allocator to be an int allocator.

john
Jul 22 '05 #3

P: n/a

"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsavy7sdb212331@andronicus...
If you specify an allocator in an STL container is it a requirement that the allocator allocates object of the right type, or can you assume that the container will rebind the allocator to the correct type?


I think this is addressed by 23.1 [lib.container.requirements] para.
8:

Copy constructors for all container types defined in this clause copy
an allocator argument from their
respective first parameters. All other constructors for these
container types take an Allocator& argument
(20.1.5), an allocator whose value type is the same as the container's
value type.

Jonathan
Jul 22 '05 #4

P: n/a
"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsavy7sdb212331@andronicus...
If you specify an allocator in an STL container is it a requirement that
the allocator allocates object of the right type,
Yes, according to the C++ Standard.
or can you assume that
the container will rebind the allocator to the correct type?


Yes, according to widespread practice.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #5

P: n/a
On Fri, 09 Jul 2004 20:47:16 GMT, P.J. Plauger <pj*@dinkumware.com> wrote:
"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsavy7sdb212331@andronicus...
If you specify an allocator in an STL container is it a requirement that
the allocator allocates object of the right type,


Yes, according to the C++ Standard.
or can you assume that
the container will rebind the allocator to the correct type?


Yes, according to widespread practice.

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


Yes it seems so, both implementations of the STL I've checked do rebind
the allocator for vector at least. This seems to directly contradict the
requirements for allocator_type.

I also noticed that Josuttis' book also ignores what the standard says,
see first page of chapter 15 where he happily passes the same allocator to
several containers with different value types.

What's the reason for the standard saying what it does? It seems a bit
inconvenient.

john
Jul 22 '05 #6

P: n/a

"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsav1xfa5212331@andronicus...
On Fri, 09 Jul 2004 20:47:16 GMT, P.J. Plauger <pj*@dinkumware.com> wrote:
"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsavy7sdb212331@andronicus...
If you specify an allocator in an STL container is it a requirement that the allocator allocates object of the right type,
Yes, according to the C++ Standard.
or can you assume that the container will rebind the allocator to the correct type?


Yes, according to widespread practice.

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


Yes it seems so, both implementations of the STL I've checked do

rebind the allocator for vector at least. This seems to directly contradict the requirements for allocator_type.
How does this contradict the allocator requirements?
I also noticed that Josuttis' book also ignores what the standard says, see first page of chapter 15 where he happily passes the same allocator to several containers with different value types.


It looks to me like the allocators he uses all have value_types
appropriate for the containers.

Jonathan
Jul 22 '05 #7

P: n/a
On Fri, 9 Jul 2004 15:21:25 -0600, Jonathan Turkanis
<te******@kangaroologic.com> wrote:

"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsav1xfa5212331@andronicus...
On Fri, 09 Jul 2004 20:47:16 GMT, P.J. Plauger <pj*@dinkumware.com> wrote:
> "John Harrison" <jo*************@hotmail.com> wrote in message
> news:opsavy7sdb212331@andronicus...
>
>> If you specify an allocator in an STL container is it a requirement that >> the allocator allocates object of the right type,
>
> Yes, according to the C++ Standard.
>
>> or can you assume that >> the container will rebind the allocator to the correct type?
>
> Yes, according to widespread practice.
>
> P.J. Plauger
> Dinkumware, Ltd.
> http://www.dinkumware.com
>


Yes it seems so, both implementations of the STL I've checked do

rebind
the allocator for vector at least. This seems to directly contradict

the
requirements for allocator_type.


How does this contradict the allocator requirements?


Not the allocator requirements, the requirements for allocator_type. For
instance 23.2.4 has

template <class T, class Allocator = std::allocator<T> >
class vector
{
...
typedef Allocator allocator_type;

i.e. allocator_type should be the same type as the template parameter.
I also noticed that Josuttis' book also ignores what the standard says,
see first page of chapter 15 where he happily passes the same

allocator to
several containers with different value types.


It looks to me like the allocators he uses all have value_types
appropriate for the containers.


Well maybe I'm reading too much into this but in chpater 15 in quick
succession he gives

vector<int,SpecialAlloc> v;

map<int,float,less<int>,SpecialAlloc> m;

basic_string<char,char_traits<char>,SpecialAlloc> s;

Its not specified anywhere what SpecialAlloc is but by the quote you made
from the standard it cannot have the correct value type for all these
different containers.

john
Jonathan


Jul 22 '05 #8

P: n/a

"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsav3hke1212331@andronicus...
On Fri, 9 Jul 2004 15:21:25 -0600, Jonathan Turkanis
<te******@kangaroologic.com> wrote:

"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsav1xfa5212331@andronicus...

Yes it seems so, both implementations of the STL I've checked do rebind
the allocator for vector at least. This seems to directly
contradict the
requirements for allocator_type.


How does this contradict the allocator requirements?


Not the allocator requirements,


Sorry, I read your post too fast.
the requirements for allocator_type. For
instance 23.2.4 has

template <class T, class Allocator = std::allocator<T> >
class vector
{
...
typedef Allocator allocator_type;

i.e. allocator_type should be the same type as the template

parameter.

I still don't see the violation.
I also noticed that Josuttis' book also ignores what the standard

says,
see first page of chapter 15 where he happily passes the same

allocator to
several containers with different value types.


It looks to me like the allocators he uses all have value_types
appropriate for the containers.


Well maybe I'm reading too much into this but in chpater 15 in quick
succession he gives

vector<int,SpecialAlloc> v;

map<int,float,less<int>,SpecialAlloc> m;

basic_string<char,char_traits<char>,SpecialAlloc> s;


That's funny. My copy has

vector<int, MyAlloc<int> > v;
map<int,float,less<int>,MyAlloc<std::pair<const int, float> > > m;
...

Jonathan
Jul 22 '05 #9

P: n/a
"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsav1xfa5212331@andronicus...
On Fri, 09 Jul 2004 20:47:16 GMT, P.J. Plauger <pj*@dinkumware.com> wrote:
"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsavy7sdb212331@andronicus...
If you specify an allocator in an STL container is it a requirement that the allocator allocates object of the right type,
Yes, according to the C++ Standard.
or can you assume that
the container will rebind the allocator to the correct type?


Yes, according to widespread practice.

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


Yes it seems so, both implementations of the STL I've checked do rebind
the allocator for vector at least. This seems to directly contradict the
requirements for allocator_type.


I think this approach gives meaning to an otherwise ill formed program,
hence it's a conforming implementation.
I also noticed that Josuttis' book also ignores what the standard says,
see first page of chapter 15 where he happily passes the same allocator to
several containers with different value types.

What's the reason for the standard saying what it does? It seems a bit
inconvenient.


It was simple, and the rebind mechanism was introduced as a cutesy
trick before template template was well established in the language.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
Jul 22 '05 #10

P: n/a
Jonathan Turkanis wrote:
"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsav3hke1212331@andronicus...
On Fri, 9 Jul 2004 15:21:25 -0600, Jonathan Turkanis
<te******@kangaroologic.com> wrote:

"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsav1xfa5212331@andronicus... [...]I also noticed that Josuttis' book also ignores what the standard

says,

see first page of chapter 15 where he happily passes the same

allocator to

several containers with different value types.

It looks to me like the allocators he uses all have value_types
appropriate for the containers.


Well maybe I'm reading too much into this but in chpater 15 in quick
succession he gives

vector<int,SpecialAlloc> v;

map<int,float,less<int>,SpecialAlloc> m;

basic_string<char,char_traits<char>,SpecialAlloc > s;

That's funny. My copy has

vector<int, MyAlloc<int> > v;
map<int,float,less<int>,MyAlloc<std::pair<const int, float> > > m;
...


<Butting in...>

So does mine, but it's the 7th printing (what's yours?) so, either
before they printed something differently or after...

V
Jul 22 '05 #11

P: n/a

"Victor Bazarov" <v.********@comAcast.net> wrote in message
news:uv*****************@ord-read.news.verio.net...
Jonathan Turkanis wrote:
"John Harrison" <jo*************@hotmail.com> wrote in message
news:opsav3hke1212331@andronicus...
Well maybe I'm reading too much into this but in chpater 15 in quicksuccession he gives

vector<int,SpecialAlloc> v;

map<int,float,less<int>,SpecialAlloc> m;

basic_string<char,char_traits<char>,SpecialAlloc > s;

That's funny. My copy has

vector<int, MyAlloc<int> > v;
map<int,float,less<int>,MyAlloc<std::pair<const int, float> > > m; ...


<Butting in...>

So does mine, but it's the 7th printing (what's yours?) so, either
before they printed something differently or after...


Mine is the 10th. I wonder if Josuttis changed it because he decided
it was an error or because he thought it was debatable or an
unnecessary distraction.

I'm a bit suprised that the requirement that the value_type's match is
stated clearly for basic_string (21.3/1) but only in an almost
parenthetical way for containers generally (23.1/8), AFAICT.

Jonathan
Jul 22 '05 #12

P: n/a
>>
Yes it seems so, both implementations of the STL I've checked do rebind
the allocator for vector at least. This seems to directly contradict the
requirements for allocator_type.


I think this approach gives meaning to an otherwise ill formed program,
hence it's a conforming implementation.


Yes, thinking about it I agree.

john
Jul 22 '05 #13

P: n/a
On Fri, 9 Jul 2004 16:13:19 -0600, Jonathan Turkanis
<te******@kangaroologic.com> wrote:

Mine is the 10th. I wonder if Josuttis changed it because he decided
it was an error or because he thought it was debatable or an
unnecessary distraction.


Mine's the third, the change is listed in the errata on his website.

john
Jul 22 '05 #14

This discussion thread is closed

Replies have been disabled for this discussion.