I originally posted this as a question only about destructors, but now I&#39;m adding consideration of the default constructor.  Here&#39;s the original question:

&gt; If I want to give my class a destructor that is virtual, but is
&gt; otherwise the same as what the compiler would generate, I can use `=default`:
&gt; 
&gt;     class Widget {
&gt;     public:
&gt;        virtual ~Widget() = default;
&gt;     };
&gt; 
&gt; But it seems that I can get the same effect with less typing using an
&gt; empty definition:
&gt; 
&gt;     class Widget {
&gt;     public:
&gt;        virtual ~Widget() {}
&gt;     };
&gt; 
&gt; Is there any way in which these two definitions behave differently?

Based on the replies posted for this question, the situation for the default constructor seems similar.  Given that there is almost no difference in meaning between &quot;`=default`&quot; and &quot;`{}`&quot; for destructors, is there similarly almost no difference in meaning between these options for default constructors?  That is, assuming I want to create a type where the objects of that type will be both created and destroyed, why would I want to say

    Widget() = default;

instead of
   
    Widget() {}

?

I apologize if extending this question after its original posting is violating some SO rules.  Posting an almost-identical question for default constructors struck me as the less desirable option.


How is &quot;=default&quot; different from &quot;{}&quot; for default constructor and destructor?

Is there any good reason that an empty set of round brackets (parentheses) isn&#39;t valid for calling the default constructor in C++?

    MyObject  object;  // ok - default ctor
    MyObject  object(blah); // ok

    MyObject  object();  // error

I seem to type &quot;()&quot; automatically everytime. Is there a good reason this isn&#39;t allowed?


Default constructor with empty brackets

Does the default constructor (created by the compiler) initialize built-in-types?

Does the default constructor initialize built-in types?

What exactly is a default constructor — can you tell me which one of the following is a default constructor and what differentiates it from any other constructor?

    public Module() {
       this.name = &quot;&quot;;
       this.credits = 0;
       this.hours = 0;
    }
    
    public Module(String name, int credits, int hours) {
       this.name = name;
       this.credits = credits;
       this.hours = hours;
    }


Java default constructor

In C#, C++ and Java, when you create a constructor taking parameters, the default parameterless one goes away. I have always just accepted this fact, but now I&#39;ve started wondering why.

What is the reason for this behavior? Is it just a &quot;safety measure/guess&quot; saying &quot;If you&#39;ve created a constructor of your own, you *probably* don&#39;t want this implicit one hanging around&quot;?
Or does it have a technical reason that makes it impossible for the compiler to add one once you have created a constructor yourself?

Why does the default parameterless constructor go away when you create one with parameters

As JPA requires, `@Entity` classes should have a default (non-arg) constructor to instantiate the objects when retrieving them from the database.

In Kotlin, properties are very convenient to declare within the primary constructor, as in the following example:

    class Person(val name: String, val age: Int) { /* ... */ }

But when the non-arg constructor is declared as a secondary one it requires values for the primary constructor to be passed, so some valid values are needed for them, like here:

    @Entity
    class Person(val name: String, val age: Int) {
        private constructor(): this(&quot;&quot;, 0)
    }

In case when the properties have some more complex type than just `String` and `Int` and they&#39;re non-nullable, it looks totally bad to provide the values for them, especially when there&#39;s much code in primary constructor and `init` blocks and when the parameters are actively used -- when they&#39;re to be reassigned through reflection most of the code is going to be executed again.

Moreover, `val`-properties cannot be reassigned after the constructor executes, so immutability is also lost.

So the question is: how can Kotlin code be adapted to work with JPA without code duplication, choosing &quot;magic&quot; initial values and loss of immutability?

P.S. Is it true that Hibernate aside of JPA can construct objects with no default constructor?

Kotlin with JPA: default constructor hell

I want to refresh my memory on the conditions under which a compiler typically auto generates a default constructor, copy constructor and assignment operator.

I recollect there were some rules, but I don&#39;t remember, and also can&#39;t find a reputable resource online. Can anyone help?

Conditions for automatic generation of default/copy/move ctor and copy/move assignment operator?

With C++11 `std::array`, do I have the guarantee that the syntax `std::array&lt;T, N&gt; x;` will default-initialize all the elements of the array ?

**EDIT**: if not, is there a syntax that will work on all arrays (including zero-sized arrays) to initialize all elements to their default value?

**EDIT**: on [cppreference][1], the default constructor description says:

    (constructor) (implicitly declared) (public member function)
    default-constructs or copy-constructs every element of the array 

so the answer may be yes. But I would like to be sure of that according to the standard or future standard.


  [1]: http://en.cppreference.com/w/cpp/container/array

Default initialization of std::array?

