Not sure exactly which part you are talking about however:

- C++ memory is deleted with the 'delete' operator manually, or using reference counting

- Lua has automatic garbage collection for unused data
- LuaPlus I believe only holds on to a handle of a Lua object, so long as the object is still referenced in script, I don't think it will be deleted.

Now you say ScriptProcess which I don't remember there being in GCC, however if it is a process handled by the process manager, it will be deleted when the process is either SUCCEEDED, ABORTED, or FAILED, and when any references to the shared_ptr are released.

The process system doesn't use smart pointers. When you create a process, whether it's a script process or any other kind, the ownership of that object gets passed to the process manager.

The ScriptProcess is a bit different because it also has a Lua component. There's a member in ScriptProcess called m_self, which is a LuaObject and represents the instance table for the Lua side of things. This counts as a reference to that instance table and as long as the LuaObject exists, the Lua instance will exist as well.

Now, when you call Succeed(), Fail(), or Abort() or on the process, the C++ side is destroyed. This will cause the m_self object to go out of scope and call its destructor, which decrements the ref count. If this ref count drops to 0, the garbage collector will collect the Lua instance and free that memory.

There is a caveat to this. The Lua side is only destroyed when all references to the Lua instance are gone. That means you can't hold onto a reference to the ScriptProcess object or the Lua side won't be destroyed. This is potentially dangerous. If you call Succeed() twice on the Lua object, it will work the first time and probably crash the second time, since it will be accessing invalid memory.

The correct way to use processes is in a fire-and-forget manner. You are not meant to hold onto references to the process objects, you are meant to instantiate a process and pass ownership completely to the process manager. The process should be completely self-contained. If you do need to talk to the process, the correct way to do it is with an event. This holds true for the ScriptProcess as well; you shouldn't keep a reference to it anywhere.

Incidentally, that's why I don't have processes use smart pointers.

-Rez

For transferring ownership and not risking memory leaks, use a unique_ptr. Of course this means adding appropriate move semantics to a lot of things, but I'm saying this just to defy Rez's "Don't use smart pointers" statement

James

Sure, if you want to incur the performance cost of unique_ptr. Or you could just correctly destroy memory like a big boy.

-Rez

Originally posted by rezination
Sure, if you want to incur the performance cost of unique_ptr. Or you could just correctly destroy memory like a big boy.

-Rez

lol...thats all

Originally posted by rezination
Sure, if you want to incur the performance cost of unique_ptr. Or you could just correctly destroy memory like a big boy.

-Rez

If I remember correctly, in this video from Stephen Lavavej, he says that in most cases unique_ptr has no performance cost due to optimizations:
channel9.msdn.com/Series/C9-Le…mplate-Library-STL-3-of-n

unique_ptr should just be a really simple wrapper, so I'd be very surprised of any noticeable cost. shared_ptr on the other hand apparently uses an atomic increment, so pass it by const reference

James

Oh I know, I was just poking fun at you.

When I talk about my dislike of smart pointers, I am specifically talking about shared_ptr and weak_ptr. Those should be avoided unless it makes architecural sense, such as in the case of the actor system in GCC. They are generally very slow and are often used incorrectly.

unique_ptr is useful when you have a single, unique owner for an object and need to transfer that ownership around (or even without transferring ownership). For example, factories can often return unique_ptr. unique_ptr can add some overhead, but it's pretty minuscule and not worth worrying about unless you're really doing some heavy optimizations (which you probably shouldn't be doing).

There's one thing that unique_ptr does that makes it especially worth while: it communicates your intention to other engineers. If I see a function returning a unique_ptr, I know pretty quickly that I am receiving ownership whatever it's returning.

This is definitely a pattern you want to follow.

-Rez