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]

Re: Default constructor

Vinodh Kumar wrote:[color=blue]
> 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?[/color]

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.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

[David White]

Re: Default constructor

"Vinodh Kumar" <thecomdevelope r@yahoo.com> wrote in message
news:bgnrgg$kcp $1@news.mch.sbs .de...[color=blue]
>
> Does *int* has no non-trivial default constructor?[/color]

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_conditi on)
{ do_something(); k = 2;
}
else
{ do_something_el se(); 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]

Re: Default constructor

Vinodh Kumar wrote:
[color=blue][color=green][color=darkred]
>> > 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?[/color]
>>
>> 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.
>>[/color]
> OK.
>
> Does *int* has no non-trivial default constructor?[/color]

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]

Re: Default constructor


Vinodh Kumar <thecomdevelope r@yahoo.com> wrote in message
news:bgnpld$dbd $1@news.mch.sbs .de...[color=blue]
> 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?[/color]

Because built-in types do not have constructors.

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

-Mike

[Mike Wahler]

Re: Default constructor


Vinodh Kumar <thecomdevelope r@yahoo.com> wrote in message
news:bgnrgg$kcp $1@news.mch.sbs .de...[color=blue]
>
> "Andrey Tarasevich" <andreytarasevi ch@hotmail.com> wrote in message
> news:3F2F6C1F.3 000007@hotmail. com...[color=green]
> > Vinodh Kumar wrote:[color=darkred]
> > > 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[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > constructor for the *int*.
> > > Why?[/color]
> >
> > 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.
> >[/color]
> OK.
>
> Does *int* has no non-trivial default constructor?[/color]

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

-Mike

[Andrey Tarasevich]

Re: Default constructor

Mike Wahler wrote:[color=blue]
> ...[color=green]
>> 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?[/color]
>
> Because built-in types do not have constructors.
>
> Which C++ book(s) are you reading?
> ...[/color]

It might by surprising to many people here to find out that this
misunderstandin g 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.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

[David White]

Re: Default constructor

Mike Wahler <mkwahler@mkwah ler.net> wrote in message
news:bgokmu$k5m $1@slb6.atl.min dspring.net...[color=blue]
>[color=green]
> > However, int does have a non-default constructor[/color]
>
> No it does not. Built-in types don't have constructors.
>[color=green]
> > that takes no arguments:
> >
> > int k = int(); // = 0[/color]
>
> This syntax (introduced for 'symmetry') makes it *look*
> like there's a ctor, but there's not.[/color]

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]

Re: Default constructor

David White wrote:[color=blue][color=green]
>> ...[color=darkred]
>> > However, int does have a non-default constructor[/color]
>>
>> No it does not. Built-in types don't have constructors.
>>[color=darkred]
>> > that takes no arguments:
>> >
>> > int k = int(); // = 0[/color]
>>
>> This syntax (introduced for 'symmetry') makes it *look*
>> like there's a ctor, but there's not.[/color]
>
> 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."
> ...[/color]

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.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

[David White]

Re: Default constructor

Andrey Tarasevich <andreytarasevi ch@hotmail.com> wrote in message
news:3F303860.2 080500@hotmail. com...[color=blue]
> David White wrote:[color=green]
> > 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[/color][/color]
0[color=blue][color=green]
> > converted to that type. Thus, int() is another way of writing 0."
> > ...[/color]
>
> 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.[/color]

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]

Re: Default constructor

Jim Fischer wrote:[color=blue][color=green]
>> ...
>> 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."[/color]
>
> 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 ..."
> ...[/color]

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".

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

[Andrey Tarasevich]

Re: Default constructor

David White wrote:[color=blue][color=green]
>> ...
>> 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.[/color]
>
> 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?
> ...[/color]

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.

--
Best regards,
Andrey Tarasevich
Brainbench C and C++ Programming MVP

[Mike Wahler]

Re: Default constructor

Andrey Tarasevich <andreytarasevi ch@hotmail.com> wrote in message
news:3F3041F0.1 090003@hotmail. com...
[color=blue][color=green]
> > int j(3);
> > int k = int(5);
> >
> > If it looks like a constructor and quacks like a constructor, then for[/color][/color]
all[color=blue][color=green]
> > intents and purposes it _is_ a constructor, isn't it?
> > ...[/color]
>
> 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.[/color]

Quack(); /* :-) */

-Mike

[Vinodh Kumar]

Re: Default constructor

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



"Vinodh Kumar" <thecomdevelope r@yahoo.com> wrote in message
news:bgnpld$dbd $1@news.mch.sbs .de...[color=blue]
> 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?
>
>[/color]

[Rolf Magnus]

Re: Default constructor

Vinodh Kumar wrote:
[color=blue]
> int i = int(5);
>
> In the above statement *int(5)* is not a constructor invocation?[/color]

Right, it's not.
[color=blue]
> Is there any guideline in the standard saying that primary types
> should not be implemented as classes?[/color]

Yep

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

The descriptions of "fundamenta l types" and "compound types" are a bit
long, but basically, the types you call "primary types" are the
"fundamenta l types". Classes are compound types.
[color=blue]
> What is the typical implemenation of *int(5)* in some of the famous,
> good implementations ?[/color]

What do you mean? It does the same as (int)5.
[color=blue]
> 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[/color]

Well, if it were a POD class, we could in theory. But POD classes may
not have user-defined constructors :-)
[color=blue]
> (As one is always less than two in positive logic).[/color]

Er... what?
[color=blue]
> 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.[/color]

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.