Why are g++ error messages so daunting?

[Markus Dehmann]

I have started with C++ a few months ago. The language itself is nice,
but what I really don't like are the error messages that I get from
g++.

g++ error messages are often just not helpful.

Sometimes I just take the line number of the error and try to figure
out myself what might be wrong. Or I just remember this error message
and know already: if g++ says error X it really means error Y.

For example, take the following code:

#include <iostream>
class Interface{
public:
virtual std::string &getText() const = 0;
};
class Implementation : public Interface{
std::string text;
public:
Implementation: :Implementation (std::string text):text(text ){}
std::string &getText() const{
return text;
}
};

bash-2.05b$ g++ -c test.cpp
test.cpp: In member function `virtual std::string&
Implementation: :getText()
const':
test.cpp:13: could not convert `this->Implementation ::text' to
`std::string&'

The return type of getText() must not be std::string, but const
std::string. But why doesn't g++ just say that? It could say: "Could
not return reference to this->... from a const method"...

For beginners, it's also intimidating to get an error message that
fills several screens from the STL usage
std::vector<std ::string> test;
std::cout << test;
The whole "candidates are..." list with 26 entries is anyway
unreadable... There should be a better, more readable way to indicate
an error.

Markus

[JKop]

Markus Dehmann posted:

I'm curious: Why did you (and E. Robert Tisdale) change my
std::string &getText() const{return text;}
to
virtual std::string &getText() const{return text;}

Is it a convention that in subclasses, the "virtual" keyword should
remain, like in the superclass definition?

Thanks
Markus

Here's how it starts:

class Interface;

And then:

class Implementation : public Interface;
As the overidden function is virtual in the base class, it's virtual in the
derived class. Even though you haven't written "virtual" in the derived
class, it *has* to be virtual. So there's reason 1:

Reason 1: Because it actually is virtual

Then there's the fact that you can just read through the derived class's
definition and see which functions are virtual, rather than having to check
back with the base class's definition.

Reason 2: It's a convenient indicator in the definition of the derived class
of which functions are in fact virtual, without having to look back at the
definition of the base class.

Now, obviously when you're writing your derived class, you're going to be
aware that this certain function is virtual, and so you going to write code
accordingly. If you derive a class from this derived class, eg.

class SuperImplementa tion : public Implementation

Then again, this certain function is going to be virtual in
SuperImplementa tion aswell, and the code will be again be written
accordingly.
Now consider that you change things so that Implementation no longer
inherits from Interface. You haven't specified "virtual" in Implementation,
so this function will no longer be virtual, and concordantly, the function
in SuperImplementa tion will no longer be virtual either, even though you've
written code according to it being virtual. When this happens, you're going
to have to go back to the derived class and stick in "virtual" to set it
that it's still virtual. You may aswell just stick in in the first place to
avoid this.

Reason 3: When you change the inheritence, the derived class's functions are
still virtual.
-JKop

[Ronald Landheer-Cieslak]

JKop wrote:

Ronald Landheer-Cieslak posted:

JKop wrote:

Xenos posted:

Instead of giving the caller write access to the string, I would
suggest "going the way" to fix it. Meaning, keep the member function
constant, and change the return type to const std::string&

I was just trying to get the code to compile without interferring. Good
points though. But then some may say that you should use an accessor
function and return by value... which is a good point also.

-JKop

returning by value implies a copy (which the compiler may then optimize
away) whereas returning a const reference doesn't (so there's less to do
for the optimizer). Hence

const std::string & MyClass::GetTex t(void) const;

is preferable to

std::string MyClass::GetTex t(void) const;

because it doesn't rely on the compiler to optimize the extra copy away.

Note, however, that it does rely on the type of text in the class not
changing: passing back a value is better if you think the type of your
text member variable may change from std::string to something else..

HTH

rlc

But then Implementation must store the string in a fully-fledged string
object. Consider if it pulled if from the air, from the Windows registry,
from the DOS autoexec.bat, then it wouldn't have a reference to return.

Did you read the last paragraph of what I wrote?
And the original post? (especially, the class' definition)

Just in case, the OP class definition:
<snip>
#include <iostream>
class Interface{
public:
virtual std::string &getText() const = 0;
};
class Implementation : public Interface{
std::string text;
public:
Implementation: :Implementation (std::string text):text(text ){}
std::string &getText() const{
return text;
}
};
</snip>

and the last paragraph, with a bit of highlighting:

Note, however, that it does rely on the type of text in the class not ^^^^ ^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^changing: passing back a value is better if you think the type of your ^^^^^^^^text member variable may change from std::string to something else..

^^^^^^^^^^^^^^^ ^^^^^^^^^^^^

So yes, my suggestion does depend on that, as I already pointed out..
Thanks for noticing ;)

rlc