Destroying Returned Locals

[Killparadise]

So let's say I have a function that does a simple task of creating a quest.

function questCreator (name, desc, icon, isReq)
  local qst = CreateQuest()
  local req = isReq or false

  QuestSetTitle(qst, name)
  QuestSetDescription(qst, desc)
  QuestSetIconPath(qst, icon)
  QuestSetRequired(qst, req)


  req = nil

  return qst
end

Now as you can see I am returning the quest local I generated, do I need to worry about this creating a memory leak? If so how could I remedy this?

I'm gonna slip in a second question real quick: Is there a performance difference between using GUI triggers, vs regular code ? I know we gain flexibility with going the code route, but I don't want to build everything using code if some is easier to do with the GUI, and there isn't a performance hit.

 

[FUJI]

Now as you can see I am returning the quest local I generated, do I need to worry about this creating a memory leak? If so how could I remedy this?

Yes, it creates a leak because the local handle is not nullified. I don't think you can prevent it as the function already returns it then exit.
Maybe include the object as one of the parameters and reference it via global instead?

I'm gonna slip in a second question real quick: Is there a performance difference between using GUI triggers, vs regular code ? I know we gain flexibility with going the code route, but I don't want to build everything using code if some is easier to do with the GUI, and there isn't a performance hit.

As long you're doing fine in GUI then use it.
However,
some functions can't be accessed on GUI and can only be accessible by JASS.
when translated, you'll notice how many BJ functions are there in the script which is basically a wrapper and slower than using natives directly.
more on clicking than typing (debatable)

There's a performance hit when both coded improperly. Although, there's a lot of variables that influence in-game performance and also vary in circumstances. You shouldn't worry about that leak creation in script above as you can't do anything about it (performance should be negligible in this case in my opinion)

 

[Pyrogasm]

This is unfortunately something you can’t directly avoid. DrSuperGood often refers to this as the “locally declared handle leak on return” bug. As jakeZinc alluded to there are two ways to get around this:

1. Use one of the function’s parameters as your return value.
2. Declare a global variable, set it equal to your local, null the local, and return the global.

//method 1
function ReturnsAUnit takes integer someVal, unit retU returns unit
  //...
  return retU
endfunction

 
//method 2
globals
  unit safeU
endglobals

function ReturnsAUnit takes integer someVal returns unit
  local unit u = ...
  //...
  set safeU = u
  set u = null
  return safeU
endfunction

 

[Dr Super Good]

Now as you can see I am returning the quest local I generated, do I need to worry about this creating a memory leak? If so how could I remedy this?

No leak is created as you appear to be using Lua. One only must null for JASS2, and only until that is fixed.

For JASS2 the work around is to use a global variable to hold the value while it is returned. This global variable can be used by any number of functions for this purpose. In some cases a function parameter can also be used as those do not suffer from the bug. Pyrogasm shows this workaround.

I'm gonna slip in a second question real quick: Is there a performance difference between using GUI triggers, vs regular code ? I know we gain flexibility with going the code route, but I don't want to build everything using code if some is easier to do with the GUI, and there isn't a performance hit.

Writing script directly does allow one to create faster code. However this only matters for performance critical code.

GUI compiles to script on map save. The automatically generated script from GUI is not well optimized, and hence can perform worse than manually written script. Like all optimizations this only matters when a significant amount of time could be saved.

Yes, it creates a leak because the local handle is not nullified. I don't think you can prevent it as the function already returns it then exit.
Maybe include the object as one of the parameters and reference it via global instead?

This only applies to JASS2. Lua does not have this problem.

and can only be accessible by JASS.

Or Lua.

This is unfortunately something you can’t directly avoid. DrSuperGood often refers to this as the “locally declared handle leak on return” bug. As jakeZinc alluded to there are two ways to get around this:

That is only an issue for JASS2.

 

[Killparadise]

Thanks for the responses, and yes all my map code is in lua since I already have a strong understanding of it so I am glad to know this isn't a huge issue with Lua.