VS 2005 should allows this, why?

[Lighter]

#include <set>

using namespace std;

int main()
{

typedef set<int> INTSET;

INTSET coll;

INTSET::iterator pos = coll.begin();

*pos = 9; // VS 2005 should allowes this, why?

}

the set will contain two same values, it violates the rule that a set
at most contains one of each key value.

 

[Ian Collins]

#include <set>

using namespace std;

int main()
{

typedef set<int> INTSET;

All caps is usually used form macros.

INTSET coll;

INTSET::iterator pos = coll.begin();

*pos = 9; // VS 2005 should allowes this, why?

Why should it and why VS 2005 in particular?

 

[Ron Natalie]

#include <set>

using namespace std;

int main()
{

typedef set<int> INTSET;

INTSET coll;

INTSET::iterator pos = coll.begin();

*pos = 9; // VS 2005 should allowes this, why?

No C++ compiler will allow this.

At the point of the above statement pos has the value
of coll.end(). You can't dereference it.

I think you have the concept of iterators and inserters
confused.

 

[red floyd]

#include <set>

using namespace std;

int main()
{

typedef set<int> INTSET;

INTSET coll;

INTSET::iterator pos = coll.begin();

*pos = 9; // VS 2005 should allowes this, why?

At this point, you have undefined behavior, and ANYTHING can happen.

 

[Lighter]

red floyd wrote:

At this point, you have undefined behavior, and ANYTHING can happen.
=============

I'm sorry for my careless. I made a typying mistake. The actual code
fragment is as follows:

#include <set>

using namespace std;


int main()
{

typedef set<int> INTSET;

INTSET coll;

coll.insert(9); // This line was omitted before

INTSET::iterator pos = coll.begin();


*pos = 9; // VS 2005 should allowes this, why?

}

 

[Ian Collins]

red floyd wrote:

At this point, you have undefined behavior, and ANYTHING can happen.
=============

I'm sorry for my careless. I made a typying mistake. The actual code
fragment is as follows:

That's why you should always copy and paste, not retype.

#include <set>

using namespace std;


int main()
{

typedef set<int> INTSET;

INTSET coll;

coll.insert(9); // This line was omitted before

INTSET::iterator pos = coll.begin();


*pos = 9; // VS 2005 should allowes this, why?

Again, I ask why VS 2005 and why should it allow it?

 

[Bo Persson]

That's why you should always copy and paste, not retype.

Again, I ask why VS 2005 and why should it allow it?

I think the OP might be referring to this defect report for C++

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103

which asks if you are allowed to change the value of the map elements.

The original standard is obviously a bit unclear on this, which
explains why implementations behave inconsistently.


So, my attempt to answer the question is:

It might (right now) be ok to do *pos=9, if pos is a valid iterator,
and assigning the value 9 doesn't change the order of the elements in
the set.

It seems like the next revision of the standard will contain the
sentence "Keys in an associative container are immutable.", which will
change the rule.


Bo Persson

 

[Ian Collins]

I think the OP might be referring to this defect report for C++

http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#103

which asks if you are allowed to change the value of the map elements.

The original standard is obviously a bit unclear on this, which
explains why implementations behave inconsistently.


So, my attempt to answer the question is:

It might (right now) be ok to do *pos=9, if pos is a valid iterator,
and assigning the value 9 doesn't change the order of the elements in
the set.

It seems like the next revision of the standard will contain the
sentence "Keys in an associative container are immutable.", which will
change the rule.

That makes sense. Both the compilers I use enforce this.

 

[Lighter]

I think, as a solution, the c++ standard should cancel the interface
iterator of set intead of the only interface const_iterator that users
can get under any circumstance.

for exmaple, the following code should not be allowed:

set<int>::iterator pos; // error, set doesn't provide a type/interface
named iterator

in contrast, the following is allowed

set<int>::const_iterator pos; // This should be the only way to declare
a iterator of set

 

[Richard Herring]

I think, as a solution, the c++ standard should cancel the interface
iterator of set intead of the only interface const_iterator that users
can get under any circumstance.

for exmaple, the following code should not be allowed:

set<int>::iterator pos; // error, set doesn't provide a type/interface
named iterator

in contrast, the following is allowed

set<int>::const_iterator pos; // This should be the only way to declare
a iterator of set

If you did that, you'd have to remove the overloads of erase() that take
iterators. Not such a good idea.

 

[Vikram]

Interestingly I just read Item 22 in "Effective STL" by Scott Meyers
which deals with this issue. In short, iterators are needed to change
the "non-key" parts of a set element. In your case, the element is just
an int so it is not relevant.