This macro can be defined in some global header, or better, as a compiler command line parameter:
#define me (*this)
And some usage example:
some_header.h:
inline void Update()
{
/* ... */
}
main.cpp:
#include "some_header.h"
class A {
public:
void SetX(int x)
{
me.x = x;
me.Update();
}
void SomeOtherFunction()
{
::Update();
}
/*
100 or more lines
...
*/
void Update()
{
// ...
}
int x;
};
So in a class method when I access a class member, I am always using me, and when accessing a global identifier I always use ::. This gives the reader which is not familiar with the code (probably myself after a few months) localized information of what is accessed without the need to look somewhere else. I want to define me because I find using this-> everywhere too noisy and ugly. But can #define me (*this) be considered a good C++ practice? Are there some practical problematic points with the me macro? And if you as C++ programmer will be the reader of some code using the me macro, would you like it or not?
Edit: Because many people arguing not specificaly contra using me, but generaly contra explicit this. I think it may not be clear what are benefits of “explicit this everywhere”.
What are benefits of “explicit this everywhere”?
- As a reader of the code you have certainty what is accessed and you can concentrate on different things than verify – in some distant code – that is really accessed what you think is accessed.
- You can use search function more specifically. Search “
this->x” can give you more wanted results than only search “x“ - When you are deleting or renaming some member, compiler reliably notifies you at places where is this member used. (Some global function can have same name and exist chance you can introduce error if you are not using explicit this).
- When you are refactoring code and making non-member function from member (to make better encapsulation) explicit this shows you place which you must edit and you can easily replace this with pointer to instance of class given as non-member function parameter
- Generally when you are changing code, there are more posibilities to errors when you are not using explicit this than when you are use explicit this everywhere.
- Explicit this is less noisy than explicit „m_“ when you are acessing member from outside (
object.membervsobject.m_member) (thanks to @Kaz to spot this point) - Explicit this solves problem universaly for all members – attributes and methods, whereas „m_“ or other prefix is practicaly usable only for attributes.
I would like to polish and extend this list, tell me if you know about other advantages and use cases for explicit this everywhere.
15
No, it is not.
Mind the programmer who will maintain your code several years from now long after you’ve left for greener pastures and follow common conventions of the language you use. In C++, you almost never have to write this, because the class is included in symbol resolution order and when a symbol is found in class scope, this-> is implied. So just don’t write it like everybody does.
If you often get confused which symbols come from class scope, the usual approach is using common naming pattern for members (fields and sometimes private methods; I haven’t seen it used for public methods). Common ones include suffixing with _ or prefixing with m_ or m.
5
So, you want to create a new language. Then do so, and do not cripple C++.
There are several reasons not to do it:
- Every normal coding standard will suggest to avoid macros (here is why)
- It is harder to maintain code with such macros. Everyone programming in C++ knows what
thisis, and by adding such macro, you are actually adding a new keyword. What if everyone introduces something they like? What would code look like? - You shouldn’t use
(*this).orthis->at all, except in some special cases (see this answer and search for “this->”)
Your code is not different from #define R return, which I saw in the actual code. Reason? Less typing!
Going slightly off topic, but here I am going to expand on point 3 (do not use (*this). or this-> in a class).
First of all, (*this). or this-> are used to access member variables or functions of the the object. Using it is meaningless and means more typing. Also, reading such code is more difficult, because there is more text. That means harder maintenance.
So, what are the cases where you have to use this->?
(a) Unfortunate pick of the argument’s name.
In this example, this-> is required, since the argument has the same name as the member variable :
struct A {
int v;
void foo( int v ) {
this->v =v;
}
};
(b) When dealing with templates and inheritance (see this)
This example will fail to compile, because the compiler doesn’t know which variable named v to access.
template< typename T >
struct A {
A(const T& vValue):v(vValue){}
T v;
};
template< typename T >
struct B : A<T>
{
B(const T& vValue):A<T>(vValue){}
void foo( const T & newV ) {
v = newV;
}
};
19
I suggest not to do this. This gives a reader which is not familiar with your macro a big “WTF” whenever he sees this. Code does not get more readable when inventing “new conventions” over the generally accepted ones without any real need.
using this-> everywhere is too noisy and ugly
That may seem so to you, maybe because you did a lot of programming in languages using the keyword me (Visual Basic, I guess?). But in fact it is just a matter of becoming accustomed to it – this-> is pretty short, and I think most of experienced C++ programmers will disagree with your opinion. And in the case above, neither the use of this-> or the use of me is appropriate – you get the smallest amount of clutter by leaving those keywords out when accessing data members inside of member functions .
If you want your private member variables to be distinguished from local ones, add something link m_ as a prefix, or an underscore as a suffix to them (but as you can see here, even this convention is “too noisy” for many people).
6
Please don’t do it! I am trying to cope with a large code base where macros are all over the place to save typing.
The bad thing about redefining this to me is that the preprocessor will replace it everywhere even where this is not in scope/does not apply, for instance a stand-alone function, your fellow colleage might have a local variable called me somewhere else… (s)he won’t be happy debugging… You end up having macros which you can’t use in all scopes.
NO!
Just imagine the confusion that will occur if somebody #include’s that header, not knowing your trick, and elsewhere in their file they have a variable or function called “me”. They would be horribly confused by whatever inscrutable error message would be printed.
4