constructors

[EscapeCharacter]

ok say i had class foo

class foo{
public:
foo();
void SetX(int);
private:
int x;
};


would it be better(more OO) to set the value of x in the constructor by just using a normal assignment i.e.

foo::foo(){
x = 0;
}


or to set it using the SetX method i.e.

foo::foo(){
this->SetX(0);
}

[Bradmont]

I don't see why it would make much difference.

BTW, you don't need to use "this->". In C++, you can just call the method like this:

SetX(0);

and it will be assumed that it's referring to the current instance.

[EscapeCharacter]

Originally posted by Bradmont
I don't see why it would make much difference.

BTW, you don't need to use "this->". In C++, you can just call the method like this:

SetX(0);

and it will be assumed that it's referring to the current instance.

i know i just got in the habit of using this->. i thought calling the method would be inefficient since i would be calling the function then calling the return statement, on the other hand explicitly saying x = 0 would be faster since no functions would be called. just asking :)

[CheeseLick]

Another way to initialize a member variable is by doing something like this,


foo::foo(void) : x(0)
{
}

[kmj]

Actually, I'm told that Cheeselick's way (using an initiialization list) is the best way to do it, because it is guaranteed to be atomic (ie, the process won't get switched out while the initialization list is processed; thus preventing race conditions) There is no such guarantee for the body of the constructor.

[EscapeCharacter]

well if thats the best way then i think ill give it a try, thanks for responding everyone

[sans-hubris]

Sorry to be pedantic, but don't use the this pointer in that manner. Use it only when you must (i.e. when you need to pass a pointer to a function or other object.) Using it in that manner will muck up your code pretty quickly.

The best thing to do is to come up with a proper naming convention that will help you distinguish member functions and variables from other functions and variables.

[kmj]

I disagree with you sans-hubris. You seem to be stating your personal opinion. Using the this-> pointer seems to be a perfectly valid thing to do (though I do recommend either doing always or only when necessary, or at least following a specific standard as to when you use it). Using this always will surely be a good way of differentating member data/functions/etc. from other such things. So unless there's something other than style at stake here, I really think EscapeCharacter (or the company/school/whoever he may code for) is free to choose his own style standard.

[LonelyKing]

I'd actually have to agree with sans-hubris here... As long as you name your functions even slightly intelligently, you should never have a problem with differentiating between functions...

[EscapeCharacter]

to clearify i didnt really have a problem understanding the difference between member functions and other functions i was just trying to get a feel for what the *standard* is out in the real world as i have yet to get a job. im just trying to prepare myself for whats ahead and dont want people looking over my code years down the line and having a hard time figuring out why i did something a certain way, nothing more than that. well that and im still trying to develop a personal coding style.

[ThurberMingus]

Having your own style is good, as long as it is not at the cost of efficiency/maintainability/portability/etc.

The initialization list is the proper way to initialize your data members, as far as I know.

[strags]

Originally posted by kmj
Actually, I'm told that Cheeselick's way (using an initiialization list) is the best way to do it, because it is guaranteed to be atomic (ie, the process won't get switched out while the initialization list is processed; thus preventing race conditions) There is no such guarantee for the body of the constructor.

To my knowledge, there's nothing atomic about the initialization list. If you need a critical section, then put one in. This is only an issue if you have several threads (not processes) running concurrently, of course.

Anyway, I would suggest that the second method is better. Why? Well, part of the reason for having SetX instead of permitting an application to have direct access to the member variable is that you may want to change the way in which x is stored at some point in the future. Data encapsulation, folks. Now, if you do make a change at some point in the future, you only have to change the SetX method itself. If you had gone with the first approach, you would have to modify the initialisation of x in the constructor as well.

In this case, it doesn't much matter, since x is a nice simple integer. My argument may be overkill in this case - but I still maintain that it's a good habit to get into.

[stuka]

OK, here's my $.02 - kmj's right, in that all initialization in an initialization list IS guaranteed (my guess is that it's a standards requirement, but I'd have to do some hardcore huntin' to be sure). Any simple initialization should be done in that list. More complex initialization (memory allocation, etc.) should be done in the body of the constructor. To handle strags' comment, yeah, you'd have to do it twice, but changing data representation is a relatively major shift for a class, and the move from initialization list to ctor body is not that difficult, and if your ctor accepts an argument there anyway (which it generally does, unless you're setting the value to NULL or some other 'uninitialized' flag or default value) you could just CALL your SetX function, swapping that call for the initialization list.