# void as a function parameter

116 replies to this topic

### #61bramz

Valued Member

• Members
• 189 posts

Posted 01 June 2006 - 06:41 PM

this->, this., my., self., foo., bar->, it really doesn't matter does it? It's not English literature. C++ has this-> and that's what we're going to have to use. If you can't deal with it, then design your own language. Abusing the preprocessor to "fix" the syntax to your own taste, is just plain evil. One should be expelled from class for doing that. Reminds me of those pascal veterans who defined begin and end to { and }. Can you image combining STL code with that?

Quote

Quote:
Originally Posted by Nick
The use of 'm_' should die completely though.

Care to explain why? I like my m_ ´s.

I'd like to know why myself. Over the years, I've used myFoo, m_foo and now I'm using foo_. The latter is my personal favourite, but it really doesn't matter which one you use, does it? It's just a matter of taste (avoid the leading underscore though, that's in the gray zone of names-reserved-to-the-implementation). As long as you're doing it consistently (within the scope of one file at least), any programmer worth speaking of will be able understand it. There are more effective ways to achieve incomprehensibility.
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #62davepermen

Senior Member

• Members
• 1306 posts

Posted 01 June 2006 - 08:50 PM

it should die because it's not a language feature but a coding convention.. thus they can lead to errors a compiler can not detect.

if m_ would be what this-> is today, then it would be fine.. but it isn't.. it's a "shotcut" people made because they didn't understood this->...

and yes, i'm a c# junkie, and no, i don't bother about stuff like this->, this., my., self., etc... but if i had the choise... :D
davepermen.net
-Loving a Person is having the wish to see this Person happy, no matter what that means to yourself.
-No matter what it means to myself....

### #63bramz

Valued Member

• Members
• 189 posts

Posted 01 June 2006 - 10:54 PM

davepermen said:

if m_ would be what this-> is today, then it would be fine.. but it isn't.. it's a "shotcut" people made because they didn't understood this->...

In some sort of funny and ironic way, m_ is what's this-> is today*. If you choose to use this->foo for all your members, then that's fine. However, if you choose to use m_foo, then that's an equally fine coding convention. Being a shortcut implies that people understood what they were shortcutting in the first place =)

* of course, you can't simply go and replace this-> by m_ everywhere, but I didn't need to explain that, did I? ;)
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #64Nick

Senior Member

• Members
• 1227 posts

Posted 01 June 2006 - 11:03 PM

bramz said:

I'd like to know why myself. Over the years, I've used myFoo, m_foo and now I'm using foo_. The latter is my personal favourite, but it really doesn't matter which one you use, does it? It's just a matter of taste (avoid the leading underscore though, that's in the gray zone of names-reserved-to-the-implementation). As long as you're doing it consistently (within the scope of one file at least), any programmer worth speaking of will be able understand it. There are more effective ways to achieve incomprehensibility.
It generally lowers the signal/noise ratio.

It's clearly intended to increase the 'signal' part, by telling us which variables are member variables. And it is sometimes assumed not to touch the 'noise' part. Unfortunately, it doesn't get very close to that goal:
• Most IDE's have powerful coding assistance. If it's really necessary to know whether we're working with a member or not, it often suffices to hover the mouse over the variable. When you don't need to know whether it's a member, or don't need to be reminded of it over and over again, 'm_' is nothing but noise.
• Functions ought to be short. You should be able to see function arguments and local variables, so everything else is a member variable. The only exceptions are globals, but these should be rare, and should use the short scope short name / long scope long name convention. If your application has long functions or more than three globals, consider redesigning, not adding 'm_' to each and every member variable.
• Mathematical variable names are typically short for compactness. For example a Vector class needs only x, y, z. Polluting this by adding 'm_' makes it far harder to read already complicated formulas.
• This brings me to my favorite argument: misinformation. Is every variable without 'm_' definitely not a member variable, and is every variable with 'm_' idefinitely a member variable? In the Vector example we might be tempted omit the 'm_' for readability but then we can't rely on the first assumption any more. And when refactoring we might copy a member variable to a function because it's only used locally, forgetting to remove the 'm_'. Or someone might use 'm_' for a whole different reason. It's all manually managed and to err is human, so we can just never rely on 'm_' being correct information.
• We have a lot more screen real-estate these days. Use it. It's easy to have two columns of code; for example a header file and it's corresponding source file. This way you know which variables are members, and a whole lot more useful information, in a glimpse. No need to duplicate that information by adding noise to the source file.
• It's cryptic. Nobody likes decyphering code, it's hard enough as it is with explicit names. If you have to or if it clarifies things add 'this->' to member variables and 'global' to global variables, but don't invent your own codes. Even if you think they're used widely, they're not.
Note that none of this is addressed personally at anyone using this notation I just tried to give a few main reasons why in my opinion using 'm_' is a bad idea. And the 'm_' could also be any other wart.

