Re: libstdc++/5583: std::set::iterator is readonly

Re: libstdc++/5583: std::set::iterator is readonly

[pme]

Synopsis: std::set::iterator is readonly

State-Changed-From-To: feedback->closed
State-Changed-By: pme
State-Changed-When: Mon Mar 11 14:12:28 2002
State-Changed-Why:
    LWG Defect Report #103 has resulted in a change to the C++
    Standard:  std::set::iterator is /required/ to be read-only.
    So, this is now definitely not a bug.  :-)
    
    Your example of directed edges doesn't really work:  you
    didn't specify how "edge_t" is supposed to be ordered, but
    assuming that you define an operator< which examines the
    'weight' member, then you /still/ can't change the weight,
    because that would be changing the ordering!  It's right
    back to the original problem...
    

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5583

Re: libstdc++/5583: std::set::iterator is readonly

[Mathias Hasselmann]

The following reply was made to PR libstdc++/5583; it has been noted by GNATS.

From: Mathias Hasselmann <mathias.hasselmann@gmx.de>
To: Carlo Wood <carlo@alinoe.com>
Cc: "rodrigc@gcc.gnu.org" <rodrigc@gcc.gnu.org>, 
    "gcc-bugs@gcc.gnu.org" <gcc-bugs@gcc.gnu.org>, 
    "gcc-prs@gcc.gnu.org" <gcc-prs@gcc.gnu.org>, 
    "nobody@gcc.gnu.org" <nobody@gcc.gnu.org>, 
    "gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>
