initialization in initializer list using copy constuctor?!?

[Alexander Stippler]

Hi,

I wonder about the behaviour of como and icc on some very simple program. I
thought initializing members of classes, which are of class type, would be
'direct initialized' (as the standard says). But in the example below the
copy
constructor of Vec is executed when initializing the Ref object. Is this
standard conform? Doesn't it result in bad performance?

#include <iostream>

using namespace std;

class Vec
{
public:
Vec() { cout << "constructor" << endl;}
Vec(const Vec &v) { cout << "copy constructor" << endl; }
};

class Ref
{
public:
Ref() : vec_(Vec()) { }

private:
Vec vec_;
};

int
main()
{
Ref ref;

return 0;
}


regards,
alex

 

[Leor Zolman]

Hi,

I wonder about the behaviour of como and icc on some very simple program. I
thought initializing members of classes, which are of class type, would be
'direct initialized' (as the standard says). But in the example below the
copy
constructor of Vec is executed when initializing the Ref object. Is this
standard conform?

You're perhaps confusing "direct initialization" with "default
initialization". A line of code that invokes either of your two
constructors "directly" is "direct initialization. For example,

Vec v; // default initialization
Vec v(v2); // direct initialization
Vec v = v2; // not direct initialization, but still initialization
v = v2; // not initialization at all

Doesn't it result in bad performance?

Not at all; you have to do what you have to do!

#include <iostream>

using namespace std;

class Vec
{
public:
Vec() { cout << "constructor" << endl;}
Vec(const Vec &v) { cout << "copy constructor" << endl; }
};

class Ref
{
public:
Ref() : vec_(Vec()) { }

If you had omitted the base initializer totally, or used it but omitted the
"Vec()" from inside the parens, it would have called the default
constructor.
-leor

 

[Alexander Stippler]

class Ref

If you had omitted the base initializer totally, or used it but omitted
the "Vec()" from inside the parens, it would have called the default
constructor.
-leor

Consider Vec() replaced by e.g Vec(a,b,c). Why is it necessary to (1) create
Vec(a,b,c) and then (2) copy it into vec_ using the copy constructor?
Shouldn't it just directly initialize the vec_ object?
By the way, gcc does exactly this, como and icc not. This situation is IMO
comparable to copy constructors given a temporary class object, e.g.

Vec v(Vec());

would result in the direct initialization of v with the temporary Vec(), not
first create it and then copy it into v. Where is the difference?

 

[Leor Zolman]

First of all, sorry, I said "base initializer" when of course it is a
"member" initializer. No idea why my brain did that (not enough coffee yet,
I guess....)

Consider Vec() replaced by e.g Vec(a,b,c). Why is it necessary to (1) create
Vec(a,b,c) and then (2) copy it into vec_ using the copy constructor?

Okay, several issues here. First, are you aware that you do not need, in
/either/ case, to use the "temporary" syntax? IOW, you can either omit the
member initializer completely (which invokes vec_'s default constructor)
or, to pass the ctor args, use:
Ref() : vec_(a,b,c) {}

This results in the best performance imaginable. The fact that some
compilers take your version and optimize away the temporaries, but others
don't, is a QOI issue...and I wouldn't even say the ones that do not suffer
from lower QOI, but rather than their implementors chose to focus on other
features (perhaps "export" in the case of EDG, the authors of the Comeau
front-end) that were likely to make more of a difference to more folks.

Shouldn't it just directly initialize the vec_ object?
By the way, gcc does exactly this, como and icc not. This situation is IMO
comparable to copy constructors given a temporary class object, e.g.

Vec v(Vec());

would result in the direct initialization of v with the temporary Vec(), not
first create it and then copy it into v. Where is the difference?

QOI.
-leor