compiler error when getter/setter have same name as variable

[Andrey Vul]

In the following:
class Foo {
public:
int bar() const {
return bar;
int bar(int newbar) {
return (bar = newbar);
}
bool operator==(const Foo& rhs) {
return (bar() == rhs.bar()); // error here
}
private:
int bar;
}

Where in ISO C++ does the distinction between function return value
and variable exist? My compiler (MSVC 10) chooses the variable itself
and dies about needing a (pointer to) function type, as opposed to
doing the smart thing and comparing the return values of the getters.
And is the compiler allowing get/set overloading with member part of C+
+0x?

 

[Öö Tiib]

In the following:
class Foo {
public:
int bar() const {
return bar;
int bar(int newbar) {
return (bar = newbar);}

bool operator==(const Foo& rhs) {
return (bar() == rhs.bar()); // error here}

private:
int bar;

}

It does not compile, but i get your point.

Where in ISO C++ does the distinction between function return value
and variable exist? My compiler (MSVC 10) chooses the variable itself
and dies about needing a (pointer to) function type, as opposed to
doing the smart thing and comparing the return values of the getters.
And is the compiler allowing get/set overloading with member part of C+
+0x?

Functions with different parameters may have same name, but you should
use different names for local variables, data members, parameters,
functions and types. If you do otherwise, you confuse the readers of
your code even if language allows it. Standards specifications of name
hiding are hard to read and all leading compilers do name lookup with
slight differences so you don't get too portable code with lot of
clashing names.

Data members are biggest offender so these i mark with trailing
underscore:

class Foo
{
public:
int bar() const
{
return bar_;
}

void bar( int newBar )
{
bar_ = newBar;
}

bool operator==( const Foo& that )
{
return ( bar_ == that.bar_ );
}

private:
int bar_;
};

 

[Andrey Vul]

It does not compile, but i get your point.


Functions with different parameters may have same name, but you should
use different names for local variables, data members, parameters,
functions and types. If you do otherwise, you confuse the readers of
your code even if language allows it. Standards specifications of name
hiding are hard to read and all leading compilers do name lookup with
slight differences so you don't get too portable code with lot of
clashing names.

Data members are biggest offender so these i mark with trailing
underscore:

You can tell it's been a few years since I last coded in C++ :\
I forgot all about const-overloading. With that, all problems are
solved since there is a getter+setter, thus requiring no need for the
member name to clash.
Another bonus is that the use of getters in operator==(const Foo&)
const{}, etc. allows the compiler to give errors when something needs
to be paid attention to.

An even better rewrite of class Foo would be:
class Foo {
public:
int const& bar() const { return bar_; }
int& bar() { return bar_; }
bool operator==(const Foo& that) const { return (bar() ==
that.bar()); }
private:
int bar_;
};

 

[Marcel Müller]

Another bonus is that the use of getters in operator==(const Foo&)
const{}, etc. allows the compiler to give errors when something needs
to be paid attention to.

An even better rewrite of class Foo would be:
class Foo {
public:
int const& bar() const { return bar_; }
int& bar() { return bar_; }
bool operator==(const Foo& that) const { return (bar() ==
that.bar()); }
private:
int bar_;
};

I don't see what the advantage of using bar() in operator== should be.

But normally it is unwise to declare commutative binary operators as
class members rather than free functions. This declaration is asymmetric
with respect to the operands. Some implicit conversions are not possible
for the left operand.


Marcel

 

[Daniel Pitts]

What's the point of returning a value that the caller already has?

Sometimes, when I make a call, I forget what I pass in, so I need to
have it passed back ;-)

Personally, I'd rather have it a Foo& with the value of *this, so that I
could chain the setter calls.

 

[Comité d'Entreprise Credence]

In the following:
class Foo {
public:
int bar() const {
return bar;
int bar(int newbar) {
return (bar = newbar);}

bool operator==(const Foo& rhs) {
return (bar() == rhs.bar()); // error here}

private:
int bar;

}

Where in ISO C++ does the distinction between function return value
and variable exist? My compiler (MSVC 10) chooses the variable itself
and dies about needing a (pointer to) function type, as opposed to
doing the smart thing and comparing the return values of the getters.
And is the compiler allowing get/set overloading with member part of C+
+0x?

Hello,

In case bar is an object of a class that defines an operator(), this
compiler error is quite relevant.

Nicolas

 

[Nicolas Biscos]

In the following:
class Foo {
public:
int bar() const {
return bar;
int bar(int newbar) {
return (bar = newbar);}

bool operator==(const Foo& rhs) {
return (bar() == rhs.bar()); // error here}

private:
int bar;

}

Where in ISO C++ does the distinction between function return value
and variable exist? My compiler (MSVC 10) chooses the variable itself
and dies about needing a (pointer to) function type, as opposed to
doing the smart thing and comparing the return values of the getters.
And is the compiler allowing get/set overloading with member part of C+
+0x?

Hi,

In case bar is an object of a class defining an operator(), this
compiler error seems relevant

Nicolas