Returning a class pointer from a function

"I want to return a pointer to a class from a function"

You can't return a pointer to a class. You can return only a pointer to a tangible object of the class. An object is instantiated in memory. A class is just the logical template which is used to create an object.

return newUdo;  //this is where the pointer created on the heap is being returned

Only thing is you need to be careful to release this memory pointed to by this pointer when the memory is no longer used.

but you need to remember that you are doing this inside the member function of another class. Ensure that you include the correct header file.....

so you could do this

Class2* Someclass::afn( )
{
  Class2* p = new Class2;

  return p;
}

remember to release the memory pointed to by p. And always check for NULL before using the pointer.

>> "I want to return a pointer to a class from a function"

>> You can't return a pointer to a class. You can return only a pointer to a tangible object of the class. >> An object is instantiated in memory. A class is just the logical template which is used to create an >> object.

Thank you for you answer, however I did ask for those who would answer to refrain from pedanticism.  I am aware of a class being a template and not a concrete instance.  The distinction has little to do with the question being asked.

>> Class2* Someclass::afn( )
>> {
>>   Class2* p = new Class2;
>>
>>  return p;
>> }

>> remember to release the memory pointed to by p. And always check for NULL before using the
>> pointer.

So when p goes out of scope how is the instance of the class affected?  Does it continue to exist in memory since it has not been deleted, and as such the memory address that is being passed back remains valid?  Or is there something else going on under the covers?

Thanks.

>> Class2* Someclass::afn( )
>> {
>>   Class2* p = new Class2;
>>
>>  return p;
>> }

>> So when p goes out of scope how is the instance of the class affected?
The instance is not affected. It remains in the heap.

>> as such the memory address that is being passed back remains valid?
If you have ptr = afn(); then ptr is now pointing to the valid instance.

If later you wish to delete this instance, you can delete ptr; followed by ptr = NULL;
But if you did  ptr2 = ptr; delete ptr; ptr = NULL;, now you have ptr2 still holding the address of the instance which is now invalid. So, if you dereference ptr2, you may start seeing bugging things happening.

however I did ask for those who would answer to refrain from pedanticism

Then you shouldn't be on EE. And besides your query is of a fundamental truth which seeks a pedagogic reply.


So when p goes out of scope how is the instance of the class affected?  Does it continue to exist in memory since it has not been deleted, and as such the memory address that is being passed back remains valid?  Or is there something else going on under the covers

The memory is valid since it has been created on the heap and not on the stack. If it were created on the stack then the pointer would be pointing to memory which has been released. This is the basic difference between memory allocated on a heap and that on a stack. So not releasing this could result in a memory leak.
This is a fundamental concept not limited only to C++


So

Class2* Someclass::afn( )
{
  Class2* p = new Class2;

  return p;
}

outside afn() the pointer variable 'p' goes out of scope meaning to say you can't use the same pointer variable 'p' in another function. Ofcourse you can always create another variable named 'p' having a different scope

However the memory pointed to by 'p' is still not invalidated and has not been released. So when I returned the pointer from the function it is nothing but the address of this valid area of memory.
Use this address wherever you want.

So

Class1::Somefn()
{
Class2* ptrcopy = afn();
...

...

..
}

If you understand this , you understand memory leaks and what causes them.

As for using default copy constructors, dangling pointers these are once again fundamental issues.

Could try something like this

class MyClassFactory
{
    public:
	static int obj_counter;
	MyClass* getInstance( );
};

 MyClass* MyClassFactory::getInstance()

 {
	obj_counter++;
	return new MyClass();
 }

Select allOpen in new window

in factory pattern the new operation was made by a static or virtual member function of the class which needs to get factured. so you can derive a new class and can provide functionality for factory pattern with that class not needing any second class to add code.

Sara

@trinitrotoluene
>>>> however I did ask for those who would answer to refrain from pedanticism

>> Then you shouldn't be on EE. And besides your query is of a fundamental truth which seeks a
>> pedagogic reply.

No it really doesn't.  Your comment regarding instance versus template does not go to the heart of the question which is returning a pointer.  Pedanticism is just irritating and egotistic.

@evilrix

>>>> I have run into so far including default copy constructor issues, scope problems, memory leaks
>>>>  and dangling pointer leaks to name a few.

>> Not sure why you have issues with copy-constructors since you are passing around a pointer to
>> an object rather than the object itself. The issues with memory leaks and dangling pointers can
>> easily be resolved by using smart pointers rather than returning raw pointers that need to be
>> managed and cleaned up. The following article goes into more detail about smart pointers and even
>> provides a simple referenced counted implementation you could use. It also introduces the Boost
>> shared_ptr, which is a tool every C++ programmer should have in their toolkit.

True.  Badly worded.  I should have said that I got into the forest and lost the trees on that remark.  I got so into issues that might arise as I was writing the function that I lost sight of the bigger picture.

@sarabande

>> i think returning a pointer newly created in a function which is not member function of the class
>>  itself is bad design. there might be exceptions like with smart pointers or with factory classes but
>> in my opinion the 'new' operation should be on same design level as the 'delete' operation what
>> would be not the case for the sample code you posted and what probably is the cause for the
> problems you have with the approach.

Very true.  Again I had blinders on a single approach.  Thank you for your thoughts.

edc,

It's easy to get side-tracked when struggling with a frustrating problem. I know, I am the worse :)

I hope things are now clearer for you but please do post back here if you need any further assistance on this.

All the best.

-Rx.

Hi evilrix. Thanks very much.  I appreciate the note. The EE community is always good at bringing me back to the central point and pointing out better ways to approach the problem, and I will certianly post again when I get myself bound up in thoery :o).