Free'ing Unowned Space

[Volatile Pulse]

So, I was tinkering with some code I decided to write and came across a dumb idea. What if we "new" an object without assigning it.

Does it automatically get free'd (I doubt that's the case)?

Does the space still get taken up (I believe if I understand how new works, this is definitely a yes)?

I understand this is probably the biggest no no ever, but here is a sample code that I was thinking about:

int main() {
   // typical new call
   int *myInt = new int;
   // theoretical new call
   new int;

   // typical delete
   delete myInt;
   // How do you delete the other int?
}

Edit: To make this a little more obvious, I was wondering if there was a way to get the locations of every block of memory in a program and delete it manually (just in case there happened to be an unassigned new call).

[helios]

Does the space still get taken up?

Yes.

How do you delete the other int?

You can't. That memory is leaked.

I was wondering if there was a way to get the locations of every block of memory in a program and delete it manually

Every block of memory would include the memory being used by constants and by code. So if there was a way to do this, it would be equivalent to terminating.
There's simply no way to definitely fix memory leaks at run time.

[Volatile Pulse]

So if I have a function that returns a pointer and another code fails to assign that returned pointer, there is no way to prevent them from compiling?

I'm trying to design a class system that generates a random polymorphism object and returns one of them randomly. Obviously I can't manually delete it before returning it, would I have to create a garbage collector system within the class to ensure that the memory is freed correctly?

[helios]

there is no way to prevent them from compiling?

Nope. None at all. A static analyzer could be able to detect something like that, though.

I'm trying to design a class system that generates a random polymorphism object and returns one of them randomly. Obviously I can't manually delete it before returning it, would I have to create a garbage collector system within the class to ensure that the memory is freed correctly?

Can't you just delete f();?
Proper garbage collection in native code is impossible because there's no way to tell pointers from non-pointers by just looking at memory. There are some conservative GCs that when in doubt, assume that what they're looking at is a pointer.

[Volatile Pulse]

By garbage collector, I just meant like a list of all of the pointers my class creates. When the class dtor is called, couldn't it effectively free all of those spaces? Or would that cause issues if the other coder tries to free them as well?

How can you delete a function? If the function returns a pointer and it's not assigned, what good would deleting the function do? Wouldn't it essentially just free the space the pointer was taking up? Wouldn't that also assume that the other programmer knows better?

I'd like to assume that anyone that uses the class would know how to use it, but I was wondering if I could make it dummy proof.

[naraku9333]

Personally I wouldn't over think it. Just either put in documentation that returned pointers need to be manually deleted or write a cleanup function that must be called.

[BlackSheep]

Why not return a shared pointer?

[helios]

By garbage collector, I just meant like a list of all of the pointers my class creates. When the class dtor is called, couldn't it effectively free all of those spaces? Or would that cause issues if the other coder tries to free them as well?

Whether this makes sense or not depends on how your code is structured. In any case, this doesn't solve the problem of leaking memory. At best, you can free those pointers just before the program exits, but if your system was made in the last ten years it will do that anyway. It's not much of an improvement, particularly if the program leaks memory at regular intervals.

Wouldn't it essentially just free the space the pointer was taking up?

Isn't that what you're trying to do?

Wouldn't that also assume that the other programmer knows better?

I'd like to assume that anyone that uses the class would know how to use it, but I was wondering if I could make it dummy proof.

We keep trying to make our software foolproof. The problem is that the universe keeps coming up with bigger fools.
Expecting the user to know that they have to free the resources you hand them is perfectly acceptable (as long as you document it, of course). If they don't, well, that's their problem.

[zb0S216C]

Volatile Pulse wrote:

"How do you delete the other int?"

To expand on helios's initial reply, because you do not know the address of the unnamed int, you're unable to release the memory associated with it. When the address of an allocated variable/object is not known by the program, it'll begin to leak until the operating system takes care of it. However, on legacy systems, such leak-detection systems do not exists, and the leak will continue until it consumes all the resources it can.

_Wazzak

[Peter87]

Instead of returning a raw pointer you could return a unique_ptr.

std::unique_ptr<int> f()
{
	return std::unique_ptr<int>(new int);
}

std::unique_ptr<int> p = f(); // no leak
f(); // no leak