Sign in to follow this  
eedok

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?

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by TDragon
EDIT: 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 this post


Link to post
Share on other sites
jflanglois    1020
Quote:
Original post by load_bitmap_file
Quote:
Original post by TDragon
EDIT: 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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by TDragon
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.


Ah. [grin]

Quote:
Original post by scgrn
Why 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 this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
Quote:
Original post by scgrn
Why 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 this post


Link to post
Share on other sites
Telastyn    3777
Quote:
Original post by scgrn
Why 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 this post


Link to post
Share on other sites
eedok    982
Quote:
Original post by load_bitmap_file
Quote:
Original post by TDragon
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.


Ah. [grin]

Quote:
Original post by scgrn
Why 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)

isn't prefixing a bad thing?

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

Share this post


Link to post
Share on other sites
Promit    13246
Quote:
Original post by eedok
isn'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 this post


Link to post
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 this post


Link to post
Share on other sites
Thevenin    270
Quote:
Original post by Promit
Quote:
Original post by eedok
isn'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 this post


Link to post
Share on other sites
MaulingMonkey    1730
Quote:
Original post by Shannon Barber
Quote:
Original post by scgrn
Why 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 this post


Link to post
Share on other sites
Arild Fines    968
Quote:
Original post by Promit
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;.

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

Share this post


Link to post
Share on other sites
Promit    13246
Quote:
Original post by Arild Fines
Quote:
Original post by Promit
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;.

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 this post


Link to post
Share on other sites
Promit    13246
Quote:
Original post by evanofsky
and 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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this