Default constructor

[Vinodh Kumar]

class A
{
int myIntVal;
};

int main()
{
A a;
return 0;
}

The value of *myIntVal* in *a* object is indetereminate.
The default constructor synthesized by the compiler, does not invoke the
constructor for the *int*.
Why?

 

[Andrey Tarasevich]

class A
{
int myIntVal;
};

int main()
{
A a;
return 0;
}

The value of *myIntVal* in *a* object is indetereminate.
The default constructor synthesized by the compiler, does not invoke the
constructor for the *int*.
Why?

Type 'int' is not a class type and it has no constructor. There's
nothing to invoke.

If a subobject of POD type is not mentioned in constructor's member
initializer list, it is not initialized at all. See 12.6.2/4 in the
language standard.

 

[David White]

Does *int* has no non-trivial default constructor?

There can be at most one default constructor. It's the one that's called by
default. On some occasions to initialize an int where it pops into existence
is just a waste of time, e.g.,

int k;
if(some_condition)
{ do_something(); k = 2;
}
else
{ do_something_else(); k = 3;
}

To give k an initial value here might be considered good practice, but it
shouldn't be mandatory because it just wastes time and space. I suppose it
is for this reason, and perhaps for compatibility with C as well, that there
is no default constructor for int. The same goes for an int class member.
It's up to you to initialize it explicitly if you want it to have a specific
value.

However, int does have a non-default constructor that takes no arguments:

int k = int(); // = 0

DW

 

[Rolf Magnus]

OK.

Does *int* has no non-trivial default constructor?

Type 'int' is not a class type and it has no constructor (copy/paste
from above). No trivial or non-tivial constructor, no default
constructor, not any constructor at all. A concept of constructors only
exists for class types in C++.

 

[Mike Wahler]

class A
{
int myIntVal;
};

int main()
{
A a;
return 0;
}

The value of *myIntVal* in *a* object is indetereminate.
The default constructor synthesized by the compiler, does not invoke the
constructor for the *int*.
Why?

Because built-in types do not have constructors.

Which C++ book(s) are you reading?

-Mike

 

[Mike Wahler]

OK.

Does *int* has no non-trivial default constructor?

*None* of the built-in types (which include 'int') have
constructors at all. Only classes and structs can have
constructors.

-Mike

 

[Andrey Tarasevich]

...

Because built-in types do not have constructors.

Which C++ book(s) are you reading?
...

It might by surprising to many people here to find out that this
misunderstanding often originates from TC++PL book. For example, section
10.4.2 in 3rd edition of TC++PL ends with the following sentence:

"Built-in types also have default constructors".

And in many other places in the book there are references to
constructors of built-in types. I'm sure Bjarne Stroustrup had his
reasons to use an alternative non-standard terminology (most likely in
order to simplify things a bit within the context of the book). The
unpleasant side effect of this is that readers of TC++PL sometimes feel
lost and confused in C++ community that prefers the standard terminology.

 

[David White]

No it does not. Built-in types don't have constructors.


This syntax (introduced for 'symmetry') makes it *look*
like there's a ctor, but there's not.

My information comes from page 131 of "The C++ Programming Language". I
quote:

"The value of an explicit use of the constructor for a built-in type is 0
converted to that type. Thus, int() is another way of writing 0."

DW

 

[Andrey Tarasevich]

My information comes from page 131 of "The C++ Programming Language". I
quote:

"The value of an explicit use of the constructor for a built-in type is 0
converted to that type. Thus, int() is another way of writing 0."
...

Just as I said in another message in thus thread, Bjarne Stroustrup
makes use of some non-standard terminology in his TC++PL book. There is
no point in arguing about this. According to TC++PL, built-in types do
have constructors. According to the standard, built-in types have no
constructors at all.

Nevertheless, both the standard and TC++PL indicate that member
subobjects of built-in types are treated differently from non-POD class
types with regard to initialization. In particular, both sources
indicate that the member subobject from the OP's original message will
be left uninitialized.

 

[David White]

Just as I said in another message in thus thread, Bjarne Stroustrup
makes use of some non-standard terminology in his TC++PL book. There is
no point in arguing about this. According to TC++PL, built-in types do
have constructors. According to the standard, built-in types have no
constructors at all.

