Initialising a class with data or something

Started by
9 comments, last by Fruny 18 years, 10 months ago
Hello! I'm creating a joystick class (I'm putting it in a class rather than just reading the joystick directly largely because it will read the arrow keys too and treat them the same as joystick). I'm using DevC and Allegro, but this is really just a general C++ question. If I want to initialise the member variables when the instance is created, do I do this: Joystick(); Joystick::Joystick() { m_ArrowLeft=false; m_ArrowRight=false; m_Fire=false; } or this: Joystick(bool left=false, bool right=false, bool fire=false); Joystick::Joystick(bool left, bool right, bool fire): m_ArrowLeft(left), m_ArrowRight(right), m_Fire=false(fire) { } Am I right in thinking that the second way would allow me to declare the instance with values, and that if I don't supply values the default values will be used? So I could declare it like this and it would be like the fire button is being pressed: Joystick myJoystick(false, false, true); Not that there would be any point in doing that but I want to keep things neat. In this case I just want everything set to false. What's the neatest way to do that? Thanks!
Advertisement
Quote:Original post by joebarnslondon
Am I right in thinking that the second way would allow me to declare the instance with values, and that if I don't supply values the default values will be used?


Yes, note always prefer constructor initializer lists your first version doesn't do initialization thats assignment.
The reader is entreated to note the ratings of those who respond ;)

The first way will work; you can provide a no-argument constructor and then overload it as illustrated. However, this loses flexibility for no real gain; the version with default arguments will also provide a "default" (technically, no-argument; the "default" constructor is the one provided when there is no no-arg constructor given by the coder) constructor, since all the arguments are defaulted away. It also implicitly defines 1-arg and 2-arg constructors :)

Joystick(bool left=false, bool right=false, bool fire=false);Joystick::Joystick(bool left, bool right, bool fire):m_ArrowLeft(left),m_ArrowRight(right),m_Fire=false(fire){}// Used like:Joystick a; // left = false, right = false, fire = falseJoystick b(true); // left = true, right = false, fire = falseJoystick c(false, true); // left = false, right = true; fire = falseJoystick d(true, false, true); // left = true, right = false; fire = true


In any case, please prefer the initializer list. In the case of a constructor whose work can be done entirely by the initializer list (fairly common), I also advocate putting the definition in-line in the class declaration; in that situation the extra typing and separation of code doesn't really gain you much information hiding :)
OK, but if, as in the case of this joystick class, I always want to just set them all to zero and won't ever need to create the class with any values other than false, isn't it neater to just do the first way:

Joystick();

Joystick::Joystick()
{
m_ArrowLeft=false;
m_ArrowRight=false;
m_Fire=false;
}

I just mean neater in that it's completely clear that this class is designed to always start with these exact arguments. Or am I missing something here?

Well if you are just setting the vars to a start value of false, it's pretty the same as if you set everything to NULL or 0 when initing any other class, so if you're completly sure that you're values have to be false when initing the class then there is no use to create constructor where you put the values in. So just use this:

Joystick::Joystick()
{
m_ArrowLeft=false;
m_ArrowRight=false;
m_Fire=false;
}



cheers,
marcel
Quote:Original post by MMarcel
So just use this:

Joystick::Joystick()
{
m_ArrowLeft=false;
m_ArrowRight=false;
m_Fire=false;
}


What are those assignments for? The class has a constructor, so it's not a POD type, which means that its members will get default-initialized. Thus

Joystick::Joystick() {}

would have the same end-result, and you wouldn't have to worry about whether the compiler is going to generate those redundant assignments or not.

And even if you wanted to explicitely set them to false, both snk_kid and Zahlman have already established that the form
Joystick::Joystick() :   m_ArrowLeft(false),   m_ArrowRight(false),   m_Fire(false){}

is superior, since initializer lists do an initialization instead of a post-initialization assigmnent.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
So, what if I don't have a constructor at all (ie let the compiler generate one)?

Will the values just be random? Or will they automatically be set to FALSE?

I mean, if you have an int, and you don't set it to zero you get some random value don't you?
Quote:Original post by joebarnslondon
Or am I missing something here?


I think you are, your to going end up redundantly writing two constructors, one default and one non-default, when you can just combine the two with default arguments. When you give a constructor parameters all with default arguments it becomes a default constructor.

As i and others already mentioned assignment != initialization. Even when you don't explicit write constructor initialize lists one its still implicitly defined so your first version just redundantly initializes members then you do assignment when you could just cut the middle man and directly initialize them with what-ever values.
Quote:Original post by joebarnslondon
So, what if I don't have a constructor at all (ie let the compiler generate one)?


Having a user-defined constructor definitely makes your type a non-POD ("Plain Old Data") type. Same with having virtual member functions, private members, non-POD members...

Quote:Will the values just be random? Or will they automatically be set to FALSE?


If your type is a POD-type then instances won't be initialized at all and their member variables will have random initial values. If it is a non-POD type, the instances will be default initialized, so your members will be false (there is no such thing as FALSE in C++).

Quote:I mean, if you have an int, and you don't set it to zero you get some random value don't you?


Yes, int is a POD-type.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." — Brian W. Kernighan
Quote:Original post by Fruny
Having a user-defined constructor definitely makes your type a non-POD


I'm pretty sure POD-struct/class types can have user-declared constructors but cannot have user-declared copy constructor, user-declared assignment operator and user-declared destructor + the rest of the stuff.

I think the no user-declared constructors of any form, including no user-declared assignment operator, and user-declared destructor + the rest of the stuff would be an Aggregate type (further restriction on POD-struct/class types).

This topic is closed to new replies.

Advertisement