No memory leaks?

[Serbianbeast]

New sc2 batch shows us that there will be no memory leaks since it will have uber-efficient garbage collector. Your opinions?

 

[Dreadnought[dA]]

more time working on good stuff rather than clearing leaks

 

[PurplePoot]

I'd rather not trust Blizzard with a garbage collector, so bah.

more time working on good stuff rather than clearing leaks

Because of all that time and effort that clearing leaks took... oh wait, what time and effort?

All it did was force you to think about what you wrote. I'm all for GC, but not for something which likely won't have the bugs ironed out after release.

 

[Serbianbeast]

I only hope that it wouldn't reset some variables to null without us knowing it.

 

[Dreadnought[dA]]

I'd rather not trust Blizzard with a garbage collector, so bah.

Because of all that time and effort that clearing leaks took... oh wait, what time and effort?

All it did was force you to think about what you wrote. I'm all for GC, but not for something which likely won't have the bugs ironed out after release.

I swear you're just like me, a prick 90% of the time, and yes I know that's not a compliment.

 

[BlinkBoy]

as far as they allow you to create static memory like:

mystruct *p = new mystruct;

you'll have to clean it yourself. What I Imagine is that memory created in GUI will be automatically tracked and erased.

Also the garbage collector may work like in this C++ function:

#include <iostream>

using namespace std;

struct node
{
     int x;
     int y;
};

void MyFunc() {
     node n; //The structs and classes in C++ are auto constructed, so declaring
     //group g;, it's JASS equivalent to: local group g = CreateGroup().
     n.x = 20;
     n.y = 10;
     cout<<n.x<<" "<<n.y<<endl; //prints both numbers into command pront
}

int main() {
     MyFunc();
}

once the function finishes, the node n will be erased from memory. The same thing will happen with SC2's garbage collector.

However, if I create the memory instance myself, I'll need to delete it myself:

#include <iostream>

using namespace std;

struct node
{
     int x;
     int y;
};

void MyFunc() {
     node *n = new node; //*n means the variable is a pointer
     n->x = 20;
     n->y = 10;
     cout<<n->x<<" "<<n->y<<endl; //prints both numbers into command pront
     delete n; //we must delete the memory we allocated.
     //n = NULL; //this is unnecessary since n is a local, but if it would be a global, it would need to be nullified.
}

int main() {
     MyFunc();
}

 

[Dreadnought[dA]]

You're probably correct, since when will the code know to get rid of that pointer? Well it still will be nice to not have to:

set a = null
set b = null
set c = null

 

[BlinkBoy]

You're probably correct, since when will the code know to get rid of that pointer? Well it still will be nice to not have to:

set a = null
set b = null
set c = null

actually the reason we nullify in C++ is quite different to the one in jass. Setting a pointer to null is a safe-caution operation so next time we try to use the pointer it points to nothing instead of pointing into some random unknown adress which could cause the program to crash.

Actually it doesn't matter if we nullify a local pointer or not in C++, the garbage collector will automatically erase it as any other local.

 

[PurplePoot]

I only hope that it wouldn't reset some variables to null without us knowing it.

...

I swear you're just like me, a prick 90% of the time, and yes I know that's not a compliment.

No point denying it. But hey, why not?

You're probably correct, since when will the code know to get rid of that pointer? Well it still will be nice to not have to:

set a = null
set b = null
set c = null

That's a separate issue to do with the fact that the Jass VM apparently doesn't distinguish between locals and globals in most cases, so they are not auto freed at the end of a function (which is required for indexes to be recycled; nothing to do with objects).