Hey everyone,

Got 2 questions here that i'm hoping will be answered.

Say i have 2 variables

int iValue;
int iValueArray[300];

and later on init. them in the constructor

Banana::Banana(): 
    ival(0),
    ivalArray()
{}
  1. What would the ivalArray() indicate? Would it be the same as initializing every element to null/empty? Or does it actually mean something else such as every element is init. to 0?

  2. I've always initialized variables in constructors like

    Banana::Banana()
    {
    iValue = 0;
    ...
    }

is there a difference between initializing after a colon and before the {} and initializing inside the {}. I understand that variables can be init. through 3 different ways so does is this just a matter of syntax preference in terms of initializing variables in constructors?

int someVal = 0;
int someVal (0);
int someVal {0};

You have posted this 3 times

Sorry about reposting. Been having internet trouble and wasn't sure if the button was responding.

What would the ivalArray() indicate?

It indicates that when a Banana object is created, the ivalArray data member will be value-initialized. This is standard terminology and it boils down to meaning that it gets initialized to a default value. For all primitive types (int, double, any pointer type, etc..), the default value is zero. And this applies to arrays too, i.e., value-initializing an array will value-initialize all of its elements.

One important thing to know is that if you don't put this statement, ivalArray(), in the constructor's initialization list (which is the technical term for that place between the : and the {), then the array will be left uninitialized, as in this:

Banana::Banana() : 
    ival(0), ivalArray()
{
  // at this point, ivalArray contains all 0
}

// But...

Banana::Banana() : 
    ival(0)
{
  // at this point, ivalArray contains GARBAGE!
}

Would it be the same as initializing every element to null/empty?

Yes. For an array of primitive types (or more in standard terminology, trivial types), this will initialize all elements of the array to zero / null. In case you have an array of objects of some non-trivial class type, then this will call the default constructor on all elements of the array, i.e., they are all default-constructed.

is there a difference between initializing after a colon and before the {} and initializing inside the {}.

Yes, there is (ignoring the possibility that the compiler will optimize things out). Basically, just think about the initialization list as the place where the data members are constructed, and the body of the constructor as simply some code that executes right after.

So, if you look at normal code like this:

int a(1);

You are creating an integer called a which is constructed (or initialized) with the value 1.

If you have instead, the following:

int a;
a = 1;

You are creating an integer called a which is left uninitialized, and then you assign to it the value 1.

The difference between initializing data members in the initialization list versus in the constructor's body, is the same as the difference between those two pieces of code. And I mean, it is literally the same difference, in every way.

So, if you have primitive types, like int, then the difference isn't really big (and probably will be optimized away, anyway) because you only momentarily leave an uninitialized segment of memory that you immediately initialize after. However, it is still considered good style to initialize everything in the initialization list, because it's just more fool-proof. And this recommendation applies just the same for preferring to use int a = 1; or int a(1); instead of the alternative above.

But, if you have data members that are objects of non-trivial class types, then the difference can be significant. For many complicated classes, doing a default-construction followed by an assignment to initialize it can be significantly more work than just constructing it in the desired initial state directly in the initialization list.

So, in short, try to always initialize all your data members in the initialization list. The body of the constructor should only really be used for more complicated initializations (like an algorithm or set of function calls).

I understand that variables can be init. through 3 different ways so does is this just a matter of syntax preference in terms of initializing variables in constructors?

No. Or not really. The last two, with the braces or the parentheses, behave exactly the same (they are called, in technical terms, a direct-initialization). The first one, with the = sign (which is called a copy-initialization), differs in one important way, which has to do with conversions. If the type of what's on the right of the equal sign does not match the type declared for the variable, then there needs to be an implicit conversion available from one to the other. For the other two cases, any conversion available will do, including an explicit conversion operator.

This might be too technical for you to handle at this stage. What it boils down to is that if the first version compiles, then it's the same as the other two. It's just that there are some cases where the first one will not compile while the other two will. By the time you learn about implicit versus explicit conversion operators, this will all become clear anyway, so don't worry about it for now.

There is also a small difference between using parentheses versus curly braces. They both have their own "gotchas", i.e., things that will be misinterpreted and/or fail to compile for some stupid accidental reason. They introduced the curly braces to solve the gotchas when using parentheses, but the curly braces also have their own gotchas, so.. whatever.. but this almost never happens in real life, but just know that if one fails to compile for some seemingly unexplanable reason, just try the other syntax.

Thank you very much for the detailed response. Really cleared things up for me!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.