Whats the standard here and why?

[sid debgupta]

I am attaching this simple code snippet which compiles fine with MS C++ compiler v15 ( which comes with Visual C++ 8 ) but fails with MS C++ compiler v16 ( Visual C++ 10 ) and g++ from MingW.

The long code is below, here is the relevant part and why I think the compiler does not like it.

I have a static member function in class t_threads as so-

static void run()
{
for( set<t_thread>::iterator ix = _s_pobj->_threads.begin(); ix != _s_pobj->_threads.end(); ++ix )
(*ix).run();
}
 

t_threads manages a set of t_thread objects. In the above function, it starts the threads it manages. The t_thread::run function is non-const ( of course, since it changes the state of the t_thread object ). The iterator "ix" is also non-const. But the compiler promotes the iterator to a const because t_threads::run is a static member function.

The error from g++ is -

w.cpp: In static member function `static void t_threads::run()':
w.cpp:95: error: passing `const t_thread' as `this' argument of `void t_thread::run()' discards qualifiers

This should be allowed, IMO. I need the t_threads::run function to be static because of the way I call it in main(). See below. Of course I could change the code but this is just a small part of a much larger system and I have to change similar constructs in numerous places and I am going to stick with MS C++ compiler v15 for the time being.

The sample code-

#include <stdlib.h>
#include <assert.h>
 
#include <iostream>
#include <string>
#include <set>
 
using namespace std;
 
// the t_thread object
 
class t_thread
{
public:
 
t_thread( int _tid )
: tid_ (_tid), run_(false)
{}
void run() { run_ = true; cout << "run(" << tid_ << ") running!\n"; }
 
void dump() const { cout << "dump(" << tid_ << ") run=" << run_ << "\n"; }
 
bool operator<( const t_thread& t2 ) const {
return tid_ < t2.tid_;
}
 
private:
 
bool run_;
int tid_;
};
 
// the t_threads object
 
class t_threads
{
public:
 
static int initialize( string& serr )
{
// check for multiple initialization
if( _s_initialized ) {
serr = "t_threads: multiple initialization not allowed!";
return -1;
}
 
// create the global t_threads object
_s_pobj = new t_threads();
 
if( !_s_pobj ) {
serr = "t_threads: cannot create new t_threads!";
return -1;
}
 
// remember initialization
_s_initialized = true;
 
return 0;
}
 
static void finalize()
{
delete _s_pobj;
_s_initialized = false;
}
 
static const t_threads& _this()
{
return *_s_pobj;
}
 
static void dump()
{
for( set<t_thread>::const_iterator ixc = _s_pobj->_threads.begin(); ixc != _s_pobj->_threads.end(); ++ixc )
(*ixc).dump();
}
 
static const set<t_thread>& threads()
{
return _s_pobj->_threads;
}
 
static int create( int _tid )
{ 
pair<set<t_thread>::iterator,bool> pair_ = _s_pobj->_threads.insert( t_thread( _tid ) );
 
assert( pair_.second );
 
return 0;
}
 
static void run()
{ 
for( set<t_thread>::iterator ix = _s_pobj->_threads.begin(); ix != _s_pobj->_threads.end(); ++ix )
(*ix).run();
}
 
private:
 
t_threads() {}
t_threads( const t_threads& );
t_threads& operator=( const t_threads& );
 
set<t_thread> _threads;
 
static t_threads* _s_pobj;
static bool _s_initialized;
};
 
t_threads* t_threads::_s_pobj = NULL;
bool t_threads::_s_initialized = false;
 
// main section
 
int main(int argc, char **argv)
{
string serr;
if( -1 == t_threads::initialize(serr) ) {
cout << "main: t_threads::initialize error " << serr;
return -1;
}
 
for( int i = 0; i < atoi(argv[1]); i++ )
if( -1 == t_threads::create(i)) {
cout << "main: t_threads::create error " << serr;
return -1;
}
 
t_threads::dump();
t_threads::run();
t_threads::dump();
 
t_threads::finalize();
 
return 0;
}
 

[Banfa]

Well its a bit complicated and related to the fact you are using a set.

In the newer MS C++ and gcc set<>::iterator is defined as a constant iterator and I suspect that is a specific design choice people have made.

However all iterators types are implementation defined so the fact that the definition has changed from on version of MS C++ to another and is different in GCC is not actually breaking the standard at all. It can happen, the standard says so.

I suspect (think I have seen said elsewhere) that the reason for making all iterators constant is that in a set the key is the value. However the set is sorted on the key and if you allowed the key to change that would imply a different sort order. That would mean the code would have to be able to know and alterations to the key and reorder the list when they happened.

That last bit isn't possible so the conclusion is that the key must be constant (actually a fairly normal assumption for a keyed table) however since the key is the value that means the value is constant too and so everyone has change all set iterators to be constant.

gcc definitions

     typedef typename _Rep_type::const_iterator            iterator;
      typedef typename _Rep_type::const_iterator            const_iterator;
 

The conclusion, set<> is uniquely not suited for the purpose you are trying to use it for because it is a set of constant keys. Personally I would use a list, or if you really want to use an associative container rather than a sequence a map.

[sid debgupta]

Thanks for the explanation. It makes sense.