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

[E. Robert Tisdale]

Markus Dehmann wrote:

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(void) const = 0;
}; class Implementation: public Interface { private: std::string text;
public:
Implementation( std::string text):text(text ) { } virtual std::string& getText(void) 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.
cat test.cpp #include <iostream>
class Interface {
public:
virtual
std::string& getText(void) const = 0;
};

class Implementation: public Interface {
private:
std::string text;
public:
Implementation( std::string text): text(text) { }
virtual
std::string &getText(voi d) const {
return text;
}
};
g++ -Wall -ansi -pedantic -c test.cpp test.cpp:8: warning: `class Implementation' \
has virtual functions but non-virtual destructor
test.cpp: In member function \
`virtual std::string& Implementation: :getText() const':
test.cpp:15: error: invalid initialization of reference \
of type 'std::string&' from expression \
of type 'const std::string' g++ --version

g++ (GCC) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)

Try the gnu.g++.help newsgroup.
Also, try comparing the GNU C++ diagnostic messages
with the diagnostic messages produced by other compilers.
I think that you will find that they compare favorably.
Don't expect too much from compiler diagnostics.
The compiler can't know what you *intended* to write.
It doesn't pick up "understand ing" from comments
or your choice to type and variable names.
Diagnostics are pretty much constrained to the rules
of the C++ computer programming language
which, unfortunately, don't always help you understand
what you did wrong.

[JKop]

I tried fiddling with the code. Here's what I've got:

class Interface
{
public:
virtual std::string& GetText() const = 0;
};

class Implementation : public Interface
{
private:

std::string text;

public:

Implementation( const std::string& in_text) : text(in_text) { ; }

virtual std::string& GetText() const
{
return text;
}
};

int main()
{
std::string k = "PooPoo";

Implementation p(k);
}

I'm at a loss to explain why it won't compile. G++ is giving me the
following:
t:/poo.cpp: In member function `virtual std::string& Implementation: :GetText
()
const':
t:/poo.cpp:22: could not convert `this->Implementation ::text' to
`std::string&'

Anyone?

-JKop

[Xenos]

"JKop" <NU**@NULL.NULL > wrote in message
news:Ax******** *********@news. indigo.ie...

I tried fiddling with the code. Here's what I've got:

class Interface
{
public:
virtual std::string& GetText() const = 0;
};

class Implementation : public Interface
{
private:

std::string text;

public:

Implementation( const std::string& in_text) : text(in_text) { ; }

virtual std::string& GetText() const
{
return text;
}
};

int main()
{
std::string k = "PooPoo";

Implementation p(k);
}

I'm at a loss to explain why it won't compile. G++ is giving me the
following:
t:/poo.cpp: In member function `virtual std::string& Implementation: :GetText ()
const':
t:/poo.cpp:22: could not convert `this->Implementation ::text' to
`std::string&'

Anyone?

You are trying to make a constant member function return a non-constant
reference to a member. The compiler is telling you it cannot convert a
const string& to a string&

DrX

[JKop]

Thanks.
The following compiles:
#include <string>
#include <iostream>

class Interface
{
public:
virtual std::string& GetText() = 0;
};

class Implementation : public Interface
{
private:

std::string text;

public:

Implementation( const std::string& in_text) : text(in_text) { ; }

virtual std::string& GetText()
{
return text;
}
};

int main()
{
std::string k = "PooPoo";

Implementation p(k);
}

-JKop

[Xenos]

"JKop" <NU**@NULL.NULL > wrote in message
news:75******** *********@news. indigo.ie...

Thanks.
The following compiles:
#include <string>
#include <iostream>

class Interface
{
public:
virtual std::string& GetText() = 0;
};

class Implementation : public Interface
{
private:

std::string text;

public:

Implementation( const std::string& in_text) : text(in_text) { ; }

virtual std::string& GetText()
{
return text;
}
};

int main()
{
std::string k = "PooPoo";

Implementation p(k);
}

-JKop

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&

[JKop]

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

[Ronald Landheer-Cieslak]

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

[JKop]

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.

-JKop

[Markus Dehmann]

JKop <NU**@NULL.NULL > wrote in message news:<Ax******* **********@news .indigo.ie>...

I tried fiddling with the code. Here's what I've got:

class Interface
{
public:
virtual std::string& GetText() const = 0;
};

class Implementation : public Interface
{
private:

std::string text;

public:

Implementation( const std::string& in_text) : text(in_text) { ; }

virtual std::string& GetText() const
{
return text;
}
};

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