Prof. A Olowofoyeku (The African Chief) wrote:
On 21 Mar 2001, at 16:15, Maurice Lombardi wrote:
Yes, it does - but I am not sure which destructor you would be calling after such an assignment. Remember that instances of classes are pointers to the objects - so in the assignment, what you are moving around are pointers, and there may be gotchas there.
But as far as I remember delphi knows the actual type of an object at run time from the address of the VMT (there is one VMT for each defined object type) which he recovers at a fixed displacement from the address given by the object pointer.
Well, the example code causes an exception at the point where you call "h1.free" (if you do the assignment "h1 := h2"). This happens both under Delphi and Virtual Pascal (which is Delphi-compatible). So there is obviously an issue there.
yes but that's because in this code you do two free's. After the assignment h1 and h2 point to the same location. You then can do only one free (h1.free or h2.free), in any order. The exception arises only on the second free because the second pointer points then to nowhere.
Cheers, Maurice
On 21 Mar 2001, at 18:20, Maurice Lombardi wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
On 21 Mar 2001, at 16:15, Maurice Lombardi wrote:
Yes, it does - but I am not sure which destructor you would be calling after such an assignment. Remember that instances of classes are pointers to the objects - so in the assignment, what you are moving around are pointers, and there may be gotchas there.
But as far as I remember delphi knows the actual type of an object at run time from the address of the VMT (there is one VMT for each defined object type) which he recovers at a fixed displacement from the address given by the object pointer.
Well, the example code causes an exception at the point where you call "h1.free" (if you do the assignment "h1 := h2"). This happens both under Delphi and Virtual Pascal (which is Delphi-compatible). So there is obviously an issue there.
yes but that's because in this code you do two free's. After the assignment h1 and h2 point to the same location. You then can do only one free (h1.free or h2.free), in any order. The exception arises only on the second free because the second pointer points then to nowhere.
You are right of course. But that is still one of the "gotchas" that one needs to bear in mind, although it is a different one from the one that I had in mind at the time. And furthermore you cannot then be sure that there are no memory leaks - you have constructed two objects and allocated memory and resources for both of them, and you are only freeing one of them. That sounds like a memory leak to me, unless I am missing something.
Best regards, The Chief --------- Prof. Abimbola Olowofoyeku (The African Chief) Author of Chief's Installer Pro for Win32 Email: African_Chief@bigfoot.com http://www.bigfoot.com/~african_chief/
Prof. A Olowofoyeku (The African Chief) wrote:
On 21 Mar 2001, at 18:20, Maurice Lombardi wrote:
Prof. A Olowofoyeku (The African Chief) wrote:
On 21 Mar 2001, at 16:15, Maurice Lombardi wrote:
Yes, it does - but I am not sure which destructor you would be calling after such an assignment. Remember that instances of classes are pointers to the objects - so in the assignment, what you are moving around are pointers, and there may be gotchas there.
But as far as I remember delphi knows the actual type of an object at run time from the address of the VMT (there is one VMT for each defined object type) which he recovers at a fixed displacement from the address given by the object pointer.
Well, the example code causes an exception at the point where you call "h1.free" (if you do the assignment "h1 := h2"). This happens both under Delphi and Virtual Pascal (which is Delphi-compatible). So there is obviously an issue there.
yes but that's because in this code you do two free's. After the assignment h1 and h2 point to the same location. You then can do only one free (h1.free or h2.free), in any order. The exception arises only on the second free because the second pointer points then to nowhere.
You are right of course. But that is still one of the "gotchas" that one needs to bear in mind, although it is a different one from the one that I had in mind at the time. And furthermore you cannot then be sure that there are no memory leaks - you have constructed two objects and allocated memory and resources for both of them, and you are only freeing one of them. That sounds like a memory leak to me, unless I am missing something.
Right, but it is a programming error the way the program has been written. The correct way would be to free h1 before assigning it a new value, or to keep the corresponding address in an other pointer, otherwise the location it was pointing to before the affectation is lost. But this is of no consequence on the original issue. There is a well defined way to free correctly at run time the content of an object. Hope this helps
Maurice
On 21 Mar 01, at 19:53, Maurice Lombardi wrote:
You are right of course. But that is still one of the "gotchas" that one needs to bear in mind, although it is a different one from the one that I had in mind at the time. And furthermore you cannot then be sure that there are no memory leaks - you have constructed two objects and allocated memory and resources for both of them, and you are only freeing one of them. That sounds like a memory leak to me, unless I am missing something.
Right, but it is a programming error the way the program has been written. The correct way would be to free h1 before assigning it a new value, or to keep the corresponding address in an other pointer, otherwise the location it was pointing to before the affectation is lost.
Of course ...
But this is of no consequence on the original issue.
Correct. The original issue is how the compiler would know at compile time what the type of an object is so as to generate a compile-time error with "is" and "as", and my original example was only for the purpose of demonstrating that it is easy for the compiler to know this, and that, indeed, it should know this. But then we all went off on other tangents ...
An old Chinese saying: "do not go off on a tangent, because tangents can bite you" (actually, I just made that up ;)).
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) Author of: Chief's Installer Pro for Win32 http://www.bigfoot.com/~African_Chief/chief32.htm Email: African_Chief@bigfoot.com
-
Maurice Lombardi -
Prof Abimbola Olowofoyeku -
Prof. A Olowofoyeku (The African Chief)