Code segment unload: Difference between revisions

Added FreeBASIC
(Added FreeBASIC)
 
(3 intermediate revisions by 3 users not shown)
Line 8:
=={{header|BASIC}}==
Some versions of basic have the facility to delete lines of code:
<langsyntaxhighlight lang="gwbasic">10 GOSUB 5000: REM call initializer
20 DELETE 5000-9999: REM delete initializer
30 PRINT A: REM show initializer worked
Line 16:
5000 REM this is a dummy initializer
5010 LET A=1
5020 RETURN</langsyntaxhighlight>
 
=={{header|COBOL}}==
The <code>CANCEL</code> statement in COBOL unloads from memory the dynamically-loadable module containing the specified program or entry-point.
<langsyntaxhighlight lang="cobol">CANCEL "foo"</langsyntaxhighlight>
 
=={{header|FreeBASIC}}==
In FreeBASIC, there is no direct way to unload an unused section of code from memory. However, you can free memory used by variables or data.
 
Here's an example of how you could do it:
 
<syntaxhighlight lang="vbnet">DIM AS INTEGER PTR p
p = CALLOC(100, SIZEOF(INTEGER)) ' Reserve memory for 100 integers
 
'Use memory...
 
DEALLOC(p) ' Free the memory
p = NULL ' Ensures that the pointer does not point to a freed memory location
</syntaxhighlight>
 
=={{header|Furor}}==
The <code>neglect</code> statement in Furor deletes from memory the named function. It is possible because each function is loaded into a dinamycally allocated memory segment.
<syntaxhighlight lang ="Furor">foo neglect</langsyntaxhighlight>
 
=={{header|Go}}==
Line 32 ⟶ 46:
 
=={{header|Io}}==
<langsyntaxhighlight lang="Io"># Call anonymous block to do the initialization.
 
block(
Line 42 ⟶ 56:
 
writeln("Doing real work.")
// Code to do the real work here.</langsyntaxhighlight>
 
{{output}}
Line 113 ⟶ 127:
;Releasing commands
:The memory associated with a particular command can be released back to the general memory pool by deleting the command. This is done by either creating a new command with the same name, or by using <code>rename</code> to change the command's name to the empty string.
:<langsyntaxhighlight lang="tcl">rename exampleCmd ""</langsyntaxhighlight>
;Releasing loaded extensions
:The memory associated with a loaded extension can be released by using <code>unload</code>, provided the extension has registered a handler function (this is relatively uncommon). Once the handler function has run (which gives the extension an opportunity to destroy any commands and other callbacks it has created), the underlying library will be removed from memory with <code>dlclose()</code> (on Unix) or <code>FreeLibrary()</code> (on Windows). This ''completely'' removes the program code concerned, as well as returning the other ancillary memory to the general pool.
:<syntaxhighlight lang ="tcl">unload theLibrary.dll</langsyntaxhighlight>
;Releasing an entire interpreter
:Provided an interpreter is not the ''root'' interpreter in its thread, you can delete it from an ancestor interpreter, which releases all the memory associated with it back into the general memory pool.
:<syntaxhighlight lang ="tcl">interp delete theChildInterpreter</langsyntaxhighlight>
 
=={{header|Wren}}==
It is not currently possible to unload code from a running Wren script.
 
However, what you can do is to place code that will only be run once, such as initialization code, into a function and then call that. Functions (as opposed to class methods) are first class objects in Wren and will be garbage collected when there are no longer any references to them. This doesn't usually occur immediately but you can request an immediate collection by calling the ''System.gc'' method.
{{omit from|360 Assembly|Depends entirely on the hardware implementation}}
{{omit from|6502 Assembly|Depends entirely on the hardware implementation}}
{{omit from|6800 Assembly|Depends entirely on the hardware implementation}}
{{omit from|68000 Assembly|Depends entirely on the hardware implementation}}
{{omit from|8051 Assembly|Depends entirely on the hardware implementation}}
{{omit from|8080 Assembly|Depends entirely on the hardware implementation}}
{{omit from|8086 Assembly|Depends entirely on the hardware implementation}}
{{omit from|AArch64 Assembly|Depends entirely on the hardware implementation}}
{{omit from|ARM Assembly|Depends entirely on the hardware implementation}}
{{omit from|AWK}}
{{omit from|Brlcad}}
Line 127 ⟶ 154:
{{omit from|Logtalk}}
{{omit from|Mathematica}}
{{omit from|MIPS Assembly|Depends entirely on the hardware implementation}}
{{omit from|MIRC Scripting Language}}
{{omit from|TPP}}
{{omit from|UNIX Shell}}
{{omit from|VAX Assembly|Depends entirely on the hardware implementation}}
{{omit from|X86 Assembly|Depends entirely on the hardware implementation}}
{{omit from|Z80 Assembly|Depends entirely on the hardware implementation}}
{{omit from|ZX Spectrum Basic}}
2,130

edits