operator overloading

[jseb]

Hello,

I thought i had understood operator overloading.
Look the small code below.
It should not print "same amount" when comparing "Me" and "You", but
that's what i get.

Could you tell me where i'm wrong, please ? Thank you.


#include <iostream>

class Foo {
private:
int gold;

public:
Foo(int gold) { this->gold = gold; }
~Foo() {}
bool operator== (const Foo &);

};

bool Foo:perator== (const Foo &other)
{
std::cout << ". = " << gold << "; .other = " << other.gold << "\n";
if (other.gold==gold) return true;
}

int main(void)
{
Foo Me(42);
Foo You(33);

if (Me==You) std::cout << "same amount\n";

return 0;
}

 

[Ian Collins]

#include <iostream>

class Foo {
private:
int gold;

public:
Foo(int gold) { this->gold = gold; }

Better: Foo(int gold) : gold(gold) {}

~Foo() {}
bool operator== (const Foo &);

};

bool Foo:perator== (const Foo &other)
{
std::cout << ". = " << gold << "; .other = " << other.gold << "\n";
if (other.gold==gold) return true;

What does this return if other.gold != gold!

 

[Goran Pusic]

Hello,

I thought i had understood operator overloading.
Look the small code below.
It should not print "same amount" when comparing "Me" and "You", but
that's what i get.

Could you tell me where i'm wrong, please ? Thank you.

#include <iostream>

class Foo {
    private:
       int gold;

    public:
       Foo(int gold) { this->gold = gold; }
       ~Foo() {}
       bool operator== (const Foo &);

};

bool Foo:perator== (const Foo &other)
{
   std::cout << ". = " << gold << "; .other = " << other.gold << "\n";
   if (other.gold==gold) return true;

Try to compile with maximum level of warnings possible (look at your
compiler's docs for that).

Here, you return true if "if" holds, and you invoke undefined behavior
if "if" doesn't hold.

If you compiled with better warning level, compiler would have told
you that you don't return a value from all code paths.

also, operator== is canonically like this:

bool TYPE:perator==(const TYPE& rhs) const
{
return
member1==rhs.member1 &&
member2==rhs.member2 &&
...
memberX==rhs.memberX;
}

Goran.

 

[Marcel Müller]

also, operator== is canonically like this:

bool TYPE:perator==(const TYPE& rhs) const

and it should be defined outside the class or as friend because of the
type conversion rules.

friend bool operator==(const TYPE& lhs, const TYPE& rhs);


Marcel

 

[jseb]

Thank you for the answers.

That's true, i should have raised the compiler level of warnings.
With "-Wall" (all warnings for gcc) , i get a warning about returning
nothing of a non-void function.

I'll keep -Wall on compiler line, for now.

 

[Ian Collins]

Thank you for the answers.

That's true, i should have raised the compiler level of warnings.
With "-Wall" (all warnings for gcc) , i get a warning about returning
nothing of a non-void function.

I'll keep -Wall on compiler line, for now.

s/now/ever/

 

[Jens Thoms Toerring]

s/now/ever/

And perhaps you should also add -Wextra since the 'all' in
-Wall doesn't really mean all...

Regards, Jens

 

[Juha Nieminen]

And perhaps you should also add -Wextra since the 'all' in
-Wall doesn't really mean all...

How about -pedantic and -ansi?

 

[Juha Nieminen]

-Wall -Wextra -pedantic -ansi -Weffc++ -Wunused-Wshadow -Werror

The only problem is that with the above, most thrid party libraries
fail to compile.

Remove -Werror. It doesn't make any sense anyways (because the set
of minor/pedantic warnings gcc will issue is more or less arbitrary
anyways, and some of the warnings may be issued from completely valid
and standard-conforming code.)

They can, however, help you catch actual errors.

 

[Joshua Maurice]

-Werror... Ah yes, can be removed... but then that means you need to
walk around with a stick to hit those that just ignore warnings.
-Werror just simplify this

But yes, I don't usually leave it in for large projects, it's totally
unworkable especially due to third party libraries.  I don't generally
use -pedantic either, just too noisy.  But for learning and small self
contain code base, -Werror and -pedantic are not a bad idea.

I agree that a lot of the warnings are useless. However several are
very important. What I've done in my own company is as follows. In the
build system, I wrote code which parses the output of gcc, visual
studios, etc., to catch the warnings "warning, deleting pointer to
incomplete type" and "warning, deleting pointer of void pointer type".
(IIRC, visual studios only gives a warning on one so I only catch one
on win32, but gcc warns on both. Stupid visual studios.) When the
build system catches it, it fails the build and deletes the output
object file.

Thus, while gcc might not have the diagnostics "properly" separated
between warnings and errors, you could treat certain warnings as
errors without too much effort by writing the logic on top of gcc in a
simple shell script. I find this is quite useful for those who might
not bother checking warnings.