People that put "this->" before members:

Pages: 12
closed account (zb0S216C)
Some people do it to prevent ambiguities. Since some people use the global name-space, they usually get caught out with ambiguities. The compiler will be able to resolve such ambiguities, but to the reader, they'd probably get confused:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
int Value_( 0 );

struct Structure
{
    Structure( ) : Value_( 1 ) { }
    int Value_;

    void Print( ) const { std::cout << Value_; } // Which "Value_"?
}:

int main( )
{
    ( Structure( ) ).Print( ); // Prints 1, but the reader may not know that.
}

As the comment says, the reader may become confused at the sight of "Structure::Print( )" implementation. Given the situation, we could resolve this by either renaming the global, but that would break any implementations that directly reference "::Value_". Another possible resolution is to prefix "Structure::Value_" with "this->" to disambiguate the reference.

1
2
3
4
5
6
7
struct Structure
{
    Structure( ) : Value_( 1 ) { }
    int Value_;

    void Print( ) const { std::cout << this->Value_; } // The reference is now obvious.
}:

Wazzak
Last edited on
> you can always access static members from non-static contexts.
> It's my most hated feature of both languages and I wish it could go away
I'm reading it as `accessing a class property from a member function'
which makes no sense to be banned, ¿what did you try do say?

> Why use such an absurd design pattern (pimpl)?
> To hide implementation details
fine
> and reduce coupling
the interface is the same, ¿how is coupling reduced?
> as well as avoid the overhead of virtual method calls with interfaces for simple classes.
But you've got overhead in dereferencing the implementation pointer.
And you may made the implementation polymorphic.

It reduces compilation time, as you don't need to recompilate the clients when changing the implementation class.


> I guess you could argue that . doesn't require a pointer dereference which might save you a few CPU cycles.
I don't think that value = 42; may be faster than this->value = 42;
ne555 wrote:
which makes no sense to be banned, ¿what did you try do say?
Using the . or -> operator on an instance to access static data rather than going through the class' name.

This is fine:
1
2
SomeClass::STATIC_MEMBER //C++
SomeClass.STATIC_MEMBER //Java 
This doesn't make sense, and it is not even polymorphic:
1
2
some_instance_of_someclass.STATIC_MEMBER //C++ / Java
some_instance_of_someclass->STATIC_MEMBER //C++ 


ne555 wrote:
the interface is the same, ¿how is coupling reduced?
if the private implementation data members were listed in the header, any dependencies would need to be included such as other headers that define the types the implementation uses internally. I called this coupling for lack of a better word.

ne555 wrote:
But you've got overhead in dereferencing the implementation pointer.
And you may made the implementation polymorphic.
True, it depends on the C++ implementation.
closed account (S6k9GNh0)
I don't do this because their are better syntactical methods of telling your reader that a variable is a member of a class. It's also verbose. If you have a function parameter that's the same as a class member, perhaps you should choose more sane variable names.

To be clear, I understand that this has its uses but I don't think it was meant to be used as a prefix.
closed account (o1vk4iN6)
So you name your member functions ?

m_getSomething() ?
closed account (S6k9GNh0)
Depending but yeah.
I don't give methods special naming conventions as this->SomeMethod() is no problem and is worth it for the easy usage outside of the method definitions.

However, often the parameters will want to use the names that would have been good for the members so I always name private members with the m_ prefix as it's less writing than this-> and I use it basically all the time.

Also it helps one see what's part of the object being modified and what's just a local variable or parameter.

Public members are modified from methods less often, and are exposed, so I give them nice names without the prefix.
Last edited on
@JLBorges

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <vector>

template < typename T > struct my_vector : std::vector<T>
{
    // ...
    bool my_empty() const
    {
        // return empty() ; // *** error 'empty' is a a nondependent name
        return this->empty() ; // fine, 'empty' is a dependent name
        return std::vector<T>::empty() ; // also fine, 'empty' is a dependent name
    }
};

template struct my_vector<int> ;


why is the first return statement an error?
wht do you mean by saying that [empty] is a nondependant name?
> why is the first return statement an error?
> wht do you mean by saying that [empty] is a nondependant name?

There are two different phases of compilation when templates are involved. In somewhat simplified words:

The first phase is when a template definition is seen, and it is initially parsed. This takes place before the template is instantiated; the compiler only looks up "non-dependent" names during this phase. A name is a "non-dependent" name if the results of name lookup do not depend on any template parameters; the name refers to the same entity in all template instantiations.

The second phase is when when the template is instantiated; in phase two the compiler looks up "dependent" names. Obviously, the result of this lookup may vary from one template instantiation to another.

See: http://www.parashift.com/c++-faq-lite/nondependent-name-lookup-members.html
I am aware of the two phase process in template compilation but did not know that a consequence of this process would result in compilation errors for the example provided above.

From a comment on the link provided:

← bad (even though some compilers erroneously (temporarily?) accept it)


would that suggest that all future versions of compilers will aim to also not accept such code?

i have tested the code above on three compilers and found that all of them accepts the code. could you provide an example of a compiler that does not accept it?
SIK wrote:
could you provide an example of a compiler that does not accept it?

are you referring specifically to the C++ FAQ code sample?

g++ 4.7.2
test.cc:12:7: error: there are no arguments to ‘f’ that depend on a template parameter, so a declaration of ‘f’ must be available [-fpermissive]

clang++ 3.2
test.cc:12:5: error: use of undeclared identifier 'f'

IBM XL 11.1
"test.cc" line 12.5: 1540-0274 (S) The name lookup for "f" did not find a declaration

intel 13.0 and sun studio 12 accept it for me (for shame)
Last edited on
Topic archived. No new replies allowed.
Pages: 12