[vb.net]Dim en herinitialisatie

[bibawa]

Wanneer je in een subprocedure in vb.net een declaratie doet met dim is deze declaratie enkel bereikbaar binnenin deze subprocedure. Daarbuiten is ze niet meer gekend.

Zo hebben ze het mij altijd geleerd en zo is het ook, maar wanneer je eenmaal buiten de sub bent wordt de variabele dan uit het geheugen verwijderd, of blijjft deze gewoon bestaat tot er een opruiming gebeurt van ongebruikte vars (zoals garbage in java?), en wat als je dan een tweede keer in deze sub zou komen, zitten er in het geheugen dan 2 dezelfde variabelen in of wijzen de pointers van deze dan 2 identieke variabelen naar dezelfde geheugenplaats?

Google is m'n beste vriend maar hier kan ik echt geen deftig antwoord op vinden.
gezocht op:

Dim definition
dim sub
dim subprocedure
dim memory usage
...

[Harm]

Ik heb geen idee hoe het exact werkt, maar mogelijk dat je met de zoektermen 'garbage collection vb.net' al een stuk verder kan komen .

[H!GHGuY]

ik zou eens zoeken hoe een stack werkt.
De lokale variabelen worden op de stack gealloceerd. Eens buiten de scope zijn ze ongeldig en worden ze verwijderd. De volgende keer dat je in de functie komt worden ze opnieuw gealloceerd op de stack.

In VB.Net, waar objecten eigenlijk references (aka pointers in C++ termen) zijn, is een object op de stack niet meer als een pointer naar een stuk geheugen. Wanneer de pointer op de stack verdwijnt is het object niet meer gerefereerd en kan de garbage collector (wanneer ie daar zin in heeft) de boel opschonen.

Een niet-gereferenced object kan je nooit meer referencen (tenzij je met wel hele nasty hax tevoorschijn komt).

Kijk dus best even na wat een stack is, wat een functie-aanroep is en hoe variabelen en objecten gealloceerd kunnen worden.

zie bvb: http://en.wikipedia.org/wiki/Call_stack

[ Voor 3% gewijzigd door H!GHGuY op 24-12-2006 00:05 ]

[Korben]

Value-type variabelen (int, byte, enums, etc.) worden direct op de stack gealloceerd, en worden dus direct gedealloceerd als ze out-of-scope gaan. Een reference type (elke class) wordt van de managed heap gealloceerd, die beheerd wordt door de garbage collector.

Value-types verdwijnen gelijk, dus die zul je nooit meer terugkrijgen als je die Sub opnieuw aanroept, en references ook niet, omdat inderdaad de wel op de stack zit en verdwijnt, en er wordt gewoon een nieuw reference type gealloceerd.

[Verwijderd]

Hallo,

Je moet oppassen bij vb.net als je een grootte applicatie maakt dat je wel alle variabelen opruimt.

Ook de variabelen die out of scope gaan blijven in het geheugen staan. Ookal kun je ze niet meer benaderen.

Dus close alles en zet alles op nothing wat je gebruikt.


Natuurlijk maakt het met een kleine applicatie niet zo veel uit!!

[pjonk]

Verwijderd schreef op maandag 25 december 2006 @ 14:16:
Je moet oppassen bij vb.net als je een grootte applicatie maakt dat je wel alle variabelen opruimt.

Opruimen doet de Garbage collector (GC) voor je wanneer:
- je variabele out of scope gaat
- de reference counter 0 is. Met andere woorden als de variabele niet meer benaderbaar is door andere types in je applicatie. De GC kan dit bepalen door gebruik te maken van complexe algoritmen.
In het algemeen is het een goed idee om de scope van de variabelen niet groter te maken dan nodig is. Dan zal de Garbage collector (GC) kan de variabelen dan sneller opruimen.

Ook de variabelen die out of scope gaan blijven in het geheugen staan. Ook al kun je ze niet meer benaderen.

Gedeeltelijk waar, het opruimen van de variabelen door de GC gebeurt niet deterministisch. M.a.w. je weet niet precies op welk moment het geheugen van de variabelen door de GC wordt opgeruimd. Hierover hoef je je normaal gesproken geen zorgen te bepalen. De GC kan heel goed bepalen op welk moment een Garbage collection het meest efficiënt is.

Dus close alles en zet alles op nothing wat je gebruikt.

Closen (of Dispose) is in sommige gevallen noodzakelijk. Bijvoorbeeld als je bezig bent met FileHandles of Database connecties. Nothing was in VB6 een truukje om de reference count naar beneden te stellen. In .NET is dit ondertussen overbodig geworden.

