A::foo() or a.foo()

[saneman]

In A.h I have:

class A {
public:
std::list<int>l;
int foo();
...
...

};

In A.cpp I have:

int A::foo() {
return A::l.top(); // (1)
return l.top(); // (2)
return (this*).l.top(); // (3)
}

All 3 returns give the correct result (when used separately). But which
one is best to use or is it just a matter of taste?

 

[Victor Bazarov]

In A.h I have:

class A {
public:
std::list<int>l;
int foo();
...
...

};

In A.cpp I have:

int A::foo() {
return A::l.top(); // (1)
return l.top(); // (2)
return (this*).l.top(); // (3)
}

All 3 returns give the correct result (when used separately). But
which one is best to use or is it just a matter of taste?

The best is not to have 'l' public.

As to what form to use for accessing members, then in your
situation it is the matter of taste. All three are equivalent
from the language POV.

V

 

[saneman]

The best is not to have 'l' public.

As to what form to use for accessing members, then in your
situation it is the matter of taste. All three are equivalent
from the language POV.

V

In my current implementation 'l' is protected, like the sequence
instance in std::stack.

 

[Christian Hackl]

int A::foo() {
return A::l.top(); // (1)
return l.top(); // (2)
return (this*).l.top(); // (3)

Are you sure you did not mean to write:

return (*this).l.top();

?

Your version should not even compile.

 

[Bo Persson]

In my current implementation 'l' is protected, like the sequence
instance in std::stack.

Which is a very strange choice for std::stack as well.

Unless there are some very special reasons, members are most often
private.

And I would generally chose option (2).



Bo Persson

 

[Andrey Tarasevich]

...
In A.cpp I have:

int A::foo() {
return A::l.top(); // (1)
return l.top(); // (2)
return (this*).l.top(); // (3)
}

All 3 returns give the correct result (when used separately). But which
one is best to use or is it just a matter of taste?

It is always a matter of taste, but normally one'd use version 2.
Versions 1 and 3 (BTW, you have a typo in 3) can (and will) be useful in
certain specific circumstances, but there's no point of using them all
the time.

 

[James Kanze]

The best is not to have 'l' public.

As to what form to use for accessing members, then in your
situation it is the matter of taste. All three are equivalent
from the language POV.

On the other hand, if a reader sees anything but (2), he's going
to wonder why? The one exception would be in templates, where
this->l.top() might be used.

 

[Victor Bazarov]

On the other hand, if a reader sees anything but (2), he's going
to wonder why?

Depends on the reader...

The one exception would be in templates, where
this->l.top() might be used.

There is no reason in templates to use 'this->' to access your
own member.

The only reason I think the additional qualification or the member
access operator might be needed is to resolve the name correctly
if it's _hidden_ by another name in the scope:

for (int l = 0; l < 42; ++l) { // hides 'l' member
this->l.push_back(666); // resolves to 'l' member
}

V

 

[Alf P. Steinbach]

* Victor Bazarov:

Depends on the reader...


There is no reason in templates to use 'this->' to access your
own member.

template< typename T >
struct Base
{
void foo() {}
};

template< typename T >
struct Derived: Base<T>
{
void bar() { this->foo(); }
};

Cheers, & hth.,

- Alf

 

[James Kanze]

Depends on the reader...

Have you ever seen a body of C++ code which used anything but
(2)? I'd pretty much say that (2) was "established practice",
and that anything else represents a special case. And
confronted with a special case, my first question would always
be: why didn't the programmer follow established practice.

There is no reason in templates to use 'this->' to access your
own member.

Not your own member, but you need something to make the look-up
dependent when trying to access a member of a dependent base
class. The result is that there is an "established practice" of
using this-> in such cases, and it is not unreasonable to
imagine a programmer extending it to all member accesses in a
template.

It is, at any rate, the only convention other than (2) that I've
seen used at all.

The only reason I think the additional qualification or the
member access operator might be needed is to resolve the name
correctly if it's _hidden_ by another name in the scope:

If there is a dependent base class, using this-> forces
dependent name lookup. And it seems to be the most widely
spread idiom to force dependent name lookup in such cases.

 

[Victor Bazarov]

* Victor Bazarov:

template< typename T >
struct Base
{
void foo() {}
};

template< typename T >
struct Derived: Base<T>
{
void bar() { this->foo(); }

I said "your own member".

};

Cheers, & hth.,

- Alf

V

 

[Alf P. Steinbach]

* Victor Bazarov:

I said "your own member".

i noticed

dismissed cause if that subtlety was intention would've been meaningless


cheers,

- Alf