error: passing const ... discards qualifiers

[danny van elsen]

hello all,

I don't understand the implications of the 'const' keyword in the
following...

I have a class
class util::Utilities
{
public:
.... usual stuff ...
string int_to_hexstring(int i);
}

and an other class (building on the gnome gtkmm class hierarchy)
class dis::gui::Gui_TreeModel
: public Glib::Object,
public Gtk::TreeModel
{
public:
.... usual stuff ...

protected:
virtual void get_value_vfunc(const TreeModel::iterator& iter, int column,
Glib::ValueBase& value) const;

private:
util::Utilities u;
}

inside the function
void
dis::gui::Gui_TreeModel::get_value_vfunc(const TreeModel::iterator& iter, int column, Glib::ValueBase& value) const

I cannot put :
std::string result_string;
result_string = u.int_to_hexstring(dn->memory_offset);

because this gives the error

passing `const util::Utilities' as
`this' argument of `std::string util::Utilities::int_to_hexstring(int)'
discards qualifiers

however, this works:

std::string result_string;
util::Utilities u2;
result_string = u2.int_to_hexstring(dn->memory_offset);


- I don't understand the difference between the two? why is one version
legal, while the other isn't?

greetings, Danny.

 

[danny van elsen]

I'm using gcc 3.3.1 ...

 

[Pete Becker]

I have a class
class util::Utilities
{
public:
... usual stuff ...
string int_to_hexstring(int i);
}

int_to_hexstring cannot be called on a const object of type util::Utilities.

inside the function
void
dis::gui::Gui_TreeModel::get_value_vfunc(const TreeModel::iterator& iter, int column, Glib::ValueBase& value) const

I cannot put :
std::string result_string;
result_string = u.int_to_hexstring(dn->memory_offset)

u is a const object.

std::string result_string;
util::Utilities u2;
result_string = u2.int_to_hexstring(dn->memory_offset);

u2 is not a const object.

 

[danny van elsen]

u is a const object.


u2 is not a const object.

ok, I more or less worked that out myself; but why the difference?

I don't see: why is u considered const, and u2 not?

greetings, D.

 

[Pete Becker]

ok, I more or less worked that out myself; but why the difference?

I don't see: why is u considered const, and u2 not?

u2 is not const because it's not declared const. u is const because it's
a member of the object whose member function is begin called, and the
member function is declared const. Like this:

struct S0
{
void f();
};

struct S1
{
S0 data;
void g() const
{
data.f(); // illegal: data is const because 'this' is const S1*
S0 local_data;
local_data.f(); // okay: local_data is not const
}
{;

 

[danny van elsen]

u2 is not const because it's not declared const. u is const because it's

a member of the object whose member function is begin called, and the
member function is declared const. Like this:

ok, I understand... I think... more or less.

but since get_value_vfunc is a frequently called function, it makes sense
trying to avoid constructing and destructing a temporary object
util::Utilities in this function.

So I adapted the class declaration to

class dis::gui::Gui_TreeModel
....
{
....

private:
util::Utilities *u;
}

with

dis::gui::Gui_TreeModel::Gui_Disassembly_TreeModel()
....
{
....
u = new util::Utilities();
}

and

void
dis::gui::Gui_TreeModel::get_value_vfunc(const TreeModel::iterator& iter,
int column, Glib::ValueBase& value) const
result_string = u->int_to_hexstring(dn->memory_offset);

now compiles.

does this seem a correct way to proceed?

many thanks for your response!

bye, D.

 

[Pete Becker]

ok, I understand... I think... more or less.

but since get_value_vfunc is a frequently called function, it makes sense
trying to avoid constructing and destructing a temporary object
util::Utilities in this function.

I didn't suggest creating a temporary object. I also didn't suggest
creating an auto object, which is what u2 is. You asked why an auto
object produced a different result than a member. Rather than go through
all that hokum, though, it seems like int_to_hextring probably ought to
be const, or possibly static. Unless it does something that its name
doesn't suggest...