Take the following class as an example:

    class Sometype
    {
        int someValue;
    
        public Sometype(int someValue)
        {
            this.someValue = someValue;
        }
    }

I then want to create an instance of this type using reflection:

    Type t = typeof(Sometype);
    object o = Activator.CreateInstance(t);

Normally this will work, however because `SomeType` has not defined a parameterless constructor, the call to `Activator.CreateInstance` will throw an exception of type `MissingMethodException` with the message &quot;*No parameterless constructor defined for this object.*&quot; Is there an alternative way to still create an instance of this type? It&#39;d be kinda sucky to add parameterless constructors to all my classes.


Creating instance of type without default constructor in C# using reflection

Let&#39;s say I have a type and I want to make its default constructor private. I write the following:

    class C {
        C() = default;
    };
    
    int main() {
        C c;           // error: C::C() is private within this context (g++)
                       // error: calling a private constructor of class &#39;C&#39; (clang++)
                       // error C2248: &#39;C::C&#39; cannot access private member declared in class &#39;C&#39; (MSVC)
        auto c2 = C(); // error: as above
    }

Great.

But then, the constructor turns out to not be as private as I thought it was:

    class C {
        C() = default;
    };

    int main() {
        C c{};         // OK on all compilers
        auto c2 = C{}; // OK on all compilers
    }    

This strikes me as very surprising, unexpected, and explicitly undesired behavior. Why is this OK? 

When is a private constructor not a private constructor?

I have been asked this question by a colleague that should we always include a default constructor in a class? If so, why? If no, why not?

_**Example**_

    public class Foo {

        Foo() { }

        Foo(int x, int y) {
            ...
        } 

    }

I am also interested to get some lights on this from experts.

Should we always include a default constructor in the class?

I can do this:

    #include &lt;iostream&gt;
    
    int counter;
    
    int main()
    {
    	struct Boo
    	{
    		Boo(int num)
    		{
    			++counter;
    			if (rand() % num &lt; 7) Boo(8);
    		}
    	};
    
    	Boo(8);
    
    	return 0;
    }

This will compile fine, my counter result is **21**. However when I try to create the `Boo` object passing the constructor argument instead of an integer literal I get a compile error:

    #include &lt;iostream&gt;
    
    int counter;
    
    int main()
    {
    	struct Boo
    	{
    		Boo(int num)
    		{
    			++counter;
    			if (rand() % num &lt; 7) Boo(num); // No default constructor 
                                                // exists for Boo
    		}
    	};
    
    	Boo(8);
    
    	return 0;
    }

How is a default constructor called in the second example but not in the first example? This is error I get on Visual Studio 2017.

On the online C++ compiler onlineGDB I get the errors:

    error: no matching function for call to ‘main()::Boo::Boo()’
        if (rand() % num &lt; 7) Boo(num);
          
                               ^
    note:   candidate expects 1 argument, 0 provided



Why won&#39;t this compile without a default constructor?

When I don&#39;t declare a constructor for example, the compiler will provide me with a default constructor that will have no arguments and no definition (empty body), and thus, will take **no action**.

So, if I&#39;m finished with an object for example, wouldn&#39;t the default destructor reallocate (free) memory used by the object? If it doesn&#39;t, why are we getting it?

And, maybe the same question applies to the default constructor. If it does nothing, why is it created for us by default?

Why do C++ objects have a default destructor?

I recently grew tired of constantly having to know `String` keys to pass arguments into `Bundles` when creating my `Fragments`. So I decided to make constructors for my `Fragments` that would take the parameters I wanted to set, and put those variables into the `Bundles` with the correct `String` keys, therefore eliminating the need for other `Fragments` and `Activities` needing to know those keys.

	public ImageRotatorFragment() {
		super();
		Log.v(TAG, &quot;ImageRotatorFragment()&quot;);
	}

	public ImageRotatorFragment(int imageResourceId) {
		Log.v(TAG, &quot;ImageRotatorFragment(int imageResourceId)&quot;);

		// Get arguments passed in, if any
		Bundle args = getArguments();
		if (args == null) {
			args = new Bundle();
		}
		// Add parameters to the argument bundle
		args.putInt(KEY_ARG_IMAGE_RES_ID, imageResourceId);
		setArguments(args);
	}

And then I pull out those arguments like normal.

	@Override
	public void onCreate(Bundle savedInstanceState) {
		super.onCreate(savedInstanceState);
		Log.v(TAG, &quot;onCreate&quot;);

		// Set incoming parameters
		Bundle args = getArguments();
		if (args != null) {
			mImageResourceId = args.getInt(KEY_ARG_IMAGE_RES_ID, StaticData.getImageIds()[0]);
		}
		else {
			// Default image resource to the first image
			mImageResourceId = StaticData.getImageIds()[0];
		}
	}

