Instantiating / allocating objects via scripts

[nofish]

say

faststring = reaper.SNM_CreateFastString()
env = reaper.BR_EnvAlloc()

-- scripter does unexpected stuff
-- script errors out here and below is never called

reaper.SNM_DeleteFastString()
reaper.BR_EnvFree()

Does this produce a memory leak?
Asking because I'm thinking about doing something similar in SWS, or should it be avoided?
Essentially I'd like to return a variable sized (determined at runtime) array of doubles. It's already basically working but if it's rather bad practice...

[Xenakios]

It leaks. The "delete", "free" and "destroy" functions are not provided for entertainment purposes.

Unfortunately this C-language style scripting is how Cockos decided to go with the ReaScript API.

What exactly are you planning to do? Is using the reaper.new_array function not an option? The array returned by that has special handling where it will be automatically cleaned up when it is no longer needed. It has the downside that the maximum allocation that can be done is around 4 million doubles.

[nofish]

Thanks.
What I'm doing is a multichannel peak/RMS analyzer:



I've heard about reaper.new_array (via js's extension) but I'm a bit hesitant to use (apart from I don't know currently how to use it) because:

https://forum.cockos.com/showthread.php?p=2040152

[Xenakios]

Originally Posted by nofish

I've heard about reaper.new_array (via js's extension) but I'm a bit hesitant to use (apart from I don't know currently how to use it) because:

https://forum.cockos.com/showthread.php?p=2040152

Oh, well...I did figure out a way to use it and nothing has blown up so far. The unusual bit about the new_array thing is that it will be an array of doubles one element longer than requested and the first element contains the length of the array. So in script code you can't do arr[0]=something because that would overwrite the length data. (The script will just give a runtime error if you attempt that.) Similarly, on the C or C++ side of things, you have to take into account the first element contains the length data.

Anyway, it looks like you already have a dedicated object type for your analysis that you want to be using, so you should just use that and live with the fact that errors in the script code may end up leaking them. Reaper's new_array arrays are of course intended just for dealing with arrays of numbers. (Though with some creative hacking I suppose C++ objects could be put inside them... That would only work for objects where you could live with the destructor not being called, so that would be of limited use.)

It would be useful to try to figure out if there's any way at all to deal with the potential leaks. Maybe atexit could be used? Or Lua's pcall mechanism?

[nofish]

Originally Posted by Xenakios

Anyway, it looks like you already have a dedicated object type for your analysis that you want to be using, so you should just use that and live with the fact that errors in the script code may end up leaking them.

Well yes it does work but I'm not so happy about the potential leaking that's why I'm checking out other possibilities.
I guess the potential leaking is exactly what Justin referred to here (about FastStrings) and last thing I wanna do is annoy Justin.

Reaper's new_array arrays are of course intended just for dealing with arrays of numbers. (Though with some creative hacking I suppose C++ objects could be put inside them... That would only work for objects where you could live with the destructor not being called, so that would be of limited use.)

That be fine in my case as it's only about returning the peak/RMS arrays.

It would be useful to try to figure out if there's any way at all to deal with the potential leaks. Maybe atexit could be used? Or Lua's pcall mechanism?

If there is a way (haven't checked yet) it'd still to be done from the scripters side I think, i.e. still not 100% bullet proofed.

I think I'll do a FR about an official ('non hackish') way about passing arrays between scripts / extensions and also have a look about reaper.array (I've seen its usage when having a brief look in the new extension source).
May ask for a bit of coding help when the time comes...

[Justin]

Originally Posted by Xenakios

Unfortunately this C-language style scripting is how Cockos decided to go with the ReaScript API.

Hmm those are sws functions -- most of our APIs don't leak (reaper.new_array() etc). Having said that, it might be possible to get PCM_sources to leak, so one should be careful there. But in general we've tried to avoid ownership issues.

[nofish]

I went with reaper.new_array() in the end (instead of allocating an own object), so I hope it's ok.

Btw. speaking of reaper.arrays
https://forum.cockos.com/showthread.php?t=212695