In what circumstance does it matter? I accept that built-in types do not
have _default_ constructors (and I said that in my first post), but to argue
whether they do or don't have constructors at all seems a pointless argument
over definitions, unless there is some circumstance in C++ code in which the
distinction is important.

int j(3);
int k = int(5);

If it looks like a constructor and quacks like a constructor, then for all
intents and purposes it _is_ a constructor, isn't it?

DW

 

[Andrey Tarasevich]

...
My information comes from page 131 of "The C++ Programming Language". I
quote:

"The value of an explicit use of the constructor for a built-in type is 0
converted to that type. Thus, int() is another way of writing 0."

IMO, this is an unfortunate choice of wording. C++'s built in types
(a.k.a., "plain old data" [POD] types) are NOT implemented as classes.
Since class types are the only types that have constructors, and since
POD types are not classes, then POD types do not have constructors.

FWIW, I suspect the meaning of the sentences on page 131 is something
more like,

The value of an explicit use of constructor notation with no
argument for a built-in type is 0 converted to that type.
Thus, int() is another way of writing 0."

or even,

The value of an explicit use of functional notation with no
argument for a built-in type ..."
...

That definitely is how these sentences would sound in standard wording.
But I don't think that the original form is nothing more than an
unfortunate choice of wording. For example, a sentence on page 224
(10.4.2) of the 3rd edition is more explicit and less open to
interpretations:

"Built-in types also have default constructors".

 

[Andrey Tarasevich]

In what circumstance does it matter? I accept that built-in types do not
have _default_ constructors (and I said that in my first post), but to argue
whether they do or don't have constructors at all seems a pointless argument
over definitions, unless there is some circumstance in C++ code in which the
distinction is important.

int j(3);
int k = int(5);

If it looks like a constructor and quacks like a constructor, then for all
intents and purposes it _is_ a constructor, isn't it?
...

This form - maybe, but not the '()' form, which is supposed to refer to
default constructor. It doesn't really quack like a constructor in all
contexts. For example, automatic objects and member subobjects of
built-in types are not initialized, unless an explicit initializer is
specified by the user. This wouldn't be the case if built-in types had
default constructors, which would quack when default constructors are
supposed to quack.

 

[Mike Wahler]

This form - maybe, but not the '()' form, which is supposed to refer to
default constructor. It doesn't really quack like a constructor in all
contexts. For example, automatic objects and member subobjects of
built-in types are not initialized, unless an explicit initializer is
specified by the user. This wouldn't be the case if built-in types had
default constructors, which would quack when default constructors are
supposed to quack.

Quack(); /* */

-Mike

 

[Vinodh Kumar]

int i = int(5);

In the above statement *int(5)* is not a constructor invocation?
Is there any guideline in the standard saying that primary types should not
be implemented as classes?
What is the typical implemenation of *int(5)* in some of the famous, good
implementations?
I know nothing is perfect.
But whats the truth?
The truth is that then we can't guarantee the C++ atomic types are as good
as their "C' counterparts, if we are implementing *int* as classes(As one is
always less than two in positive logic).
Right?
So my intution is ( since i have never seen any sourcecode of any c++
compilers) that all the available typical implementations of C++ provide
*int(5)* as a mere synctaical resemblance of nonPODs.
Thanks for all.

Regards,
Vinodh Kumar P

 

[Rolf Magnus]

int i = int(5);

In the above statement *int(5)* is not a constructor invocation?

Right, it's not.

Is there any guideline in the standard saying that primary types
should not be implemented as classes?

Yep

3.9.1:
There are two kinds of types: fundamental types and compound types.

The descriptions of "fundamental types" and "compound types" are a bit
long, but basically, the types you call "primary types" are the
"fundamental types". Classes are compound types.

What is the typical implemenation of *int(5)* in some of the famous,
good implementations?

What do you mean? It does the same as (int)5.

I know nothing is perfect.
But whats the truth?
The truth is that then we can't guarantee the C++ atomic types are as
good as their "C' counterparts, if we are implementing *int* as
classes

Well, if it were a POD class, we could in theory. But POD classes may
not have user-defined constructors

(As one is always less than two in positive logic).

Er... what?

Right?
So my intution is ( since i have never seen any sourcecode of any c++
compilers) that all the available typical implementations of C++
provide *int(5)* as a mere synctaical resemblance of nonPODs.

That's right. Having the same syntax for user-defined types and builtin
types can be useful in templates, so it's not only syntactic sugar.