Using standard c/c++ classes and explicit memory management in ENIGMA

[CCJ]

Hi all,
Is it possible to include standard c/c++ classes in ENIGMA in addition to or instead of EDL?  If possible I'd prefer to code in straight c++ using the ENIGMA API functions, rather than scripting in EDL.  Also, is explicit memory management via malloc/free and new/delete supported in EDL?  I'm not sure how Game Maker handled memory, but I hope ENIGMA allows developers to take the reins with application memory rather than relying on a garbage collector.  Specifically, what exactly is the code equivalent of the drag and drop 'destroy instance' icon in ENIGMA?  Is the memory freed immediately or simply marked as eligible for reclamation by a GC?

thanks,
CCJ

[TheExDeus]

If possible I'd prefer to code in straight c++ using the ENIGMA API functions, rather than scripting in EDL.

That's the plan. You will be able to use most if not all C++. EDL will just allow additional cool things to make coding faster and easier. Almost every aspect of C++ is in already.

Specifically, what exactly is the code equivalent of the drag and drop 'destroy instance' icon in ENIGMA?

Just like in GM its: instance_destroy().

Is the memory freed immediately or simply marked as eligible for reclamation by a GC?

I think its freed immediately, although looking at the code it seems to unlink it for GC.

[Rusky]

EDL is translated directly to C++, so as long as you can do what you want with it there's no need to worry about efficiency. There is also no garbage collector in either GM or ENIGMA, and explicit new/delete is generally a bad way to manage memory.

[Josh @ Dreamland]

To expand on what has been said, all C++ functions are game in ENIGMA provided you include them from Definitions, which IsmAvatar will be adding to the resource tree as an instantiable resource shortly. EDL is very similar to C++, but you must configure some settings to use otherwise ambiguous operators (such as ++). Currently, the string behavior setting is broken.

Instances are not freed immediately; their iterators are unlinked and any open iterators are updated to be kept valid. The instance is then added to a set for deletion at the end of the step. This way, you can do asinine garbage like with (a) { instance_destroy(); instance_create(x,y,obj_explosion); } without tripping any access violations.

The new parser I am working on will correctly integrate the new C++ syntax features. Presently, member access is limited due to the dynamic nature of GML, and ternary expressions can often cause compile error if you mix types in them (expression? var : int gives an ambiguous cast error, because var can cast to int as well as construct from int).

[CCJ]

thanks all for the informative replies!

Instances are not freed immediately; their iterators are unlinked and any open iterators are updated to be kept valid. The instance is then added to a set for deletion at the end of the step. This way, you can do asinine garbage like with (a) { instance_destroy(); instance_create(x,y,obj_explosion); } without tripping any access violations.

ah, sounds good 

explicit new/delete is generally a bad way to manage memory

@Rusky: could you elaborate please?  If not with malloc/free and new/delete, how should memory be managed? 

[luiscubal]

Consider the following code:

Code: [Select]

MyClass foo; //the constructor of foo is called automatically
//do something with foo

In the case above, the variable "foo" is automatically destroyed when it goes out of scope.

With explicit new, it's very easy to forget an edge case and miss a "delete", which results in a memory leak.
Additionally, variables allocated as shown above("on the stack") tend to be friendlier to the computer(due to relatively advanced stuff like CPU cache, overhead of memory allocation and memory fragmentation) than data allocated with new("on the heap").
Finally, classes allocated on the stack are automatically constructed. The same does not apply to pointers. If you forget to add "= new MyClass()" after the pointer declaration, then using that pointer is undefined behavior.

There are, indeed, cases where variables allocated on the stack are not appropriate, and then "new"/"delete" is indeed an option, but there are also other classes provided by C++(known as "smart pointers") that make memory easier to manage.

In short, explicit new/delete is harder to use, slower and makes it easy to make critical mistakes.

[Josh @ Dreamland]

...

[luiscubal]

Hey, Josh, you have your computer on Mute. Enable the sound again so we can hear what you're saying.

(Because, y'know, an ellipsis is not a very constructive comment)

[Rusky]

In Josh's terms, using classes like vector that do the new/delete for you requires less typing.

Also if you use exceptions, you kind of have to avoid vanilla new/delete because otherwise memory will leak.