CConstructor Infinite Recursion!

std::list::push_back, and push_back for any other STL container, uses a const reference.

void push_back ( const T& x );

Add element at the end
Adds a new element at the end of the list, right after its current last element. The content of this new element is initialized to a copy of x.

This effectively increases the list size by one.

Code:

while ( whatever ) {
   Dog save(stuff);
   
   a.push_back(save);
}

Incidentally, this (unasked) question is better than the earlier one. Most of the time, you just need to explain the real, actual problem, and delve not into hypotheticals. There are so many smart people here, it is unfair to other places.

Originally Posted by whiteflags

std::list:ush_back, and push_back for any other STL container, uses a const reference.

Code:

while ( whatever ) {
   Dog save(stuff);
   
   a.push_back(save);
}

Incidentally, this (unasked) question is better than the earlier one

I tried that, but it didn't work, because the save object would still go out of scope and the pointer would address would be destroyed.
Yes, i think this is better because I know for sure the copy constructor would be called.

Most of the time, you just need to explain the real, actual problem, and delve not into hypotheticals. There are so many smart people here, it is unfair to other places.

I apologize, didn't mean to offend you or anyone .

If i implemented to copy constructor so that when pushing to the list it copies using the defined constructor, the question is would it work?

OK, well there is no real difference between what I wrote and a.push_back( Dog(4,4) ); It is copied anyway according to the reference page. But the problem must be with your copy constructor if you are pushing invalid objects into a.

I would want to see Dog's members and the available copy constructor to fix it.

Originally Posted by whiteflags

OK, well there is no real difference between what I wrote and a.push_back( Dog(4,4) ); It is copied anyway according to the reference page. But the problem must be with your copy constructor if you are pushing invalid objects into a.

I would want to see Dog's members and the available copy constructor to fix it.

yeah that is the problem, i didn't even have a copy constructor.

Code:

      class Dog
      {
              char *name ; 
              int a,  b ;

              Dog(int x, int y) 
              {

                      a = x; 
                       b = y  ;

                      name = new int[5] ;
                       name="Jack
                }

               ~Dog()
                {
                         delete []name ;
                      // i think when it goes out of scope the destructor the destroys the                  
                      //memory location of name, but the object copied to the list would point to                
                       //that memory address, and when i accessed it later i got a seg fault.
                      //maybe this idea is wrong then. 
                 } 


       }

No, you are correct. When the Dog you passed to push_back goes out of scope the destructor will be called, but you copied that old address into a's copy of Dog. This is why default copy construction doesn't work for objects that have resources you need to manage.

Even changing name to std::string would solve Dog's problems, because you don't have to manage memory.

Originally Posted by whiteflags

No, you are correct. When the Dog you passed to push_back goes out of scope the destructor will be called, but you copied that old address into a's copy of Dog. This is why default copy construction doesn't work for objects that have resources you need to manage.

Even changing name to std::string would solve Dog's problems, because you don't have to manage memory.

Oh yes, you caught me out haha.
Well, in truth i am making a using allegro and i wasn't using c string, but
a function called create_bitmap(..) and that uses the free store.

I just thought simplifying it to strings would make discussion easier.

And yes! I just tried it, it absolutely worked! I was able to use destructor as normal and it looks cleaner.

Maybe copy constructors aren't so bad hahaha.

Thanks very much man.

Originally Posted by whiteflags

It's an even better idea to not have the default construction be a NULL string. Real string classes allocate a small chunk, even if it is going to be an empty string.

I wrote that example in quite a hurry. I could have virtually guaranteed that it was buggy, but it seems to have illustrated the point well enough.
I should also point out that it's completely useless since there are no ways to access the stored data.

>>I wrote that example in quite a hurry

And that's OK. I was only trying to respond to Eman's questions.

so I think maybe I can understand what you meant by infinite recursion. If i go back to function call basics.

Code:

  void foo(int a) ;  
   main()
   {
        foo(10) ; 
   }

Steps
1. main invokes the foo function.
2. the compiler/OS sets about to make a copy of 10 and assigns a the copied value.
3. function call ends.
now if i apply that basic concept, then the theory of infinite recursion makes sense

Code:

      class A 
      {
            A(A a) 
           {
                      // we assume it will compile
           }
       } ;
       main() 
      {
             A a ;

             B b(a) ;

      }