However, Lint took issue with this, saying not to have subclasses of `Fragment` with constructors with other parameters, requiring me to use `@SuppressLint(&quot;ValidFragment&quot;)` to even run the app. The thing is, this code works perfectly fine. I can use `ImageRotatorFragment(int imageResourceId)` or the old school method `ImageRotatorFragment()` and call `setArguments()` manually on it. When Android needs to recreate the Fragment (orientation change or low memory), it calls the `ImageRotatorFragment()` constructor and then passes the same argument `Bundle` with my values, which get set correctly.

So I have been searching for the &quot;suggested&quot; approach and see a lot of examples using `newInstance()` to create `Fragments` with parameters, which seems to do the same thing my constructor is. So I made my own to test it, and it works just as flawlessly as before, minus Lint whining about it.


	public static ImageRotatorFragment newInstance(int imageResourceId) {
		Log.v(TAG, &quot;newInstance(int imageResourceId)&quot;);

		ImageRotatorFragment imageRotatorFragment = new ImageRotatorFragment();

		// Get arguments passed in, if any
		Bundle args = imageRotatorFragment.getArguments();
		if (args == null) {
			args = new Bundle();
		}
		// Add parameters to the argument bundle
		args.putInt(KEY_ARG_IMAGE_RES_ID, imageResourceId);
		imageRotatorFragment.setArguments(args);

		return imageRotatorFragment;
	}

I personally find that using constructors is a much more common practice than knowing to use `newInstance()` and passing parameters. I believe you can use this same constructor technique with Activities and Lint will not complain about it. **So basically my question is, why does Google not want you to use constructors with parameters for `Fragments`?**

My only guess is so you don&#39;t try to set an instance variable without using the `Bundle`, which won&#39;t get set when the `Fragment` gets recreated. By using a `static newInstance()` method, the compiler won&#39;t let you access an instance variable. 

	public ImageRotatorFragment(int imageResourceId) {
		Log.v(TAG, &quot;ImageRotatorFragment(int imageResourceId)&quot;);

		mImageResourceId = imageResourceId;
	}

I still don&#39;t feel like this is enough reason to disallow the use of parameters in constructors. Anyone else have insight into this?


Creating a Fragment: constructor vs newInstance()

[Gson user guide][1] states that we should define default no-args constructor for any class to work with Gson properly. Even more, in the [javadoc][2] on Gson&#39;s `InstanceCreator` class said that exception will be thrown if we try to deserialize instance of class missing default constructor and we *should* use `InstanceCreator` in such cases. However, I&#39;ve tried to test use Gson with class lacking default constructor and both serialization and deserialization work without any trouble.

Here is the piece of code for deserializaiton. A class without non-args constructor:

&lt;!-- language: lang-java --&gt;

    public class Mushroom {
        private String name;
        private double diameter;

        public Mushroom(String name, double diameter) {
            this.name = name;
            this.diameter = diameter;
        }

        //equals(), hashCode(), etc.
    }

and a test:

&lt;!-- language: lang-java --&gt;

    @Test
    public void deserializeMushroom() {
        assertEquals(
                new Mushroom(&quot;Fly agaric&quot;, 4.0),
                new Gson().fromJson(
                        &quot;{name:\&quot;Fly agaric\&quot;, diameter:4.0}&quot;, Mushroom.class));
    }

which works fine.

So my question is: **could I actually use Gson without need to have default constructor or there is any circumstances when it will not work?**


  [1]: https://sites.google.com/site/gson/gson-user-guide
  [2]: http://google-gson.googlecode.com/svn/trunk/gson/docs/javadocs/com/google/gson/InstanceCreator.html

Is default no-args constructor mandatory for Gson?

I&#39;m preparing for my CPP exam and one of the question is: Can you delete default class constructor and if so, what would be the reason to do so? OK, so obviously you can do it:

    class MyClass 
    { 
      public: 
        MyClass() = delete; 
    };


but I do not understand why would you do it? 


What&#39;s the point of deleting default class constructor?

I have a question about default constructors and inheritance in Java. 

Generally, if you write a class and do not include any constructor, Java provides automatically for you a default constructor (one without parameters), which initializes all instance variables of the class (if there are any) with some default values (0, null, or false). If you write a constructor, however, with some parameters, and you don&#39;t write  any default constructor, then Java does not provide a default constructor. 
My question is: what is the case with classes, which inherit from other classes - if I write a constructor with some parameters in them, but don&#39;t include a default constructor, do they inherit the default constructor of the super class?

All Default Constructor Solutions on Gang of Coders

Total of 17 Default Constructor Solutions

How is "=default" different from "{}" for default constructor and destructor?