Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #36689 > unrolled thread

Re: "default constructor"

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: "default constructor" Juha Nieminen <nospam@thanks.invalid> - 2017-06-21 14:32 +0000
    Re: "default constructor" "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2017-06-21 18:07 +0200
      Re: "default constructor" Eric Douglas <e.d.programmer@gmail.com> - 2017-06-21 10:26 -0700

#36689 — Re: "default constructor"

In comp.lang.c++ Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>   In C++, it is a constructor that can be called with missing
>   arguments (no arguments).

I have the impression that the word "default" is used in a somewhat
different meaning here.

Rather than meaning the same as "implicit constructor" (which is what
you are referring to), it means "the constructor that's called by
default when there is no explicit constructor call in the code
that instantiates the class" (or, in other words, when the class
is instantiated without any parameters).

In other words, when you write:

  MyClass obj;

the default constructor is called because no other constructor
call was specified explicitly. It doesn't matter whether that
default constructor was implicitly created by the compiler, or
explicitly declared in the implementation of the class.

[toc] | [next] | [standalone]

#36690

On 21-Jun-17 4:32 PM, Juha Nieminen wrote:
> In comp.lang.c++ Stefan Ram <ram@zedat.fu-berlin.de> wrote:
>>    In C++, it is a constructor that can be called with missing
>>    arguments (no arguments).
> 
> I have the impression that the word "default" is used in a somewhat
> different meaning here.
> 
> Rather than meaning the same as "implicit constructor" (which is what
> you are referring to), it means "the constructor that's called by
> default when there is no explicit constructor call in the code
> that instantiates the class" (or, in other words, when the class
> is instantiated without any parameters).
> 
> In other words, when you write:
> 
>    MyClass obj;
> 
> the default constructor is called because no other constructor
> call was specified explicitly. It doesn't matter whether that
> default constructor was implicitly created by the compiler, or
> explicitly declared in the implementation of the class.

First, let me apologize for calling you ungrateful, in another thread. I 
was angry. I stand by the rest (that your attacks were silly, and that 
they really annoyed me, and so forth), because that was either objective 
or reporting how I felt, but assigning motives and deducing 
characteristics of people is Just Wrong. I did it out of anger but it 
was still wrong of me. I had no basis for that, it was not an 
evaluation, it was just very ugly name calling, lashing out. I'm sorry.

Now regarding what you write here, I agree with you in principle, that 
this is a good way to think about it, a good conceptual model.

But it's worth being aware that this model, of the default constructor 
being called, either a user-defined one or one generated by the 
compiler, breaks down in a certain case, as illustrated below:


------------------------------------------------------------------------
#include <iostream>
#include <string>
using namespace std;

struct S
{
     int     score;
     string  name;
};

auto operator<<( ostream& stream, S const& o )
     -> ostream&
{ return stream << "{" << o.name << ", " << o.score << "}"; }

auto main() -> int
{
     S a;            // Default initialization
     S b{};          // Value initialization

     cout << a << endl;
     cout << b << endl;
}
------------------------------------------------------------------------


Results in Windows 10 using MinGW g++ 6.3.0 and Visual C++ 2017:


------------------------------------------------------------------------
[H:\forums\clc++\020 vaue init versus default init]
 > g++ initializations.cpp

[H:\forums\clc++\020 vaue init versus default init]
 > a
{, 65535}
{, 0}

[H:\forums\clc++\020 vaue init versus default init]
 > cl initializations.cpp /Feb
initializations.cpp

[H:\forums\clc++\020 vaue init versus default init]
 > b
{, 15726820}
{, 0}

[H:\forums\clc++\020 vaue init versus default init]
 > _
------------------------------------------------------------------------


The funny `a.score` values stem from default initialization. It leaves 
that member indeterminate. Value initialization zeroes it.

Now you wrote nothing about value initialization, but it's clear from 
the difference that either value initialization uses a default 
constructor that's not the one that default initialization uses, or one 
or both of them doesn't actually call a constructor with a single 
well-defined effect, or both compilers above are non-conforming.

In C++98 there was no value initialization so one had the indeterminate 
value in both the `S a;` case and e.g. the `S* p = new S();` case.

Andrew Koenig then fixed this partially by proposing value 
initialization, which was included in C++03. This was the only really 
new thing in C++03, which otherwise was just Technical Corrigendum 1, 
TC1, a bug-fix of C++98. But if we view it as a fix of a design level 
bug (with the “design” the design of C++) it was also just a fix. ;-)


Cheers!, and again, sorry for that name calling,

- Alf

[toc] | [prev] | [next] | [standalone]

#36692

On Wednesday, June 21, 2017 at 12:07:42 PM UTC-4, Alf P. Steinbach wrote:
> Now you wrote nothing about value initialization, but it's clear from 
> the difference that either value initialization uses a default 
> constructor that's not the one that default initialization uses, or one 
> or both of them doesn't actually call a constructor with a single 
> well-defined effect, or both compilers above are non-conforming.
> 
> In C++98 there was no value initialization so one had the indeterminate 
> value in both the `S a;` case and e.g. the `S* p = new S();` case.
> 
> Andrew Koenig then fixed this partially by proposing value 
> initialization, which was included in C++03. This was the only really 
> new thing in C++03, which otherwise was just Technical Corrigendum 1, 
> TC1, a bug-fix of C++98. But if we view it as a fix of a design level 
> bug (with the “design” the design of C++) it was also just a fix. ;-)
> 

So you're saying write Java, don't use C++.  I don't know of any such problems with Java.
If you want clear defined initialization, try COBOL.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web