Quote:
Originally Posted by whatsup
Sorry for the delay, but i kept thinking and thinking ... 
Point1: Post #35
I basically share your opinion about the application crash on the attempt to Mem_copy something what doesn't match a 4 Bytes Code.
By accident I choose first a range-object (and experienced the crashes), afterwards I changed to a worksheet-object (avoiding crashes I didn't any mem-copy to an object or a variant). I was just looking at the numbers of ObjPtr which are always the same whether you obtain them directly from the object
ObjPtr(Sheet1)
or from the variable
ObjPtr(objwks)
Therefore I wondered, why did excel crash, because even with the variable gone I ask at the end of the Copy of ObjPtr(Range("A1")), and since the Range still exists and hasn't changed, what's the problem to copy it?
It took me a long time to figure out there is a difference between Range and Worksheet:
Whereas Worksheet keeps his pointer throughout the application, this isn't the case with Range. A Range changes its pointer, furthermore the variable (objRange) set to the Range is assigned another pointer.
I said the choice was by accident but actually I'm glad about the choice because otherwise it would have led in a complete different direction... |
I'll have to take some time to think about that, but they are interesting observations...
I'm surprised that the crashMem_Copy routine in my previous post crashes excel because the destination pointer is fine. Why crash when the source pointer is set to zero? Its only a read... Any thoughts?
Quote:
Originally Posted by whatsup
I regret the lack of knowlegde about the architecture of objects and what they look like in memory. I really do, probably it would make things a lot easier knowing about this things.
|
Well, clearly you are not alone! Nobody seems to have any knowledge about this, at least I cant find any.
But your link was very helpful, I've seen the byte comb site before but it was good to be reminded of it, it informed my thinking on this.
Quote:
Originally Posted by whatsup
I would feel more comfortable if evidence would present itself more obvious, for example in just showing only zeros (as it does with a simple class). Why can't excel give a pointer some rest after he did a job 
But Yes, I agree, at least for the moment let's depend on the change. |
It seems to me that the Erase Method in VBS's "garbage collection" system does indeed set the first 8 bytes to zeros. The point is, after a crash and re-start of another routine, a LOT has changed and the space will surely have been used for something else. So the zeros have been over-written.
Quote:
Originally Posted by whatsup
According to Point 4, I agree, memory is freed whether or not the variable is set to Nothing (at least valid for the macros I tried up to now). A surprise to me: Classes are destroyed without explicity destroying them.
|
Yes, I saw from one of your early quotes that you would be surprised about the classes being destroyed and I wanted to give you clear evidence about that and that's why I did the class example.
Its quite simple really, all object life cycle is managed by reference counting: when the reference count goes to zero, the object is scheduled for deletion. There are no no exceptions.
I guess this will be a background process that is run when VBARuntime has free time and it will just scan the reference count field in the object table and "Erase" those with zero reference. The ERASE method will not delete the object from the object table, but it will release any memory used by the object's structure.
Quote:
Originally Posted by whatsup
But I don't agree on this
If you refer to the example with circular references within classes, that's one thing which the example establishes most clearly: None of them get destroyed.
Attached the file including 4 tests - as well the CircRef - with some kind of summary.
|
OK, now we get to the main point
The full quote on this is:
Quote:
Originally Posted by CoolBlue
In summary, I cant see any reason to set local objects to nothing at the end of a sub. Even if there is an error and the sub doesn't complete normally, or if there are structures that fool the reference counting, everything is still cleaned up in the former and the set to nothing does nothing extra in the latter.
|
Sorry, the language is a bit unclear so I've added emphasis...
I am saying that setting to nothing
does nothing extra in these cases. Im saying
it makes no difference. The problem will still be there.
I am arguing
against using set to nothing remember?
As you can see in your example, the result after run-time is the same if you have
Code:
Set objcls1 = Nothing
Or
Code:
'Set objcls1 = Nothing
THAT is my point: you cannot fix these issues with set to nothing. One of the links offered by my friend @macropd as a reason to use set to nothing was referring to these structures and my point was and still is that set to nothing makes no difference.
So, the two points I was trying to argue against are:
- Your second point in post#7
Quote:
Originally Posted by whatsup
- The main reason: There are different types of objects, for instance classes you must unload manually; if creating a new instance of an object (whenever using the keyword "New") you have to unload it manually as well...
|
- The claim by @macropod in post#7 that this link was supporting the use of set to nothing at the end of a sub as a way to manage (for example) objects with circular references.
I think we do agree on those...
And thanks for the attachment... your documentation style is much nicer than mine, I will study it and improve my ways!