Subject: Re: libstdc++/5583: std::set::iterator is readonly
Date: Wed, 6 Feb 2002 00:29:00 +0100 (CET)

 On Tue, 5 Feb 2002, Carlo Wood wrote:
 
 > On Tue, Feb 05, 2002 at 02:56:09PM -0000, rodrigc@gcc.gnu.org wrote:
 > > Synopsis: std::set::iterator is readonly
 > > 
 > > State-Changed-From-To: open->feedback
 > > State-Changed-By: rodrigc
 > > State-Changed-When: Tue Feb  5 06:56:09 2002
 > > State-Changed-Why:
 > >     Your testcase in the "How-to-Repeat" section is
 > >     incorrect and doesn't even compile.
 > >     Can you submit a full testcase (including #include statements)
 > >     which illustrates your problem?
 > > 
 > > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5583
 > 
 > I didn't look at the PR, but from the Subject I bet that
 > he means that (*iter) returns a constant object, even
 > for set<Non-Const-Type>::iterator.
 > 
 > If so, then this is not a bug: the elements of set<> have to be
 > constant, you are not allowed to change them because that would
 > change the ordering in the set<>.
 
 
 Agreed: There are situations in which changing attributes of an element
 would change the ordering in the set. Looks like my acknowledgement of
 this situation was not clear enough in the report.
 
 BUT: Condisider the situation where I want to use std::set to store a set
 of edges of an directed weighted graph. Edges of a directed graph are
 triples of the kind (u,v,w) where u and v refer to vertices of the graph
 and w describes the weight of the edge. Obviously edges of a directed
 weighted exclusively are distinguished by their vertices. Obviously it
 would be nonsense to allow edgessets like {(1,2,3),(1,2,3)} or
 {(1,2,3),(1,2,inf)}. I hope you agree so far.
 
 Now since we have our nice set of edges:
 
 
 	struct edge_t 
 	{ 
 		vertex_t * u, * v;
 		double weight;
 
 		void set_weight(double new_weight) 
 		{
 			weight = new_weight;
 		}
 	};
 
 	typedef std::set<edge_t> set_of_edges_t;
 
 
 we want to use this ADT to implement for instance Dijkstra's Shortest Path
 Algorithm. At the very beginning of Dijkstra's Algorithm (in the form I
 know it) we have to initialize all edges of the graph to have an infinite 
 weight. In my opinion a good way to achieve this would be to write:
 
 
 	set_of_edges_t edges;
 	std::for_each(edges.begin(), edges.end(),
 	std::bind2nd(std::mem_fun_ref(&edge_t::set_weight, INFINITY));
 
 
 Unfortunatly this simple piece of code fails to compile when
 std::set::iterator is a read-only iterator.
 
 Well, it would be possible to hack arround the problem by changing the
 definition of edge_t:
 
 
                 struct edge_t
                 {
                         vertex_t * u, * v;
                         mutable double weight; // <- made it mutable
   
                         void set_weight(double new_weight) const // <- const now
                         {
                                 weight = new_weight;
                         }
                 };
 
 But somehow I don't feel well when doing it that way: It's set_weight's
 purpose to modify edges contra caricatures the entire idea of the "const"
 keyword... In this situation both "const" qualifiers (the one of the
 iterator and the one of set_weight) are used in an absurd manner.
 
 
 Ciao,
 Mathias
 -- 
 WWW:           http://www.informatik.hu-berlin.de/~hasselma/
 PGP/GnuPG:     1024-Bit DSA: ID 55E572F3, 1024-Bit RSA: ID EAAF7CF1
 

Re: libstdc++/5583: std::set::iterator is readonly

[Carlo Wood]

The following reply was made to PR libstdc++/5583; it has been noted by GNATS.

From: Carlo Wood <carlo@alinoe.com>
To: rodrigc@gcc.gnu.org, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org,
  mathias.hasselmann@gmx.de, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: libstdc++/5583: std::set::iterator is readonly
Date: Tue, 5 Feb 2002 16:18:40 +0100

 On Tue, Feb 05, 2002 at 02:56:09PM -0000, rodrigc@gcc.gnu.org wrote:
 > Synopsis: std::set::iterator is readonly
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: rodrigc
 > State-Changed-When: Tue Feb  5 06:56:09 2002
 > State-Changed-Why:
 >     Your testcase in the "How-to-Repeat" section is
 >     incorrect and doesn't even compile.
 >     Can you submit a full testcase (including #include statements)
 >     which illustrates your problem?
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5583
 
 I didn't look at the PR, but from the Subject I bet that
 he means that (*iter) returns a constant object, even
 for set<Non-Const-Type>::iterator.
 
 If so, then this is not a bug: the elements of set<> have to be
 constant, you are not allowed to change them because that would
 change the ordering in the set<>.
 
 -- 
 Carlo Wood <carlo@alinoe.com>

Re: libstdc++/5583: std::set::iterator is readonly

[rodrigc]

Synopsis: std::set::iterator is readonly

State-Changed-From-To: open->feedback
State-Changed-By: rodrigc
State-Changed-When: Tue Feb  5 06:56:09 2002
State-Changed-Why:
    Your testcase in the "How-to-Repeat" section is
    incorrect and doesn't even compile.
    Can you submit a full testcase (including #include statements)
    which illustrates your problem?

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=5583

libstdc++/5583: std::set::iterator is readonly

[mathias.hasselmann]

>Number:         5583
>Category:       libstdc++
>Synopsis:       std::set::iterator is readonly
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 04 11:06:04 PST 2002
>Closed-Date:
>Last-Modified:
>Originator:     mathias.hasselmann@gmx.de
>Release:        3.0.2 (and 2.95.3)
>Organization:
>Environment:
System: Linux dali.sqx.lde 2.4.9-mosix #17 SMP Sam Sep 1 03:04:51 CEST 2001 i686 unknown
Architecture: i686

        <machine, os, target, libraries (multiple lines)>
host: i686-pc-linux-gnu
build: i686-pc-linux-gnu
target: i686-pc-linux-gnu
configured with: /nfs/sam/opt/glibc/gcc-3.0.2/configure --prefix=/usr
>Description:
since std::set::iterator is declared as const_iterator it's impossible to write code like that:

std::set<obj_t> myset;
std::fill(myset.begin(), myset.end(), 42);

or

std::for_each(myset.begin(), myset.end(), obj_t::reset);

Yes, protecting members of set protects the set from getting corrupted. _But_ if you ensure that your modification of elements of sets does _not_ change the element order (simply 'cause the element's compare operations don't consider the modification you are going to do) you really should be able to modify elements stored in a set...
>How-To-Repeat:
struct foo
{ 
    void reset() { a = 0; };
    bool operator<(const foo & other) const { return b < other.b; }

    int a, b;
};

std::set<foo> myset;
std::for_each(myset.begin(), myset.end(), std::mem_fun_ref(&foo::reset);
>Fix:
Heavy ugly casting to overcome const qualifiers.
>Release-Note:
>Audit-Trail:
>Unformatted: