VB.Net, "late" DIM statements

"late" DIM statements

Author	Message
Mike Lerc #1 / 8	"late" DIM statements I have a question that I think comes down to coding style. VB.NET allows you to Dim statements all over the place. Here's a simplistic example: public Sub Example(strExampleText As String) Dim intStrLen As integer intStrLen = strExample.length if intStrLen> 0 then dim intCounter as integer '<-"late" DIM statement for intcounter = 1 to 10 console.write(intcounter) next end if end sub I was taught to Dim all your variables at the top of the code. Is there an advantage to doing it as shown above? For instance does VB.NET not allocate space for "late" dims unless it actually gets to that part of the code? To my eye, declaring variables all over the code makes for messy code, but if there's an advantage to this I want to use it. Please respond with your thoughts Lerch
Sun, 06 Mar 2005 21:22:10 GMT

Bev Kaufma #2 / 8	"late" DIM statements I don't know if VB only allocates space if the command is actually run, but neither do I think it matters. Back in the Jurassic period when by 48K-ram Apple was considered state of the art, limiting space allocation was a serious concern. It's not anymore. Messy code is more costly in the long run because it makes it harder to debug, and these days minutes cost a lot more than megs. Quote: >-----Original Message----- >I have a question that I think comes down to coding style. VB.NET >allows you to Dim statements all over the place. Here's a simplistic >example: >public Sub Example(strExampleText As String) > Dim intStrLen As integer > intStrLen = strExample.length > if intStrLen> 0 then > dim intCounter as integer '<-"late" DIM statement > for intcounter = 1 to 10 > console.write(intcounter) > next > end if >end sub >I was taught to Dim all your variables at the top of the code. Is >there an advantage to doing it as shown above? For instance does >VB.NET not allocate space for "late" dims unless it actually gets to >that part of the code? To my eye, declaring variables all over the >code makes for messy code, but if there's an advantage to this I want >to use it. Please respond with your thoughts >Lerch >.
Sun, 06 Mar 2005 21:39:44 GMT

Lee Mood #3 / 8	"late" DIM statements The objects dimensioned only exist once the code is executed, and only exist within the block that they are created. For example, the 'intCounter' in the second dim statement below only exists within the if/then block that it's created within. If you try to access 'intCounter' after the 'end if' then you will get an error (assuming you have 'option explicit on' set). It's a nice way to only create variables/objects when you need them and automatically discard them when you're done. Quote: >-----Original Message----- >I have a question that I think comes down to coding style. VB.NET >allows you to Dim statements all over the place. Here's a simplistic >example: >public Sub Example(strExampleText As String) > Dim intStrLen As integer > intStrLen = strExample.length > if intStrLen> 0 then > dim intCounter as integer '<-"late" DIM statement > for intcounter = 1 to 10 > console.write(intcounter) > next > end if >end sub >I was taught to Dim all your variables at the top of the code. Is >there an advantage to doing it as shown above? For instance does >VB.NET not allocate space for "late" dims unless it actually gets to >that part of the code? To my eye, declaring variables all over the >code makes for messy code, but if there's an advantage to this I want >to use it. Please respond with your thoughts >Lerch >.
Sun, 06 Mar 2005 21:54:39 GMT

Mike Lerc #4 / 8	"late" DIM statements Quote: >The objects dimensioned only exist once the code is >executed, and only exist within the block that they are >created. >For example, the 'intCounter' in the second dim statement >below only exists within the if/then block that it's >created within. If you try to access 'intCounter' after >the 'end if' then you will get an error (assuming you >have 'option explicit on' set). So if I'm reading you right, this is really the most efficient way to code in terms of saving memory and such. Does the garbage collection take care of the clean-up as soon as each block is done or does that not happen until the function or sub itself is done? I'd love to read more on this if anyone can point me to external resources. Thanks! Mike
Tue, 08 Mar 2005 03:10:23 GMT

Jonathan Alle #5 / 8	"late" DIM statements Quote: > The objects dimensioned only exist once the code is > executed, and only exist within the block that they are > created. That's not quite accurate. Local variables may only exist within the block they are created, but objects exist on the heap and thus have indefinite lifespans. -- Jonathan Allen, MCSD Quote: > The objects dimensioned only exist once the code is > executed, and only exist within the block that they are > created. > For example, the 'intCounter' in the second dim statement > below only exists within the if/then block that it's > created within. If you try to access 'intCounter' after > the 'end if' then you will get an error (assuming you > have 'option explicit on' set). > It's a nice way to only create variables/objects when you > need them and automatically discard them when you're done.
Tue, 08 Mar 2005 12:45:40 GMT

