Initialization: = or () ?

[Mats Weber]

I can write

int x(5);

or

int x = 5;

Are both the same ? Is either form preferable for some reason I don't
see ?

 

[Gianni Mariani]

I can write

int x(5);

or

int x = 5;

Are both the same ?

Yes, they are the same.

Is either form preferable for some reason I don't

see ?

No really, but you're forced to use the T() syntax for initialization so
being consistent and using :

int x(5);

.... probably has a slight readability advantage.

 

[JKop]

Mats Weber posted:

I can write

int x(5);

or

int x = 5;

Are both the same ? Is either form preferable for some reason I don't
see ?

Would I be right in saying the following:


When you have a class that has a constructor, copy constructor, all sorts of
operators, and you do the following:

SuperClass super_class(57U);


You're calling the

SuperClass(unsigned int);

constructor.



But...

when you write:


SuperClass super_class = 57U;


Are you not then calling the:

SuperClass(void);

constructor, and then calling

operator=(int)

??


-JKop

 

[Rolf Magnus]

Mats Weber posted:



Would I be right in saying the following:


When you have a class that has a constructor, copy constructor, all
sorts of operators, and you do the following:

SuperClass super_class(57U);


You're calling the

SuperClass(unsigned int);

constructor.



But...

when you write:


SuperClass super_class = 57U;


Are you not then calling the:

SuperClass(void);

constructor, and then calling

operator=(int)

??

Nope. You're calling the SuperClass(unsigned int) constructor, followed
by SuperClass's copy constructor. However, a decent compiler will
optimize the copy away, effectively doing the same as in the first code
example. But there is still a difference: Even if the compiler doesn't
use the copy constructor, it still requires a copy constructor to be
existing and accessible.

 

[Wouter de Kort]

I can write

int x(5);

or

int x = 5;

Are both the same ? Is either form preferable for some reason I don't
see ?

You use x(5) also when initialising class members.
You need to use x(5) when x is as const class member because you can't set
it with a = operator.

 

[Rolf Magnus]

You use x(5) also when initialising class members.
You need to use x(5) when x is as const class member because you can't
set it with a = operator.

"MyClass x = 3;" does _not_ use operator=!

 

[Jeff Flinn]

Yes, they are the same.

Not if int is replace by T*.

T* ptr = aTptr; // ok

T* prt( aTPtr ); // error

I'm not sure but I think the latter is being added to the standard as valid.

Jeff Flinn

 

[Steve]

Not if int is replace by T*.

T* ptr = aTptr; // ok

T* prt( aTPtr ); // error

I'm not sure but I think the latter is being added to the standard as valid.

It's accepted by Metrowerks Codewarrior 9.2, but I don't have a copy of the
standard to hand.

I always thought it was valid?


Steve.

 

[Peter Koch Larsen]

Not if int is replace by T*.

This is rubbish - it is.

T* ptr = aTptr; // ok

T* prt( aTPtr ); // error

No - not an error, just plain initialization.

I'm not sure but I think the latter is being added to the standard as valid.

Jeff Flinn

/Peter

 

[Peter Koch Larsen]

I can write

int x(5);

or

int x = 5;

Are both the same ? Is either form preferable for some reason I don't
see ?

The first style is the best. You can use it for all types. The second style
requires the class to have a copy constructor.
Why I often use the second style? Visual C++ 6.0 does not always understand
the "correct" form.

/Peter

 

[Andrey Tarasevich]

I can write

int x(5);

or

int x = 5;

Are both the same ?

For type 'int' - yes. In general case - no. It depends on actual types
involved in initialization.

For example, if the initializer and the object being initialized have
different types (the former - T, the latter - U), then the compiler will
make an attempt to convert the initializer from type T to type U. If
this process involves a conversion construction of the initializer,
which happens to be declared as 'explicit', the second form will fail,
while the first form will still compile:

std::auto_ptr<int> p1 = new int; // ERROR
std::auto_ptr<int> p2(new int); // OK

For another example, if T is different from U and if the conversion can
only be performed by using some intermediate type X in the following
two-step manner

1. convert T to X using T's conversion operator
2. convert X to U using U's conversion constructor

then the second form will fail, while the first form will still compile:

struct T { operator void*() const; };
struct U { U(void*); };

T t;
U u1 = t; // ERROR
U u2(t); // OK

Is either form preferable for some reason I don't
see ?

In situations when you actually have a choice use whatever looks better
to your eyes.

 

[Karl Heinz Buchegger]

[snip]
But...

when you write:

SuperClass super_class = 57U;

Are you not then calling the:

SuperClass(void);

constructor, and then calling

operator=(int)

No. The above constructs a new object super_class. For
construction there is always a constructor used, never
an operator=.

constructor: create new object and initialize it
operator= : take already existing object and give it a new value