2
#include <iostream>
using namespace std;

class Test
{
    public:
    Test()  { cout << "Constructor is executed\n"; }
    ~Test() { cout << "Destructor is executed\n";  }
};

int main()
{
     Test();  // Explicit call to constructor

    return 0;
}

in above code we are calling constructor explicitly and When the constructor is called explicitly the compiler creates a nameless temporary object and it is immediately destroyed. why do we need this temporary object??

Quentin
  • 62,093
  • 7
  • 131
  • 191
Maya Ojha
  • 21
  • 3

4 Answers4

0

Because the constructor & destructor have side effects. They both print stuff.

If they had no side effects, then the compiler might be smart enough to figure out that it doesn't actually need to create the temporary, and skip it entirely.

evan
  • 1,463
  • 1
  • 10
  • 13
0

The functional type conversion notation you are using, Test(...), actually means "create a temporary object of type Test" from C++98 up to C++14. Therefore, the temporary is created, as requested, and the constructor is called in order to initialize the object. It does not mean "call the constructor". In fact, the execution of a constructor can never be separated from the creation of an object.

In C++17, Test() is a prvalue that is materialized since it is used as a discarded-value expression. At the point of materialization, the temporary object is created, and the constructor is called. It remains true that the execution of a constructor never occurs separately from the creation of an object.

Brian Bi
  • 111,498
  • 10
  • 176
  • 312
  • By "In C++17, Test() is a prvalue that is materialized since it is used as a discarded-value expression." are you trying to convey something about mandatory copy elision? I don't think I follow :( – Curious Dec 29 '16 at 05:23
  • @Curious Yes, maybe I wasn't clear enough, but with guaranteed copy elision, a prvalue expression no longer denotes an object in itself, but rather a potential object. Perhaps this distinction is too subtle in this context... – Brian Bi Dec 29 '16 at 05:25
  • Can you, please, clarify what you mean by "constructor can never be separated from the **creation** of an object"? What do you mean by "creation"? Initialization? Placement `new` expression can separate initialization from allocation. – Dmitry Rubanovich Dec 29 '16 at 05:47
  • 1
    @DmitryRubanovich If the object has a nontrivial constructor, its lifetime does not begin until after the constructor has completed. Placement new creates the object; before the placement new call, all you have is some memory that the object will occupy, not the object itself. – Brian Bi Dec 29 '16 at 05:50
  • **−1** All the rest of your answer is OK, but “[the notation] does not mean "call the constructor"” is bull. That's exactly what it means, in this context. There is no contradiction with "create a temporary object": it does that also, as you mention in the OK part of the answer. – Cheers and hth. - Alf Dec 29 '16 at 06:19
0

The standard (C++14) briefly mentions some circumstances of temporary object :

1. Binding a reference to a prvalue
2. Returning a prvalue 
3. A conversion that creates a prvalue
4. Throwing an exception
5. In some initializations

You can get the description of prvalue from stackoverflow. I have collected the circumstances from Quora.

Community
  • 1
  • 1
sunkuet02
  • 2,376
  • 1
  • 26
  • 33
0

Re

why do we need this temporary object??

… we don't. The compiler is free to optimize away, as long as the effect is as if the constructor and destructor, with side effects, had been called.

The compiler can't remove the constructor and destructor side effects because the standard explicitly requires it to not remove local objects whose construction or destruction has side effects:

C++11 §3.7.3/3basic.std.auto/3:

If a variable with automatic storage duration has initialization or a destructor with side effects, it shall not be destroyed before the end of its block, nor shall it be eliminated as an optimization even if it appears to be unused, except that a class object or its copy/move may be eliminated as specified in 12.8.

Cheers and hth. - Alf
  • 142,714
  • 15
  • 209
  • 331