### #65Nick

Senior Member

• Members
• 1227 posts

Posted 01 June 2006 - 11:59 PM

bramz said:

I'd like to know why myself. Over the years, I've used myFoo, m_foo and now I'm using foo_. The latter is my personal favourite, but it really doesn't matter which one you use, does it? It's just a matter of taste (avoid the leading underscore though, that's in the gray zone of names-reserved-to-the-implementation). As long as you're doing it consistently (within the scope of one file at least), any programmer worth speaking of will be able understand it. There are more effective ways to achieve incomprehensibility.
And now the personal answer... (You didn't think you could get rid of me that easily, did you?) :p

It's interesting that you've used three 'conventions'. It perfectly illustrates the cryptic-ness and misinformation arguments. First of all 'my' is used in so many contexts that it has practically no meaning. Frankly I've never seen it used to denote member variables. But apparently you realized that too so you switched to 'm_'. It's a tiny bit more commonly used, but while switching you must have had a lot of code using both 'my' and 'm_'. I assume you were the only one reading that code because switching conventions always creates misinformation for others. And finally you settled for adding '_' to the end (I bet you still have 'm_' around). People use that for all sorts of reasons so it's either non-information or misinformation, and definitely cryptic. How much of a convention is it when you've used three different ones, and there are probably several more out there?

And don't take this too personally but do forgive my bluntness: Who do you think you are to consider "any programmer worth speaking of" to fully understand your cryptography (twice revisioned)? If you invent another one tomorrow does that make everyone else a worse programmer? Clearly there's something wrong with using these member variable indications, not with the persons who have to read it.

I do can consider "any programmer worth speaking of" someone who understands 'this->' and 'global' and knows where to look for the exact definition of a variable... So just stop adhering to one 'convention' (out of many), that only applies to specific situations. Instead constantly evaluate the signal/noise ratio by using clear names, being explicit when it helps clarifying the code, and assuming the readers to know the language and nothing more.

### #66SmokingRope

Valued Member

• Members
• 210 posts

Posted 02 June 2006 - 02:21 AM

I had a similar desire to have a local, global and params operators which could be used like this. Each of the keywords would make intellisense pop up the corresponding variables. I've found that by placing the 'm_' in my member variables theres less ambiguity when you have something like:

void MyClass::Function(int p_x)
{
m_x = p_x;
};


You can't guarantee that the 'm_' means member variable but it typicaly ensures that you're not assigning to your parameter or some other name/scoping issue.

### #67Nick

Senior Member

• Members
• 1227 posts

Posted 02 June 2006 - 06:55 AM


void MyClass::Function(int x)

{

this->x = x;

};


'Nuff said.

### #68bramz

Valued Member

• Members
• 189 posts

Posted 02 June 2006 - 09:32 AM

First of all, I've switched styles because I've switched environments. Not as in the IDE kind of environments, but as in the people kind of environments. Nowdays I've got accustomed to the trailing underscore, so that's perhaps why it's my favourite. Yes, in my/our codebase, we have code in both styles. But we don't have both styles in one file. If I go back to the old code to fix bugs or to add new features, I do use the old style. Consistent within at least one file.

If you think m_ or whatever style doesn't add to the signal but only to the noise, then that's fine for me. It's your choice, it's your style. I'm not going to say that what you do is bad or wrong, because it isn't. Personally it takes me more time to figure out wether something is a member or not in your style, than in a style using my, m_ or trailing _. But that's perhaps because I'm not used to it.

This is no less of a style issue than whether using camelStyleNames or underscores_like_stl, whether to start typenames with a capital and variables and functions with a lower case or to start everything with a capital, whether to use tabs or spaces, whether to write int* a or int *a or int * a. I'm sure you have figured out good reasons why to choose one above the other, but frankly, I don't care. It's a matter of personal taste (*). The only thing that is important is to be consistent, unless there's a good reason to make an exception. There are far more important things to put in a "code convention" than this.

(*) There are of course a few things like avoiding leading underscores and double underscores that are more than a matter of taste. Also using allcaps for macro names and nothing but macro names is generally thought of as a good way to avoid creepy name clash surprises.
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #69poita

Senior Member

• Members
• 322 posts

Posted 02 June 2006 - 11:30 AM

I must be missing something here but why do people use m_ anyway? It seems like a pointless waste of time and makes your code look ugly.

Can someone please enlighten me? :-/

### #70juhnu

Valued Member

• Members
• 292 posts

Posted 02 June 2006 - 11:33 AM

Nick said:


void MyClass::Function(int x)

{

this->x = x;

};


'Nuff said.

That's quite error prone and exactly why I would prefer accessing members only this-> (at least optionally)


void MyClass::Function(int X) some_funky_id_here_which_forces_using_this {

this->x = x; //compile time error

}



### #71monjardin

Senior Member

• Members
• 1033 posts

Posted 02 June 2006 - 01:03 PM

poita said:

I must be missing something here but why do people use m_ anyway?

I believe it came from Micro\$oft and they required its use internally. Take a look at the MFC sources for an excellent example of Hungarian notation abuse.
monjardin's JwN Meter (1,2,3,4,5,6):
|----|----|----|----|----|----|----|----|----|----|
*

### #72Nick

Senior Member

• Members
• 1227 posts

Posted 02 June 2006 - 01:51 PM

bramz said:

First of all, I've switched styles because I've switched environments. Not as in the IDE kind of environments, but as in the people kind of environments. Nowdays I've got accustomed to the trailing underscore, so that's perhaps why it's my favourite. Yes, in my/our codebase, we have code in both styles. But we don't have both styles in one file. If I go back to the old code to fix bugs or to add new features, I do use the old style. Consistent within at least one file.
In my opinion that's just plain horrible. It requires you to constantly switch your brain just to keep consistent to the artificial rule. That's probably still slightly manageable with two or three people who know the code base. But what if you have more people on the team, some even preferring their own dialect of Hungarian notation? Besides, if you know the code base, any prefix or postfix becomes insignificant. It's just plain noise.

If you don't use prefixes/postfixes, life's a lot easier. Everybody can understand the code, it's compact without being cryptic. They can use code assistence for correct information, they can read the function's arguments and local variables, and/or they can look at the header files to get all the information at once. And most of all, it's not in the way when you don't need it. If you can't remember a class's members or a function's variables then you really have to consider refactoring things.

Quote

Personally it takes me more time to figure out wether something is a member or not in your style, than in a style using my, m_ or trailing _.
Certainly. But how many times do you really have to know whether a variable is a member? Is it really worth all the hassle to write and read 'm_' and keep things consistent? How much time did you loose writing all that, correcting it, debugging it?

Personally I practically always already know whether a variable is a member or not, just by reading the code. I don't have to be reminded of it every time I use that same variable. The header file is always close and hovering the mouse over variables is handy for the one-time occasions.

Quote

This is no more of a style issue than whether using camelStyleNames or underscores_like_stl, whether to start typenames with a capital and variables and functions with a lower case or to start everything with a capital, whether to use tabs or spaces, whether to write int* a or int *a or int * a. I'm sure you have figured out good reasons why to choose one above the other, but frankly, I don't care. It's a matter of personal taste (*). The only thing that is important is to be consistent, unless there's a good reason to make an exception. There are far more important things to put in a "code convention" than this.
As long as it's C++ and English I'm quite ok with any style as long as it's concise. But it's definitely not all a matter of taste. Some 'habits' create code that is on average harder to read, harder to understand, harder to debug, and/or harder to manage...

### #73Nick

Senior Member

• Members
• 1227 posts

Posted 02 June 2006 - 02:13 PM

juhnu said:

That's quite error prone...
Is it? It's just as error prone as "m_x = x;" as far as I know. It just relies on language features everybody understands, instead of ad hoc rules.

And this is the perfect opportunity to stress the importance of testing. I can write dozens of 'error prone' situations, but with a minimum of testing the errors would instantly be exposed and trivial to fix. So I wouldn't turn clean and verifiably working code into ascii soup just because that could make it less error prone. I'd expect the contrary...

### #74SmokingRope

Valued Member

• Members
• 210 posts

Posted 02 June 2006 - 02:23 PM

Well assuming you've actually got a consistent naming scheme, knowing the scope of a variable helps quite a bit when performing memory management.

You know the 'm_' pointer will be deleted in the destructor. You know 'p_' pointer probably shouldn't be deleted. You know 'l_' pointer needs to be deleted or you're gonna piss somebody off.

### #75monjardin

Senior Member

• Members
• 1033 posts

Posted 02 June 2006 - 06:11 PM

Or you could use a smart pointer and not worry about the scope. :whistle:

I wasn't familiar with that convention, but I believe assuming that a member pointer is released in the destuctor could cause major inconsistancies.

Also, if p shouldn't be deleted then why not pass it as a reference (if it can't be NULL)?
monjardin's JwN Meter (1,2,3,4,5,6):
|----|----|----|----|----|----|----|----|----|----|
*

