Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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.member vs object.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.

share|improve this question
3  
You should avoid having function arguments and members with the same name, as well as avoiding explicit "this". –  pjc50 Jul 14 at 9:32
3  
Reminds me of my boss' VB code. Me Me Me everywhere. Sounds selfish. :p Anyway, the answers so far say it all. –  MetalMikester Jul 14 at 12:05
17  
It is a wonderful idea! And for those who come from a Python background, why not #define self (*this) ? You can even mix both macros and have some files imitating VB and others Python. :) –  logc Jul 14 at 13:38
10  
Why not just go all out, and do: #include "vb.h", #Include pascal.h, or #include FOTRAN.h and have the next person to touch your code submit it to TDWTF. –  Dan Neely Jul 14 at 15:10
4  
Oh please, just no. You could save yourself some trouble by just declaring attributes as me_x. –  Steven Burnap Jul 14 at 18:39

5 Answers 5

up vote 82 down vote accepted

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.

share|improve this answer
9  
"In C++, you almost never have to write this" that's a totally unrelated convention to the question. Some people (like me) prefer to write this to explicitly make it clear that the variable is not local to the method. The question here is about whether the macro me should exist, not whether this is something that should be used. –  Mehrdad Jul 14 at 20:43
8  
@Mehrdad: Because the OP explicitly says he is using me. instead of this->. Since there is no need for this-> there is no need for me. and thus no need for the macro. –  Loki Astari Jul 14 at 21:36
9  
@LokiAstari: Nothing in the question even remotely hints at the OP wondering whether this-> "is necessary". In fact, the OP says he is using this-> in spite of the fact that it's not necessary. The question is about whether me. should be used instead of this->, which this answer doesn't actually answer. –  Mehrdad Jul 15 at 0:51
3  
@Mehrdad: But only putting yes or no makes a very boring answer. Thus explanations are usually quite useful in explaining how the answer is reached (is encoraged by How to answer ). The conclusion is not to use because the OP has the wrong attitude to start with about using this and thus a discussion on that point is required to achieve a fully balanced conclusion. –  Loki Astari Jul 15 at 1:12
1  
+1 for explaining why, instead of just saying "No, it's a bad practice." –  immibis Jul 15 at 1:18

So, you want to create a new language. Then do so, and do not cripple C++.

There are several reasons not to do it:

  1. Every normal coding standard will suggest to avoid macros (here is why)
  2. It is harder to maintain code with such macros. Everyone programming in C++ knows what this is, and by adding such macro, you are actually adding a new keyword. What if everyone introduces something they like? What would code look like?
  3. You shouldn't use *this. or this-> 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 mean 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;
    }
};
share|improve this answer
1  
"So, you want to create a new language. Then do so, and do not cripple c++." - I disagree. A major strength of C and C++ is their flexibility. The OP is not crippling C++, just utilizing its flexibility in a particular way to make it easier for him or her to code. –  immibis Jul 15 at 7:50
1  
@immibis Right. What is easier for him, is harder for everybody else. When you work in a team, putting such nonsenses in the code will not make you very favorable. –  BЈовић Jul 15 at 7:56
2  
Your answer is not different from "defines are evil". –  Mr Lister Jul 15 at 8:34
5  
@MrLister My answer is "stupid defines are evil". The macro in the question is stupid to use, and as I showed, not needed at all. The code is good and even better without *this. and this-> –  BЈовић Jul 15 at 8:51
    
You just lost my up vote when I read case 3. *this has very good uses. –  Thomas Eding Jul 15 at 16:09

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).

share|improve this answer
12  
_ should be suffixed; as prefix it is reserved for internal symbols of standard libraries and vendor extensions. –  Jan Hudec Jul 14 at 7:20
4  
@JanHudec Only if it starts with __ (two underscores) or an underscore followed by a capital letter. A single underscore followed by a lower case letter is fine, as long as it's not in the global namespace. –  Eric Finn Jul 14 at 13:33
1  
@EricFinn: I combined the two rules to one. Two underscores or underscore followed by capital letter is for internal symbols and single underscore followed by lower case letter is for system-specific extensions. Applications should not use either. –  Jan Hudec Jul 14 at 14:36
    
@JanHudec Wasn't aware of the rule for system-specific extensions. I'll leave my previous comment to provide some context for your comment, though. –  Eric Finn Jul 14 at 14:38
2  
@JanHudec: Lowercase is for system-specific extensions? Could you post a reference to the part of the C++ standard that indicates this? –  Mehrdad Jul 14 at 20:45

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.

share|improve this answer

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.

share|improve this answer
    
In practice, they're quite likely to mouse-over "me" with their IDE and see the definition. –  immibis Jul 16 at 2:30
1  
@immibis: In practice, though, they're also likely to say something like "who wrote this crap?". :P –  cHao Jul 16 at 13:05
    
@immibis: most of the top coders I work with don't use the mouse - it is too slow. –  JBRWilkinson Jul 16 at 22:56

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.