Lee Mood #6 / 8	"late" DIM statements Then why can I not access an object outside of the block that it created within? Variables are no longer 'variables' they are in fact objects themselves are they not? Quote: >-----Original Message----- >> The objects dimensioned only exist once the code is >> executed, and only exist within the block that they are >> created. >That's not quite accurate. Local variables may only exist within the block >they are created, but objects exist on the heap and thus have indefinite >lifespans. >-- >Jonathan Allen, MCSD >> The objects dimensioned only exist once the code is >> executed, and only exist within the block that they are >> created. >> For example, the 'intCounter' in the second dim statement >> below only exists within the if/then block that it's >> created within. If you try to access 'intCounter' after >> the 'end if' then you will get an error (assuming you >> have 'option explicit on' set). >> It's a nice way to only create variables/objects when you >> need them and automatically discard them when you're done. >.
Sat, 12 Mar 2005 02:31:12 GMT

Jonathan Alle #7 / 8	"late" DIM statements Quote: > Then why can I not access an object outside of the block > that it created within? You can, you just need a reference to it. Example... Public MyCar as Car Sub CreateCar() Dim temp as Car temp = New Car temp.Name = "something" MyCar = Car End Sub Sub Test Messagebox (MyCar.Name) End Sub The object is created in CreateCar subroutine. But that same object can be accessed in the Test subroutine. In this example, 'MyCar' and 'temp' are Reference Variables. They are not the objects themselves, but rather a pointer to the object. -- Jonathan Allen, MCSD Quote: > Then why can I not access an object outside of the block > that it created within? Variables are no > longer 'variables' they are in fact objects themselves are > they not? > >-----Original Message----- > >> The objects dimensioned only exist once the code is > >> executed, and only exist within the block that they are > >> created. > >That's not quite accurate. Local variables may only exist > within the block > >they are created, but objects exist on the heap and thus > have indefinite > >lifespans. > >-- > >Jonathan Allen, MCSD > >> The objects dimensioned only exist once the code is > >> executed, and only exist within the block that they are > >> created. > >> For example, the 'intCounter' in the second dim > statement > >> below only exists within the if/then block that it's > >> created within. If you try to access 'intCounter' after > >> the 'end if' then you will get an error (assuming you > >> have 'option explicit on' set). > >> It's a nice way to only create variables/objects when > you > >> need them and automatically discard them when you're > done. > >.
Sat, 12 Mar 2005 10:34:33 GMT

Mark #8 / 8	"late" DIM statements I get the feeling Jonathan may not realize what he's saying, nor does he realize what he's not seeing. Jonathan's example clearly shows the fundamentals of global vs. local variables, a concept which has been a part of VB since it's early days. However, the code in question and it's assessment (mentioned by Lee Moody) I believe to be accurate. The text below is from the VB.NET online help, Visual Basic Language Concept, under the heading Levels of Scope (it should also answer Mike Lerch's question about lifetime): ====================================== Block Scope A block is a set of statements terminated by an End, Else, Loop, or Next statement, for example within a For...Next or If...Then...Else...End If construction. An element declared within a block can be used only within that block. In the following example, the scope of the integer variable Cube is the block between If and End If, and Cube can no longer be referenced when execution passes out of the block: If N < 1291 Then Dim Cube As Integer Cube = N ^ 3 End If Note Even if the scope of an element is limited to a block, its lifetime is still that of the entire procedure. If you enter the block more than once during the procedure, a block variable retains its previous value. To avoid unexpected results in such a case, it is wise to initialize the variable each time. ====================================== Regards, Mark Quote: > > Then why can I not access an object outside of the block > > that it created within? > You can, you just need a reference to it. Example... > Public MyCar as Car > Sub CreateCar() > Dim temp as Car > temp = New Car > temp.Name = "something" > MyCar = Car > End Sub > Sub Test > Messagebox (MyCar.Name) > End Sub > The object is created in CreateCar subroutine. But that same object can be > accessed in the Test subroutine. > In this example, 'MyCar' and 'temp' are Reference Variables. They are not > the objects themselves, but rather a pointer to the object. > -- > Jonathan Allen, MCSD > > Then why can I not access an object outside of the block > > that it created within? Variables are no > > longer 'variables' they are in fact objects themselves are > > they not? > > >-----Original Message----- > > >> The objects dimensioned only exist once the code is > > >> executed, and only exist within the block that they are > > >> created. > > >That's not quite accurate. Local variables may only exist > > within the block > > >they are created, but objects exist on the heap and thus > > have indefinite > > >lifespans. > > >-- > > >Jonathan Allen, MCSD > > >> The objects dimensioned only exist once the code is > > >> executed, and only exist within the block that they are > > >> created. > > >> For example, the 'intCounter' in the second dim > > statement > > >> below only exists within the if/then block that it's > > >> created within. If you try to access 'intCounter' after > > >> the 'end if' then you will get an error (assuming you > > >> have 'option explicit on' set). > > >> It's a nice way to only create variables/objects when > > you > > >> need them and automatically discard them when you're > > done. > > >.
Mon, 28 Mar 2005 02:31:27 GMT

Page 1 of 1

[ 8 post ]