Natuurlijk maakt het met een kleine applicatie niet zo veel uit!!

Dat is natuurlijk onzin. Ook kleine applicaties kunnen veel geheugen lekken als je je resources niet vrijgeeft.

[Infinitive]

Dat je bepaalde "unmanaged" resources zoals files en database connecties moet vrijgeven met Close is idd correct. Het geheugen zelf is gemanaged, daar is het aboluut niet voor nodig dat je verwijzingen op Nothing zet; daar heb je garbage collection voor. Het ver-nothing-en is zelfs een bad practice:

• maakt je code alleen maar onnodig langer met triviale code (nadeel voor begrijpelijkheid, onderhoud, enz)
• nadelige invloed op performance (hoewel je dat niet zult merken)

[ Voor 4% gewijzigd door Infinitive op 25-12-2006 14:42 ]

[whoami]

pjonk schreef op maandag 25 december 2006 @ 14:32:
[...]

Opruimen doet de Garbage collector (GC) voor je wanneer:
- je variabele out of scope gaat
In het algemeen is het een goed idee om de scope van de variabelen niet groter te maken dan nodig is. Dan zal de Garbage collector (GC) kan de variabelen dan sneller opruimen.

Da's fout. In .NET worden enkel reference types door de GC opgeruimd. Echter, je weet nooit wanneer die GC zijn run gaat doen. Dat hangt van allerlei omstandigheden af. Het is echt niet zo dat hij direct in actie treedt om bepaalde variablen (ref types) op te ruimen die out of scope zijn.

Een value type die out of scope gaat, wordt wel direct van de stack verwijderd. De referenties naar een reference type (die referenties staan ook op de stack), worden natuurlijk ook direct opgeruimd, maar daar heeft de GC niets mee te maken.

Gedeeltelijk waar, het opruimen van de variabelen door de GC gebeurt niet deterministisch. M.a.w. je weet niet precies op welk moment het geheugen van de variabelen door de GC wordt opgeruimd. Hierover hoef je je normaal gesproken geen zorgen te bepalen. De GC kan heel goed bepalen op welk moment een Garbage collection het meest efficiënt is.

Dit is dan weer wel juist, maar hier spreek je jezelf tegen tov je eerste stukje.

[whoami]

Verwijderd schreef op maandag 25 december 2006 @ 14:16:
Hallo,

Je moet oppassen bij vb.net als je een grootte applicatie maakt dat je wel alle variabelen opruimt.

Als een value type out of scope gaat, wordt ze opgeruimd.

Ook de variabelen die out of scope gaan blijven in het geheugen staan. Ookal kun je ze niet meer benaderen.[/]
Reference types blijven op de heap staan, ook al worden ze niet meer gereferenced.

[MLM]

value-type bevinden zich op de stack, dus grote kans dat het geheugen weer hergebruikt wordt toch (ie. opruimen is niet nodig)

voorbeeld

code:

functie foo()
{
     value_type dat;
}

functie bar(value_type argument)
{
     value_type iets;
     value_type nogiets;
}

//stack []
value_type dit;
//stack [dit]
foo(); //in de functie: stack [dit, dat]
//stack [dit]
bar(); //in de functie: stack [dit, argument, iets, nogiets]
//stack [dit]

dus: het geheugen dat "dat" in beslag nam wordt hergebruikt voor "argument" even later

[PolarBear]

whoami schreef op dinsdag 26 december 2006 @ 15:33:
[...]

Da's fout. In .NET worden enkel reference types door de GC opgeruimd. Echter, je weet nooit wanneer die GC zijn run gaat doen. Dat hangt van allerlei omstandigheden af.

Nou ja, dat kan je natuurlijk ook zelf aanroepen, de GC.

[whoami]

PolarBear schreef op dinsdag 26 december 2006 @ 22:49:
[...]


Nou ja, dat kan je natuurlijk ook zelf aanroepen, de GC.

Dat kan, maar is meestal niet wenselijk en iig geen best practice. Integendeel, eerder een bad practice.

[H!GHGuY]

Ook filehandles en DB handles zouden voor zover ik weet in het ergste geval geclosed moeten worden als je object gedestruct wordt. (ten minste als de klasse zichzelf onderhoudt).

dit maakt het natuurlijk helemaal GEEN optie om het zo te doen.
"Resource acquisition is initialisation" en natuurlijk het omgekeerde ook.