Thought I tried that last night but apparently not. Regarding "this->input_queue…", the 'this' pointer may be optional there but it's a style choice to help make it clear where the structure is coming from.

Regarding "this->input_queue…", the 'this' pointer may be optional there but it's a style choice to help make it clear where the structure is coming from.

Personally I think that should be indicated otherwise. There are several options:- if trying to differentiate with global variables, prefix global variables with "g" or something. e.g., gInputQueue. (Actually, I think that's a good idea in general, because it is immediately obvious if a variable is global or not.)- if trying to differentiate with a static class variable, use the class name, e.g. MyClass::theVariable.- if trying to differentiate local vs. member variables, mark member variables with something. Some people like putting an m in front, e.g. mInputQueue. I like putting an underscore at the end, e.g. inputQueue_. Again, this is a good idea in general because it is immediately obvious where something is coming from.

In short and IMHO, if you need to use "this" to mark where a variable is coming from, then that is indicative of potential confusion in several places. A name alone in almost all cases should suffice to tell you what you need to know about the variable. Some people go so far as to encode the type itself in the name, for example, miPeopleInRoom to denote the number (int) of people in the room as a member (m) variable. I tend to not do that for various reasons.

Having a convention and sticking to it religiously can dramatically improve the clarity of code. One of my codebase's problems is that in the many years I've been working on it, I have changed styles as I find that some things work better than others. It's interesting actually that you can almost tell when I wrote a segment of code by looking at the style it's written in. :wink:

Personally I think that should be indicated otherwise. There are several options:

It's true that using this-> as an indicator is pretty non-standard in C++, but I myself actually kind of like it. I really kind of just prefer that every identifier by qualified without relying on manual naming conventions. Maybe I've just spent too many years working in dynamic languages that essentially force you to do that, though. :)

Quote

Some people go so far as to encode the type itself in the name, for example, miPeopleInRoom to denote the number (int) of people in the room as a member (m) variable. I tend to not do that for various reasons.

These people are lame. The original "hungarian notation" had nothing to do with specifying types in names. The compiler already makes sure you can't misuse a type. The original purpose was to mark information about a variable's data that is not immediately obvious from the type. For example, if you are working on an application that has to deal with SQL queries, you would want to differentiate between strings which are just user input and strings which are supposed to be part of a SQL query, thus making it possible to write static analysis tools that would notice if you tried to concatenate unquoted user-data into one of your strings. Another example might be marking pointer types with whether or not they represent ownership of the object or not. Keep in mind that in those days, standardized C++ did not have even half the features it has today; hence why Microsoft's Win32 APIs still include a lot of cruft like a non-STL string class. Enforcing that kind of type behavior using templates or other useful C++ tricks was not feasible then. The technique is attributed to one of the Microsoft Word developers, but the other doofuses at Microsoft misunderstood the intent and ending up standardizing this huge monstrous type notation that does nothing but make variable names longer, harder to remember, and often just flat out inaccurate when types change but updating every variable name is too tedious.

Quote

One of my codebase's problems is that in the many years I've been working on it, I have changed styles as I find that some things work better than others. It's interesting actually that you can almost tell when I wrote a segment of code by looking at the style it's written in. :wink:

That's true for quite a bit of code out in the wild, too. :)

Personally, I think that if he wants to use this-> to reference member variables and methods, more power to him. It's unorthodox, but there is absolutely no compelling reason to prefer other approaches outside of "less typing." To be perfectly honest, if I were designing C++ from scratch today, I never would have added class scope (but I would have added an automatic class:: or self:: scope).

Perhaps. You've given some alternatives but you haven't really given any of these potential reasons. Care to elaborate?

I'm assuming you mean reasons for confusion? Well, here's my favorite: it means that scope is not clear enough from context. Is there another input queue I should be worrying about, that makes me specify "this"?

ghasatta said:

Quote

Having a convention and sticking to it religiously can dramatically improve the clarity of code

I agree, which is why I use my convention ;)

Yes – and yet here you are showing off an example of convoluted C++ syntax. :wink:

There's a reason why prefixing every instance variable with "this->" is unorthodox. Yes, it means less typing, but more importantly, less typing means less characters you need to sift through. Every time you see a dereference, you need to stop to process what's going on. In some cases, it leads to things like the line of code that started this thread.

This kind of terseness is good for many reasons: it means less "useless" information to process (as I said above, context should already be clear). Saving screen space is important because you can see more code at once, and more importantly, you keep lines less wide so you do not have to scroll back and forth or break them manually in the code.

Obviously there are limits (it is excessive to remove all strictly unnecessary whitespace, for example), but generally verbosity for the sake of verbosity is to be avoided as it detracts from the semantic content: the meaning of the code.