February 6, 2018 at 11:14 am #13498
When declaring an external struct, the struct is not reference based. The class will get a reference.
But when calling New() on an Local external struct, shall I manage the memory myself or will it be deleted automatically when out of scope?
Local extStruct:=New ExternalStruct(args)
I suppose that when not calling New() there is no problem..Monkey12Local extStruct:ExternalStructextStruct.someField=someValue
(GCs are great!)
EDIT: made some intensive loops and it doesn’t look like it’s leaking…February 6, 2018 at 9:31 pm #13502
You don’t need to manage ‘new Structs’ as they are always created on the stack and ‘copied’ into whatever var etc you assign them to.
This goes for both pure monkey2 structs and extern structs.February 14, 2018 at 9:11 pm #13636
@admin May I beg the question on what the idiomatic way is for handling memory in Monkey2? I find myself always wanting to do things a bit more like I would in a lower level language and using pointers for certain things and such . . .
Relevant to this case, I might want to create a pointer and point to a struct. Wouldn’t that be okay? I haven’t tried it though, so I don’t even know possible that would be.February 14, 2018 at 10:42 pm #13637
May I beg the question on what the idiomatic way is for handling memory in Monkey2?
Well, the general idea in monkey2 is to use classes/objects for dynamically created, reference style types, and structs for value style types. This is very similar to Java/C#/D etc. For examples of this ‘idiom’, check out the mojo, mojo3d, mojox modules. This way, you get the full benefit of GC and not worry about memory management or pointer lifetimes etc.
You are free to use ‘pointers to structs’ if you want, but then you’ll miss out on GC and have to deal with manual memory management issues – just like a c/c++ coder, whee! But this is effectively programming AGAINST the monkey2 idiom. The goal is for coders to never have to use Ptr unless you are heaving to deal with native code, as use of Ptr leads to all sorts of delightful c/c++ problems. Of course, if you’re the one dealing with native code, you’re kind of stuck, but if you’re writing a c++ lib wrapper module, it would be *nice* if it could be wrapped in such a way that users of the module never have to deal with Ptrs. Alas, realistically this isn’t always possible, but it’s also true many monkey2 moduls/libs (eg: assimp, bullet) could be much more elegantly wrapped.
Relevant to this case, I might want to create a pointer and point to a struct. Wouldn’t that be okay?
Of course, but again it’s up to you to manage the lifetime of the pointer/struct. If you don’t want to have to do this, use an object/class instead. If you don’t want to do this either, perhaps monkey2 isn’t for you?
Not trying to piss you off here, but I do get the impression that you are really trying to use monkey2 as kind of a ‘simple c/c++’ and I think in this respect you’ll always be disappointed. C++ is a huge, complex language, whereas monkey2 is (supposed to be) a small, simple language. There is plenty of c/c++ code out there that is NOT trivial to ‘wrap’ for use with monkey2, and that to wrap ‘properly’ would really require some fairly serious native wrapper code (same goes for many languages that need to wrap c++). It probably doesn’t really help that I added some ways to ‘half ass’ the wrapping process – things like Extends Void etc – but what’s done is done.February 15, 2018 at 8:20 am #13653
Thanks for the delightful insight, Mark! I’m actually not a C/C++ programmer, but I do find myself thinking Monkey2 is supposed to be very much in line with it. But if this is against the idiosyncrasy of the language than I’ll be the first to stop in my tracks and try to follow the correct practices.
What I’m really trying to do is just test the waters on what is appropriate to do given the capabilities of the language. . . Again I’m really only doing things which a more experienced M2 programmer would say “Just because you can don’t mean you should”. So thanks to your response I have a much clearer view of what track I should take to keep on improving my code.
No anger here! Hopefully, I haven’t done that myself to you :). The impression is definitely true I do have this idea, but it is not what I’m trying to accomplish. I just want to use Monkey2 to its fullest potential without going down the wrong track just because it “works” and seems “right”. So all in all, I think it’s really just me taking advantage of the similarities and abusing some of the features you’ve granted us for wrapping purposes. Luckily I haven’t used Monkey2’s C-like capabilities other than to make up for my own bad practices that would eventually bite me in the rear. I’ll take the advice and start working towards what the ideal MX2 code should be!
Starting to read a book right now about “game programming patterns” which I hope will help me structure things more appropriately later on.
Again, thanks, Mark!
You must be logged in to reply to this topic.