Steps
"B b(a)" naturally will invoke a function call.
1. Copy constructor is invoked. We've already defined one, so compiler issues that.
2. Compiler/OS (i'm not sure which, but I assume it is the OS, makes more sense) proceeds to make a copy of the object in the parameter.
But wait it is an object, and what makes copies of object? A copy constructor! Copy constructor is invoked.
3. Compiler proceeds to make a copy of the parameter. Hold on, it is an object. What makes copies of objects? A copy constructor! We've defined one. and so it goes on.

Infinite recursion...

But for pass by reference

Code:

          class A 
         {
                A(A &a) 
               {
                     // we assume it will compile
                }
          } ;
         main() 
        {
               A a ;

               B b(a) ; 

         }

Steps
1. Copy constructor is invoked.
2. Compiler proceeds to make copy of parameter.
3. It is not a object, but a reference to the object.
4. The compiler makes a copy of the address and stores the address to the copy constructor parameter. The compiler automatically dereferences it for us, which makes all the difference between references and compiler. (Simply the compiler makes a reference to the constructor parameter)
5. Copy Constructor exits.
No infinite recursion.

So I was going through all this on paper, to really "see" what was happening. and I think the "algorithm" of what happens might be what you meant.
Going through it feels correct and makes sense.

Is it correct?
Thanks

Originally Posted by iMalc

I should also point out that it's completely useless since there are no ways to access the stored data.

What do you mean, what is useless?

The only thing to note is that a copy constructor behaves like a real function.
If you have

Code:

foo(A a)

Then the compiler will generate code to make a copy of the object which is passed to foo. It does this by calling the copy constructor. But a copy constructor is a function, like everything else.
So if you have

Code:

A::A(A a)

Then the compiler must generate code to make a copy of the object passed into the copy constructor. And the problem is, of course, that the object's type is the same type as the copy constructor's. So it would invoke A's copy constructor. Again. And so on.

Now take note that references are aliases and not addresses.

Code:

A& a = b;

In this example, a is simply another name for b.
But no copy is made because we're just creating an alias.

Now, you seem to be running into SourceForge.net: Raw pointer issues - cpwiki. Suggest you read it.

Originally Posted by Elysia

The only thing to note is that a copy constructor behaves like a real function.
If you have

Code:

foo(A a)

Then the compiler will generate code to make a copy of the object which is passed to foo. It does this by calling the copy constructor. But a copy constructor is a function, like everything else.
So if you have

Code:

A::A(A a)

Then the compiler must generate code to make a copy of the object passed into the copy constructor. And the problem is, of course, that the object's type is the same type as the copy constructor's. So it would invoke A's copy constructor. Again. And so on.

Now take note that references are aliases and not addresses.

Code:

A& a = b;

In this example, a is simply another name for b.
But no copy is made because we're just creating an alias.

So, because the objects type is the same as the object passed to the copy constructor, it will keep calling the same copy constructor.
So which means if i pass by value an object but of a different type. It shouldn't give me an infinite loop, unless they share the same copy constructor - in this case i would be thinking of inheritance... ?


Now take note that references are aliases and not addresses.

In some website i read it says references act like pointers, except the addresses are dereferenced for us, which makes it cleaner. So we can use as local variables. I get your point that they are aliases.

Originally Posted by Eman

So, because the objects type is the same as the object passed to the copy constructor, it will keep calling the <b>same<b> copy constructor.
So which means if i pass by value an object but of a different type. It shouldn't give me an infinite loop, unless they share the same copy constructor - in this case i would be thinking of inheritance... ?

Indeed, so it would invoke that other object's copy constructor, and unless it does something weird, you shouldn't get infinite recursion.

<b>Now take note that references are aliases and not addresses.</b>

In some website i read it says references act like pointers, except the addresses are dereferenced for us, which makes it cleaner. So we can use as local variables. I get your point that they are aliases.

All I can say is that the standard says that they are aliases. Different names for the same object. How the compiler implements references is another matter. That is implementation specific. That is, compiler vendors can choose how they want to do it.

Originally Posted by Elysia

Indeed, so it would invoke that other object's copy constructor, and unless it does something weird, you shouldn't get infinite recursion.

i hope there is no ban on excessive use of smiley, i just can't help it!
Now i truly understand it.

All I can say is that the standard says that they are aliases. Different names for the same object. How the compiler implements references is another matter. That is implementation specific. That is, compiler vendors can choose how they want to do it.

Yeah true. References confused me for a while, i didn't really understand what it meant until I figured out for references to work, they must have the same addresses, no matter how different each compiler optimizes it. Which is why we have to initialize references on declaration, except if references were to be used with function calls.

Em. Does anyone know why a pushing an object into a list invokes the copy constructor?
I just had a glance at the api and noticed it takes a reference to an object. So it shouldn't invoke it, but it does?