### #76bramz

Valued Member

• Members
• 189 posts

Posted 02 June 2006 - 07:14 PM

Nick said:

In my opinion that's just plain horrible.

no, that's just plain reality.
hi, i'm a signature viruz, plz set me as your signature and help me spread :)
Bramz' warehouse | LiAR isn't a raytracer

### #77juhnu

Valued Member

• Members
• 292 posts

Posted 03 June 2006 - 03:39 AM

Nick said:

Is it? It's just as error prone as "m_x = x;" as far as I know. It just relies on language features everybody understands, instead of ad hoc rules.

I think you missed the idea here a little bit. "m_x = x" is not an equivalent case. The problem is that this->x = x; won't give you a compile time error in case x is not actually defined in the local scope.

### #78Nick

Senior Member

• Members
• 1227 posts

Posted 03 June 2006 - 08:52 AM

juhnu said:

I think you missed the idea here a little bit. "m_x = x" is not an equivalent case. The problem is that this->x = x; won't give you a compile time error in case x is not actually defined in the local scope.
I know, but why would you want a compile time error there in the first place? If you test your software, which I hope you do, then a bug like this is absolutely trivial to spot and correct. Frankly an experienced programmer doesn't write such trivial bugs any more. There are far more complicated bugs where any kind of notation just doesn't help. It's the same thing with Hungarian notation. How many times does using the wrong type pass testing, and Hungarian effectively prevents it? The only thing that helps in my opinion is to write clear, uncluttered code.

