Thread: unfamiliar syntax

Its an initializer list.

It basically calls the constructor of those items and sets them to those values

The initialization list can be more efficient.

It is also useful if you need to call a member whose constructor has a parameter.

Code:

class SomeClass
{
public:
    SomeClass(int value) : mValue(value) { }
private
    int mValue;
};

class AnotherClass
{
public:
    AnotheClass(int value) : mContainedClass(value) { }
private:
    SomeClass mContainedClass;
};

Originally Posted by DirkMaas

Any function defined within a class body is automatically inline.

But bear in mind that it's entirely up to the compiler which functions are inlined and which are not. The compiler uses many different indicators to decide whether to inline a function or not, and one indicator is whether the user declared the function as an inline function (which is implied if the function is declared within the class definition). Other factors are:

• How large is the function, how many times is it called.
  
  Large functions that are called only once can be inlined, but not large functions that are called several times, whilst small functions can be allowed to inline even if they are called many times.
• The structure of the function itself.
  
  Functions that are recursive or contain try/catch are usually not possible to inline. Functions that have their address taken are usually not inlined.
  Functions that are virtual can not be inlined except where the compiler knows some other way exactly which variant of the function is supposed to be called.
• Optimisation levels and other compiler settings.
  
  There is almost always a flag to say "do not inline functions" or "inline only functions that are explicitly marked inline".
  Many compilers also have settings to adjust the inlining - e.g. how many bytes copies of a function is allowed to take up, or number of instructions an inlined function is allowed to use up, number of times it can be called before it gets out-of-lined.

There are other factors that are even more arbitrary (e.g. the compiler simply can't "figure out" how to inline a particular function because it can't generate correct code), but the above are the common factors that occur in almost all compilers.

Note also that excessive inlining can lead to slower execution speed. It was found when testing large-scale system benchmarks that "keep the code as small as possible and don't inline' gave better performance on the Linux kernel than to inline functions all over the place. The main reason is that the inlined copies of functions are no longer shared between different paths, so if we have, say, a helper function that is called from open, read, write and close [say a function that checks that a handle is valid], and we call open, read, [modify some of the file content], write and close in sequence, each copy of the helper function needs to be read into the cache from the main memory. If we do not inline this function, it gets loaded when we call open, and then it's already there when we call read. Not only that, but the four copies of the common function throws out some other bits of code from the cache, which means that when that code needs to be executed, it is read from the slower main memory again - slowing down the system again.

--
Mats

Originally Posted by R.Stiltskin

I think I understand the distinction between declare and define wrt primitive types, but I'm not so sure when it comes to classes and functions. Can you help clarify that for me?

Perhaps examples will help. This is a function declaration that is not also a function definition:

Code:

void foo();

Whereas this is a function definition:

Code:

void foo() {}

This is a class declaration that is not also a class definition:

Code:

class X;

Whereas this is a class definition:

Code:

class X
{
public:
    void foo();
private:
    int bar;
};

Originally Posted by R.Stiltskin

Also, bearing in mind that the original question related specifically to the syntax of a constructor, what's the takeaway message here? Does it actually matter whether member variables are initialized in an initializer list or in the constructor body?

Yes, it may matter:

• Assignment in the constructor body may mean more work since a member variable would be default constructed and then assigned to.
• It may not be possible to assign to the member variable in the constructor body, e.g., for const and reference member variables, or those of types without default constructors.

Originally Posted by R.Stiltskin

I don't think I've ever come across reference member variables before.

Eh, I just realised an inaccuracy: in the case of non-const reference member variables, it would certainly be possible to assign to them in the constructor body, but that would obviously not be the same as initialising the reference.

Also yielding a compile error since references must be initialized. So they must be provided in the initializer list, whether or not they're assigned or read from in the body.