# Do I have to break this java habit when using C++?

## Recommended Posts

eedok    982
Well I have a habit in java, which is using the same variable names as arguments to a function/contructor as the class has(sorry if I'm not saying it right), here's a simple example of what I'm trying to do:
class Date
{
int d;
public:
Date (int d);
};

int main()
{
Date  date = Date(1);
return 0;
}

Date::Date(int d)
{
this.d=d;
}


what I'm trying to do is set the member of Date called d to the d passed to the constructor, this gives me the error: date.cpp:16: error: request for member 'd' in 'this', which is of non-class type 'Date* const' Is there a way to do this, or will I have to completely break this habit?

SiCrane    11839
this->d = d;

##### Share on other sites
TDragon    679
You would use "this->d" instead of "this.d"; but it's still a trifle unclear to the casual reader what you mean. It's generally a good idea to use different names for arguments than for member variables for the sake of clarity.

EDIT: Beaten to the fruit-flavored alcoholic beverage, as usual.

##### Share on other sites
FlyingDemon    112
yes

##### Share on other sites
Enigma    1410
Of course when using anything other than a builtin type you're better off using the initialiser list:
class Date{		int d;	public:		Date(int d);};int main(){	Date date(1);	return 0;}Date::Date(int d)	:	d(d){}

Enigma

##### Share on other sites
Quote:
 Original post by TDragonEDIT: Beaten to the fruit-flavored alcoholic beverage, as usual.

"SiCrane" is a fruity beverage?? Google doesn't say anything.

Feeble attempt to justify this post: As you can probably tell from the ->, in C++ this is a pointer to the object instead of a reference as is the case in Java.

##### Share on other sites
jflanglois    1020
Quote:
Quote:
 Original post by TDragonEDIT: Beaten to the fruit-flavored alcoholic beverage, as usual.

"SiCrane" is a fruity beverage?? Google doesn't say anything.

I understood it as a general state of affairs.

jfl.

##### Share on other sites
You will have no problem doing this in Java. I do this in C# all of the time, and Java will be no different.

##### Share on other sites
Vexorian    152
Well it is a bad habit after all.

##### Share on other sites
TDragon    679
punch
n.
A beverage of fruit juices and sometimes a soft drink or carbonated water, often spiced and mixed with a wine or liquor base.

I was beaten to the punch.

##### Share on other sites
iMalc    2466
Just follow what Enigma says and use initialiser lists. It's the preferred way to do this anyway. It's also perfectly fine to use the same paramter name as the member varaible in when using initialiser lists, and you don't have to write 'this' anywhere to do it:
Date::Date(int d) : d(d) {}

##### Share on other sites
scgrn    168
Why exactly is this a bad habit? I do this all the time and see no problems with it.

##### Share on other sites
Quote:
 Original post by TDragonpunchn. A beverage of fruit juices and sometimes a soft drink or carbonated water, often spiced and mixed with a wine or liquor base.I was beaten to the punch.

Ah. [grin]

Quote:
 Original post by scgrnWhy exactly is this a bad habit? I do this all the time and see no problems with it.

It's not. People just have different preferences. Personally I prefix my member variables with m_ but if you want to use this-> that's fine. (Although IMO it's a bit lengthy)

##### Share on other sites
Guest Anonymous Poster
Quote:
 Original post by scgrnWhy exactly is this a bad habit? I do this all the time and see no problems with it.

Usually, relying on scoping rules that not everyone is familiar with is a bad idea. Similar to doing tricks with operator precedence.

##### Share on other sites
Telastyn    3777
Quote:
 Original post by scgrnWhy exactly is this a bad habit? I do this all the time and see no problems with it.

Because it increases the chances of you just using d [and not assigning it], and then wondering later why your class doesn't work right.

##### Share on other sites
Shannon Barber    1681
Quote:
 Original post by scgrnWhy exactly is this a bad habit? I do this all the time and see no problems with it.

I use it for ctor's in particular. vector(x,y,z):x(x),y(y),z(z){} makes sense to me.

##### Share on other sites
eedok    982
Quote:
Quote:
 Original post by TDragonpunchn. A beverage of fruit juices and sometimes a soft drink or carbonated water, often spiced and mixed with a wine or liquor base.I was beaten to the punch.

Ah. [grin]

Quote:
 Original post by scgrnWhy exactly is this a bad habit? I do this all the time and see no problems with it.

It's not. People just have different preferences. Personally I prefix my member variables with m_ but if you want to use this-> that's fine. (Although IMO it's a bit lengthy)

Anyhow thanks all, looks like I'll have to look more into initializer lists

##### Share on other sites
Promit    13246
Quote:
 Original post by eedokisn't prefixing a bad thing?

Type based prefixing is a terrible thing. Scope based prefixing, however, is an entirely different matter, however, and remains in the .NET Naming Guidelines. Specifically, private and protected members of a class should be prefixed with a single underscore, e.g. int _privateData;. I use the same convention myself, although with m_ for largely historical (and now consistency) reasons.

##### Share on other sites
Nitage    1107
It's a bad habit because he should be using initializer lists. If he isn't he'll be paying for object construction twice (not for the built-ins, but for more complex types).

##### Share on other sites
Thevenin    270
Quote:
Original post by Promit
Quote:
 Original post by eedokisn't prefixing a bad thing?

Type based prefixing is a terrible thing. Scope based prefixing, however, is an entirely different matter,

Prefixs (Scope and type) in my procedural-C applications have done wonders for my coding styles. I suggest viewing it as a preference.

##### Share on other sites
MaulingMonkey    1730
Quote:
Original post by Shannon Barber
Quote:
 Original post by scgrnWhy exactly is this a bad habit? I do this all the time and see no problems with it.

I use it for ctor's in particular. vector(x,y,z):x(x),y(y),z(z){} makes sense to me.

/Sign

For non constructors, I tend to prefix the argument name. E.g.:

std::vector::resize( size_t new_size )

##### Share on other sites
Arild Fines    968
Quote:
 Original post by PromitScope based prefixing, however, is an entirely different matter, however, and remains in the .NET Naming Guidelines. Specifically, private and protected members of a class should be prefixed with a single underscore, e.g. int _privateData;.

Can you point out where in the guidelines it says that?

##### Share on other sites
Promit    13246
Quote:
Original post by Arild Fines
Quote:
 Original post by PromitScope based prefixing, however, is an entirely different matter, however, and remains in the .NET Naming Guidelines. Specifically, private and protected members of a class should be prefixed with a single underscore, e.g. int _privateData;.

Can you point out where in the guidelines it says that?

No, and actually on a second pass I might be mistaken. This page mentions it (and muer or Washu or somebody told me), but it sounds like they made some modifications to the original guidelines. I can't find any guidelines at all in the .NET docs for naming member fields.

##### Share on other sites
evanofsky    2913
I hate having double names (this.d verses d), and I hate initializer lists. *quickly yanks neck back in*

##### Share on other sites
Promit    13246
Quote:
 Original post by evanofskyand I hate initializer lists.

Hate or not, they're the most efficient way of initializing variables (as if it matters), and you will sometimes be forced to use initializer lists, like when initializing const members and references.