Automatic memory deallocation for CalcSceneView, am I missing something?

Hello!

I was browsing the source for a small project I’m doing and I happened upon the different incarnations of CalcSceneView (LocalPlayer.cpp:640 and some other files).
I was a bit curious to see that we allocate a new heap object at LocalPlayer.cpp:714

FSceneView* const View = new FSceneView(ViewInitOptions);

which we then prepare and then return, handing off the ownership of that heap object to the caller. I’ve been using this function quite a lot, but always kind of assumed that the pointer was managed by the localplayer itself, so I was horrified when I realized I might have been leaking here. I then checked around the source only to find that it is never handled by user code anywhere else in the source either…

First I thought, well, this is probably handled by some automatic memory management scheme, so I looked around to see if I could find any new/delete overrides that might have taken care of this. While there are some (MemoryBase.h, ModuleBoilerPlate.h, UObject.h and some other class specific overrides), none of them seem to do some kind of automatic management (which is scary anyways, so would have surprised me). There is however, another class; Memstack.h which seeems to be some kind of custom-stack for heap-objects, that I wouldn’t be surprised if it was involved if it is indeed managed. All its new overloads take arguments however, and the allocation above does not. I then thought, maybe new is also redefined? It turns out it is in the afx.h pch, but not in a way relevant to this problem as it seems to be for debug purposes (probably to find memory leaks). Also, there are no mirrors for the other platforms (afx.h is the windows naming convention, so I guess this is only for microsoft platforms?)

The object is not an UObject either, so it shouldn’t be subject to garbage collection.

What am I missing? The function and its siblings are being called quite a lot all over the source, but the returned chunk isn’t handled in any of them, so I cannot imagine that it is actually a leak.

Best regards,
Temaran

1 Like

Ah, rubber ducking works again.

I completely overlooked
ViewFamily->Views.Add(View);

nevermind :slight_smile:

/Temaran