Thread: Temporary object created by calling constructor

Hi, I was wondering if this idea I have is correct, I couldn't find an answer online

if i had a simple class

Code:

      class Dog
     { 
            Dog(x,y);
            public:

            void   coolFunction(Dog) ;//Receives object of type Dog as parameter

            private: 
              int x;
              
              int y ;

          }

So since the coolFunction(Dog Object) takes an object of type Dog, instead of declaring a
new object Dog dog1
and do this

Code:

          coolFunction(dog1); ...//first method

I should be able to do this

Code:

           coolFunction(Dog(4,4)) ; //second method

I believe that that the second method will create a temporary object in memory by calling the Vector(x,y) constructor,.. and when that copy is passed to the coolFunction(...) the object is then destroyed.


Can someone tell me if that is wrong or right?
Or if that is a good practice or idea..i know in C# the same concept is used or it is acceptable.

Originally Posted by laserlight

You can track constructor and destructor invocations to see what is happening. Note that copy construction can be elided by the compiler as an optimisation.

Thanks for reply.
Yes, I know that but when I did this

coolFunction ( Dog(x,y) )

I am referring to Dog constructor being called in the parameter coolFunction..

by doing that Dog(x,y) am I creating a <b>new</b> object although this object is temporary because I am <b>not</b> declaring a variable
so once the value is passed to the function, this temporary object is destroyed.. because it isn't a variable
do you understand what I mean?

Originally Posted by grumpy

It depends how aggressive the compiler is with optimisation.

If you and I can see that the two lines are equivalent (apart from the number of temporaries involved) then the compiler is allowed to detect that and elide temporaries.

Compilers aren't required to do that, but they are allowed to.

Which means that classes, and code that uses such classes, should not be constructed in a way that relies on any particular behaviour with temporaries - the net effects (other than performance and similar quality attributes) should be the same regardless of how the compiler treats temporaries.

sorry I didn't get any of that. In English please?
so..when I "call" the constructor it <b>does</b> create a temporary object ?

Originally Posted by laserlight

Conceptually, yes.

Compile and run this program:

Code:

#include <iostream>

class Dog
{ 
public:
    Dog(int x, int y) : x(x), y(y)
    {
        std::cout << "Dog(int, int) of " << this << std::endl;
    }

    Dog(const Dog& other) : x(other.x), y(other.y)
    {
        std::cout << "Dog copy ctor of " << this << std::endl;
    }

    ~Dog()
    {
        std::cout << "Dog dtor of " << this << std::endl;
    }

    void coolFunction(Dog other)
    {
        std::cout << "coolFunction(Dog) of " << this
            << "; parameter: " << &other << std::endl;
    }
private:
    int x;
    int y;
};

int main()
{
    Dog a(1, 2);
    a.coolFunction(Dog(4, 4));
}

Cool so it does create an object, and it dies when it goes out of scope... ?

Originally Posted by laserlight

The answer to that is definitely a yes, but how you understand the "yes" is another matter. I suggest that you change the main function to this:

Code:

int main()
{
    Dog a(1, 2);
    std::cout << "before" << std::endl;
    a.coolFunction(Dog(4, 4));
    std::cout << "after" << std::endl;
}

Then try with this:

Code:

int main()
{
    Dog a(1, 2);
    Dog b(4, 4);
    std::cout << "before" << std::endl;
    a.coolFunction(b);
    std::cout << "after" << std::endl;
}

You will probably find considerable difference between the two, but in theory they could actually amount to the same thing (in terms of number of constructor and destructor invocations) if the copy constructor was not elided in the first snippet.

So, unless you need to copy the argument anyway, you should generally prefer to have your parameters of class type be (const) references.

It took me a while to reply because I was trying to understand what was happening lol.
So the difference in what was happening is that once the copy constructor of one object was called the second program was called
while the second one wasn't.

I can only assume that when I did this coolFunction(Dog(4,4)) I am not passing a reference to an "actual" object in memory. i'm not sure how to explain it, but Dog(4,4) isn't concrete...?

while coolFunction(b) will call the copy constructor because it has a "valid/concrete" address in memory.
I'm not sure how to explain it

Originally Posted by laserlight

Take a look at what the C++ standard has to say about this:

So, it is not that Dog(4, 4) is not "concrete", but that the compiler elided the copying of the temporary object by treating it as the same object as the parameter.

mmn, thanks very much. I don't really get it because I haven't covered copy constructors yet.since I am learning C++ blindly what I am learning isn't in order. I will save this link and refer to it next when I have covered CC.

and where can I find this C++ standard?
Ty

With better understanding of Copy Constructor.
I want to clarify the difference between doing this

Code:

   a.coolFunction(Dog(4,4) ) ; 
   //and 
  a.coolFunction(b) ;

The compiler does not see Dog(4,4) as a already existing object, so therefore did not have any reason to invoke the copy constructor.
as a result it calls this constructor

Code:

    Dog(int x, int y) : x(x), y(y)
    {
        std::cout << "Dog(int, int) of " << this << std::endl;
    }

but for this piece of code a.coolFunction(b)
the compiler sees the reason to use a copy constructor to copy the already defined object.

That's an attempt to explain it to myself...

OK, yes correct,
i will refer to your quote, to clear things up:

So, it is not that Dog(4, 4) is not "concrete", but that the compiler elided the copying of the temporary object by treating it as the same object as the parameter.

I don't get the last part of it
<b>treating it as the same object as the parameter.</b>
Do you mean that it looks at the overloaded constructor signature and therefore as a result may elide the use of the copy constructor depending on that.