You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way BS handles memory management does allow for forgetful programmers to leak memory, but a conscientious BS programmer would simply learn to call Delete on all variables and not have any issues. You could even have a linting tool to catch these leaks. Perhaps someone would create a NoBS language that transpiles to BS which inserts Deletes.
But I do see some opportunities to include the worst parts of both manual and automatic memory management.
One of the challenges with manual memory management is that it's not always clear if ownership is transferred or retained. For example:
char * getObject(int key);
Does the caller need to free the memory returned by this function or not? There's no way to tell without looking at the implementation or trusting the documentation. If you're supposed to free it and you don't, then memory leaks occur. If on the other hand, the object is retained in a global cache, deleting it can cause random behavior.
You should attempt to emulate this behavior. Whether or not a variable should be Deleted or not should hinge on how it was used when it was first declared. Perhaps you can obfuscate this. For example, if the function that originally declared the variable references the variable AFTER it was passed to a function, then the function that receives it should NOT call Delete. If the receiving function does incorrectly call Delete, then a timer should be triggered which will cause a division by zero error at some random point between one hour and one year.
On the other hand, you can get a memory leak in languages like Javascript if your global event handlers refer to objects that you want to be collected (since it has no concept of weak references). I think there should be a clever way to handle this - say having Delete do nothing at all if a variable is referred to three times within the same function, or if it's passed more than two levels deep.
The text was updated successfully, but these errors were encountered:
The way BS handles memory management does allow for forgetful programmers to leak memory, but a conscientious BS programmer would simply learn to call
Delete
on all variables and not have any issues. You could even have a linting tool to catch these leaks. Perhaps someone would create a NoBS language that transpiles to BS which insertsDelete
s.But I do see some opportunities to include the worst parts of both manual and automatic memory management.
One of the challenges with manual memory management is that it's not always clear if ownership is transferred or retained. For example:
char * getObject(int key);
Does the caller need to free the memory returned by this function or not? There's no way to tell without looking at the implementation or trusting the documentation. If you're supposed to free it and you don't, then memory leaks occur. If on the other hand, the object is retained in a global cache, deleting it can cause random behavior.
You should attempt to emulate this behavior. Whether or not a variable should be
Delete
d or not should hinge on how it was used when it was first declared. Perhaps you can obfuscate this. For example, if the function that originally declared the variable references the variable AFTER it was passed to a function, then the function that receives it should NOT call Delete. If the receiving function does incorrectly call Delete, then a timer should be triggered which will cause a division by zero error at some random point between one hour and one year.On the other hand, you can get a memory leak in languages like Javascript if your global event handlers refer to objects that you want to be collected (since it has no concept of weak references). I think there should be a clever way to handle this - say having Delete do nothing at all if a variable is referred to three times within the same function, or if it's passed more than two levels deep.
The text was updated successfully, but these errors were encountered: