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

[mathias.hasselmann@gmx.de]

>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: