plain iterator to vector<const int>

[t]

Can you use a plain iterator to vector<const int> to write to it? It
doesn't seem like it should be possible, but Visual C++ 2005 Express
lets me:

vector<const int> vc;
vc.push_back(5);
vector<const int>::iterator iter = vc.begin();
*iter = 3; // compiles

 

[Ian Collins]

Can you use a plain iterator to vector<const int> to write to it? It
doesn't seem like it should be possible, but Visual C++ 2005 Express
lets me:

vector<const int> vc;
vc.push_back(5);
vector<const int>::iterator iter = vc.begin();
*iter = 3; // compiles

Looks like a compiler bug.

Try it with gcc and you will get more errors than I've ever seen for one
line before!

 

[Barry]

Can you use a plain iterator to vector<const int> to write to it? It
doesn't seem like it should be possible, but Visual C++ 2005 Express
lets me:

vector<const int> vc;
vc.push_back(5);
vector<const int>::iterator iter = vc.begin();
*iter = 3; // compiles

Well,
element type used in standard container should be Assignable

/const int/ is not a model of Assignable.

Now, concept check is still not part of standard.
So this is not a bug.

 

[Ian Collins]

Well,
element type used in standard container should be Assignable

/const int/ is not a model of Assignable.

Now, concept check is still not part of standard.
So this is not a bug.

I thought the first bug was accepting the the push_back.

 

[Barry]

I thought the first bug was accepting the the push_back.

I posted before I saw your post.

[code:
std::cout
<< typeid(std::vector<const int>::value_type).name()
<< std::endl;

std::cout
<< typeid(std::allocator<const int>::value_type).name()
<< std::endl;
--End-code]

MSVC8 produces:
int
int

that's why the code compiles.

[std:
20.4.1 The default allocator [lib.default.allocator]

template <class T> class allocator {
public:
....
typedef T value_type;
-- End-std]

So, actually allocator has a bug.

 

[Markus Moll]

Hi

[code:
std::cout
<< typeid(std::vector<const int>::value_type).name()
<< std::endl;

std::cout
<< typeid(std::allocator<const int>::value_type).name()
<< std::endl;
--End-code]

MSVC8 produces:
int
int

that's why the code compiles.

No. However, I'm not sure if the code may compile...

[std:
20.4.1 The default allocator [lib.default.allocator]

template <class T> class allocator {
public:
...
typedef T value_type;
-- End-std]

So, actually allocator has a bug.

No.

5.2.8 [Type identification]
(5) The top-level cv-qualifiers of the lvalue expression or the type-id that
is the operand of typeid are always ignored.

It actually also gives examples like "typeid(D) == typeid(const D); //
yields true"

The error in the original code is indeed instantiating std::vector<> with
const int, which doesn't meet the "Assignable" requirement.

Markus

 

[Barry]

Hi

[code:
std::cout
<< typeid(std::vector<const int>::value_type).name()
<< std::endl;

std::cout
<< typeid(std::allocator<const int>::value_type).name()
<< std::endl;
--End-code]

MSVC8 produces:
int
int

that's why the code compiles.

No. However, I'm not sure if the code may compile...

[std:
20.4.1 The default allocator [lib.default.allocator]

template <class T> class allocator {
public:
...
typedef T value_type;
-- End-std]

So, actually allocator has a bug.

No.

5.2.8 [Type identification]
(5) The top-level cv-qualifiers of the lvalue expression or the type-id that
is the operand of typeid are always ignored.

It actually also gives examples like "typeid(D) == typeid(const D); //
yields true"

Thank you. I didn't know about this.

Well, but MSVC8 really removes the constness using type traits. Don't
know what's the purpose.

[std:
20.4.1 The default allocator [lib.default.allocator]

template <class T> class allocator {
public:
typedef size_t size_type;
typedef ptrdiff_t difference_type;
typedef T* pointer;
typedef const T* const_pointer;
typedef T& reference;
typedef const T& const_reference;
typedef T value_type;
-- End-std]

The standard does NOT constrain that T for allocator should be Assignable.
But if T is "const int", then
const_reference == reference

pointer address(reference x) const;
const_pointer address(const_reference x) const;
can't be overloaded.

 

[James Kanze]

Can you use a plain iterator to vector<const int> to write to it?

You can't have a vector of const int. There is no such thing,
and attempting to declare it is undefined behavior; it may fail
to compile, it may fail to compiler only if certain specific
functions are used, or it may do just about anything else.

(With g++, it fails to compile, and I believe that this will be
required in the next version of the standard.)

 

[James Kanze]

[std:
20.4.1 The default allocator [lib.default.allocator]
template <class T> class allocator {
public:
...
typedef T value_type;
-- End-std]
So, actually allocator has a bug.

No.

Sort of. The allocator requirements in the standard have (or
had) a bug. The general requirements (which apply to any
allocator you write as well) specify behavior over T and U,
where T and U are specified as "any type". In practice, of
course, if T and U have reference type, the allocator cannot be
made to work, and if they have const type, the allocator cannot
be made useful. The latest draft of the standard corrects this;
the requirements for an allocator (default or other) are only
defined for non-const, non-reference types.

5.2.8 [Type identification]
(5) The top-level cv-qualifiers of the lvalue expression or the type-id that
is the operand of typeid are always ignored.
It actually also gives examples like "typeid(D) == typeid(const D); //
yields true"

Thank you. I didn't know about this.

Well, but MSVC8 really removes the constness using type
traits. Don't know what's the purpose.

Dinkumware was probably trying to do something useful in face of
ambiguities and problems in the standard.

This has been (somewhat) cleaned up in the current draft, but
I'm still not too sure about one thing: the current draft has
been modified to remove the Assignable requirement for
std::list. Presumably, an std::list< int const > will be legal.
But the requirements for allocators are not specified for const
types, and std::list uses an allocator. (I should probably
raise the question in comp.std.c++.)

[std:
20.4.1 The default allocator [lib.default.allocator]

template <class T> class allocator {
public:
typedef size_t size_type;
typedef ptrdiff_t difference_type;
typedef T* pointer;
typedef const T* const_pointer;
typedef T& reference;
typedef const T& const_reference;
typedef T value_type;
-- End-std]

The standard does NOT constrain that T for allocator should be Assignable.

The current standard doesn't constrain that T not be a
reference, either, although that would make reference_type a
reference to a reference (which doesn't exist).

 

[Barry]

aise the question in comp.std.c++.)

[std:
20.4.1 The default allocator [lib.default.allocator]

template <class T> class allocator {
public:
typedef size_t size_type;
typedef ptrdiff_t difference_type;
typedef T* pointer;
typedef const T* const_pointer;
typedef T& reference;
typedef const T& const_reference;
typedef T value_type;
-- End-std]

The standard does NOT constrain that T for allocator should be Assignable.

The current standard doesn't constrain that T not be a
reference, either, although that would make reference_type a
reference to a reference (which doesn't exist).

Yah, I think reference does not escape "NOT Assignable" category.

Well, still take /const int/ and /allocator/ into account.
If T is "const int", then
const_reference == reference

pointer address(reference x) const;
const_pointer address(const_reference x) const;
can't be overloaded.

So if STL implementation does NOT remove constness on T, then the code
shouldn't compile at all.