Possible JKRHeap matches

[ThePlayerRolo]

I found a way to match freeAll and dispose in JKRHeap, which is to have two temp variables for iterator.getObject();

I found this while porting this code to Luigi's Mansion and trying to get it to match.

Admittedly this does feel a little fake matchy, so at the very least this signifies some kind of inline related to get object is running here

[decomp-dev]

Report for GMSJ01 (558eb35 - d2ed9bf)

📈 Matched code: 31.22% (+0.00%, +160 bytes)

✅ 2 new matches

Unit	Item	Bytes	Before	After
mario/JSystem/JKernel/JKRHeap	JKRHeap::freeAll()	+1	99.75%	100.00%
mario/JSystem/JKernel/JKRHeap	JKRHeap::dispose()	+1	99.75%	100.00%

[Mrkol]

Oh shit, it's probably operator-> or operator*, can you try that?

[ThePlayerRolo]

Oh shit, it's probably operator-> or operator*, can you try that?

operator-> doesn't work and idk how to get operator* to work

Heres a scratch to mess around in:
https://decomp.me/scratch/mlTeO

The extra stack could be due to the main code block itself, since its shared in both freeAll and dispose, so maybe it being a seperate function causes extra stack?

[Mrkol]

Oh, it's only stack space... No, this is a fakematch then. The stack space issues are indicative of problems in the itrerator class itself. Also, we have TP debug for this file, so the amount of inlines should be as it is there, theoretically

[ThePlayerRolo]

Oh, it's only stack space... No, this is a fakematch then. The stack space issues are indicative of problems in the itrerator class itself. Also, we have TP debug for this file, so the amount of inlines should be as it is there, theoretically

ah ok, I kinda thought so.

[ThePlayerRolo]

wait I found a better way.

If you do:

JSUListIterator iterator(&mDisposerList);

it matches

https://decomp.me/scratch/mlTeO

This makes much more sense in my opinion, though maybe its still a fake match?