Suppose that a function returns some instance of a class that is statically defined as a local variable in the function body. For example:

MyClass getMyClass(){ MyClass myobject; return myobject; }

The function can be called many times, respectively, in memory there will be many copies of the object. How should I free the allocated memory in this case?

  • > ** statically ** defined as a local variable in the function body. What is it like? I don't see anything static in the code. Please show the place where you allocate the memory you want to free. - mega
  • I do not allocate memory explicitly. But MyClass object is a memory object. What happens if the function is called many times? - DarkGenius
  • 2
    @DarkGenius It is not static. It is automatic, i.e. memory is allocated on the stack, and is released when the function exits. Statically (in the sense of C and C ++, they have a static descriptor and are placed in the data section). - alexlz
  • How will an object become free when exiting a function, if I use the result returned by the function? It turns out, the result can not be used? - DarkGenius

2 answers 2

Inside your function, an object will be created on the stack. At the time of exit in the line with return, the following will occur. The object will be copied (or moved if it is from ++ 11 and everything is correctly described). The original object will be deleted. The question arises - where will it be copied ?. To do this, look at the point of call of this function. It will look like this somewhere.

 MyClass mc = getMyClass(); // 1 случай

or so

 mc = getMyClass(); // 2 случай

or even so

 getMyClass(); // 3 случай

with the third case, everything is clear, most likely the object will not even be copied (just nowhere). There will be no memory leaks.

The second case is simple. We have an object and there is an object that is returned from the function. Your copy constructor should transfer the object carefully.

The first case is interesting because there are two possible options. In the first, an object will be created and then an object with a function is copied into it. In the second - the compiler can guess that the object will need to be copied, and allocate memory for it immediately in the right stack (in the stack of the calling function). In this case, the called function will not allocate memory in its stack, do copying and deleting. And sometimes the compiler does just that. This is a known bottleneck and it is based on the fact that you guarantee the compiler that the copy constructor correctly copies everything.

When do you need to make your own copy constructor? If you wrote your usual constructor, write a copy / destructor constructor. When do you need to be careful with the copy constructor? If the constructor code has nested classes or memory allocation through new (or alloc / malloc and the like. This is of course not much appreciated in C ++ code, but sometimes it is difficult without them).

    allocate memory in the method with new, return the pointer, after using delete, clean (naturally outside the method)

    • Always worth dynamically allocate memory? Just declaring objects as in the function I have given is bad? - DarkGenius
    • one
      Yes, you can not say so bad. Just when returning from getMyClass, the object will be copied. If it suits, then everything is OK. And the problems I wrote about would arise if you returned a pointer to an internal object. There would be a bjaka - alexlz
    • one
      @DarkGenius Another option. Often they do not return a pointer, but pass it as a parameter: class ObjectType {...}; void getObject (ObjectType ** outPtr) {(* outPtr) = new ObjectType (...); } // ... Using ObjectType * obj = nullptr; getObject (* obj); - free_ze