Anyway, I was only replying to the "quite error prone" part of your suggestion. It's error prone but in practice ignorably little, comparable to any other typo that is trivial to correct. So I used it as an argument that 'm_' is of little help. In fact just like Hungarian notation I ignore it when I see it, while using 'this->' isn't part of the variable name so it's not that easily ignored. But I see that this not being part of the variable name is exactly what you're trying to address...

As an extension of C++, your suggestion makes sense. Just like we can specifiy 'const' for a function that doesn't modify any member variables, we could simply specify 'this' for functions where member access has to be explicit. I still don't think it would help much (when already using 'this->' it doesn't increase signal/noise, it's just a one-time trigger for compiler errors, after that it's noise). I'd rather just have elegant code that has been tested. But if it would stop the use of 'm_' so people can use a language/compiler supported notation, I'm all for it. :yes:

### #79Jare

Valued Member

• Members
• 247 posts

Posted 03 June 2006 - 10:56 AM

Nick said:

I know, but why would you want a compile time error there in the first place? If you test your software, which I hope you do, then a bug like this is absolutely trivial to spot and correct. Frankly an experienced programmer doesn't write such trivial bugs any more.
Sorry if I sound condescending, but there's a point in religious debates where everyone needs to let go.

### #80Nick

Senior Member

• Members
• 1227 posts

Posted 03 June 2006 - 12:11 PM

Jare said:

Sorry if I sound condescending, but there's a point in religious debates where everyone needs to let go.
I'm sorry but it's not a religious debate. There are real-world technical arguments pro and against the use of 'm_'. Everybody is free to make his own conclusions, I just gave some extra arguments in case some people missed them.

And if it were a religious debate, then yes, there's a point where everyone needs to let go. I acknowledge the advantages of 'm_', I just hope everybody acknowledges its disadvantages as well. It's impossible to have a healthy debate without understanding each other's arguments. Nobody comes to these forums to hear himself speak.

It's just that in my personal opinion the disadvantages (still) outweigh the advantages. That's all. I'm not trying to 'convert' anyone, just give a complete list of arguments. Heck, I'd love to hear more arguments of its advantages, maybe I'm missing some...

#### 1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users