ReDim'ed Array size
in [Visual Basic]
|
Prev: Array of pointers
Next: Will this object get destroyed?
From: Scott M. on 15 Oct 2009 14:05 "Eduardo" <mm(a)mm.com> wrote in message news:hb7nk9$1ee$1(a)aioe.org... > Scott M. escribi�: > >> Not to mention the wasted space, not much, but some. In addition, even >> though VB gives you the option to start counting wherever you like, there >> are standards to consider. Most other environments and many other >> programmers will start counting from zero, which could make your code be >> the "odd man out". > > The advantages for me are far more than the drawbacks. > And I don't do this when the memory usage could be critical (a rare > situation, because generally they are small arrays of longs or string that > are quickly cleared after the operation). > > I'm not programming low level routines for Windows's core, I want to do it > it clear (for me), fast, and easy. > > I think that to deal with dimensioned/not dimensioned arrays is too much > complication that I easily avoid wasting the first element. > > BTW, for the language designers I would suggest: I think that arrays > should start in 1 and not in 0 (I think I recall that McKinney wrote that > in his book, but I'm not sure), and that arrays declared > > Dim mMyArray () as Whatever > > I mean, not explicitely dimensioned, should be dimensioned automatically > when you try to write an element. > > Dim mMyArray () as String > > mMyArray(2) "B" > mMyArray(5) "E" > > DebugPrint Ubound(mMyArray) ' Prints 5 > > And when it has no element Ubound should return 0. > > The programming life would be simpler. > For the time being, I do what I said. That's fine, just pointing out why I would do it differently. -Scott
From: Eduardo on 15 Oct 2009 14:03 mayayana escribi�: >> What I usually do is to set just the upper bound and leave the lower >> bound in zero, but I use the array from 1 and ahead. >> I discard the first element. >> > I often do that too, especially in VBScript or > when passing the array around as a data > storage element. Sometimes that also provides > a way to store a number, so that A1(0) will return > the UBound. > > (I figure that if anyone else is using my code, > as Bill M. complained about, then they'll just > have to make an efort to understand the code > they're using before they start pasting it into their > own project. :) Yeah, but it's not too difficult to figure it, I think. May be you have to study the code twice, until you realize that the first element is not used, and it's not a bug. I don't remember if I ever posted code doing this (I think I didn't), but now I think I would have to add an explanation in the comments. For many people to waste a few bytes of memory could be a sin. It might had been in the past, but not now. Besides, they are usually erased when you finish what you are doing. I don't want to waste my programming time, and to complicate the code with flags to see if the array is already dimensioned, etc.
From: dpb on 15 Oct 2009 14:07 Eduardo wrote: > Scott M. escribi�: > >> Not to mention the wasted space, not much, but some. In addition, >> even though VB gives you the option to start counting wherever you >> like, there are standards to consider. Most other environments and >> many other programmers will start counting from zero, which could make >> your code be the "odd man out". > > The advantages for me are far more than the drawbacks. > And I don't do this when the memory usage could be critical (a rare > situation, because generally they are small arrays of longs or string > that are quickly cleared after the operation). > > I'm not programming low level routines for Windows's core, I want to do > it it clear (for me), fast, and easy. > > I think that to deal with dimensioned/not dimensioned arrays is too much > complication that I easily avoid wasting the first element. > > BTW, for the language designers I would suggest: I think that arrays > should start in 1 and not in 0 (I think I recall that McKinney wrote > that in his book, but I'm not sure), and that arrays declared > > Dim mMyArray () as Whatever > > I mean, not explicitely dimensioned, should be dimensioned automatically > when you try to write an element. > > Dim mMyArray () as String > > mMyArray(2) "B" > mMyArray(5) "E" > > DebugPrint Ubound(mMyArray) ' Prints 5 > > And when it has no element Ubound should return 0. > > The programming life would be simpler. > For the time being, I do what I said. There are tradeoffs to all of the above choices, good and/or bad depending on objectives/needs at any given time. Not right or wrong necessarily, just different. The amount of memory "wasted" in a single element of an array in today's environment is highly unlikely to be of any significance other than to the purist. In olden days or an embedded hardware-limited system or somesuch, sure--a desktop PC app, not so much. Dynamic allocation delayed to assignment, otoh, while perhaps convenient, does have an associated overhead at run time with it that can be significant and could potentially be a real bottleneck causing much memory thrashing and needless allocation/deallocation and copying as arrays grow. It also leads to possibilities of out-of-memory problems owing to memory fragmentation. So, there is a price; not likely to be major for smaller applications but at least worthy to be aware of the potential problems. As for zero- vis a vis one-based array indexing, that again, is a choice that has many reasons for being one or the other--there are historical reasons of compatibility as well as applications where one or the other makes common sense. Think of signal processing for sampled time series or frequency spectra where it's quite logical that 0 index is associated w/ either time zero or the DC (zero frequency) entry as simply one example for 0-based. Meanwhile, if one is doing record-based tracking, then 1-thru-N makes more sense than 0-thru-(N-1). Again, it isn't a case of right or wrong, it's what fits the situation. And, back to the spectral frequency example, for theoretical reasons for some purposes it makes sense to keep the symmetric (about DC) spectral components and so indices from -N/2 to +N/2 are handy (not to mention in VB the ability to double the size of arrays allowable since there isn't an unsigned integer to use as an array index to allow (1 To LargestIntegerOfSize-1) as a possibility w/o the workaround). IOW, there isn't one stroke for all boats and there are reasons for the choices made in various programming languages. --
From: Eduardo on 15 Oct 2009 22:59 dpb escribi�: > Dynamic allocation delayed to assignment, otoh, while perhaps > convenient, does have an associated overhead at run time with it that > can be significant and could potentially be a real bottleneck causing > much memory thrashing and needless allocation/deallocation and copying > as arrays grow. It also leads to possibilities of out-of-memory > problems owing to memory fragmentation. So, there is a price; not > likely to be major for smaller applications but at least worthy to be > aware of the potential problems. If they can raise an error when you try to access an index out of bound, they are already checking the bounds. Then, to automatically redim the array instead of raising the error (just when writing) should not be an overhead (because anyway you'll have to do it in your code). > As for zero- vis a vis one-based array indexing, that again, is a choice > that has many reasons for being one or the other--there are historical > reasons of compatibility as well as applications where one or the other > makes common sense. I think it's a remain from the old days and also an inheritance from low level languages, but it's not good for a high level language. A high level language must be rather friendly with the programmer... and humans count starting with 1. > Think of signal processing for sampled time series > or frequency spectra where it's quite logical that 0 index is associated > w/ either time zero or the DC (zero frequency) entry as simply one > example for 0-based. OK, you have some cases where 0 is the better and less confusing choice, but in the most of the cases 1 is the less confusing choice. The 'Option Base' declaration could serve to set the dafault lower bound to 0, the opposite as it's in VB6. > Meanwhile, if one is doing record-based tracking, > then 1-thru-N makes more sense than 0-thru-(N-1). Again, it isn't a > case of right or wrong, it's what fits the situation. Yes, as I already said, I agree. But at least for me, the most of the situations I have favor 1. The most of the times you have the array with a list of elements, and those elements represent something, like windows handles, images, customers, rows, etc. How many customers do you have? Let me see... 0, 1, 2, 3, 4... 5! No... it's not 'normal' to count like that. > And, back to the > spectral frequency example, for theoretical reasons for some purposes it > makes sense to keep the symmetric (about DC) spectral components and so > indices from -N/2 to +N/2 are handy (not to mention in VB the ability to > double the size of arrays allowable since there isn't an unsigned > integer to use as an array index to allow (1 To LargestIntegerOfSize-1) > as a possibility w/o the workaround). > > IOW, there isn't one stroke for all boats and there are reasons for the > choices made in various programming languages. > > --
From: dpb on 15 Oct 2009 23:54
Eduardo wrote: > dpb escribi�: > >> Dynamic allocation delayed to assignment, otoh, while perhaps >> convenient, does have an associated overhead at run time with it that >> can be significant and could potentially be a real bottleneck causing >> much memory thrashing and needless allocation/deallocation and copying >> as arrays grow. It also leads to possibilities of out-of-memory >> problems owing to memory fragmentation. So, there is a price; not >> likely to be major for smaller applications but at least worthy to be >> aware of the potential problems. > > If they can raise an error when you try to access an index out of bound, > they are already checking the bounds. Then, to automatically redim the > array instead of raising the error (just when writing) should not be an > overhead (because anyway you'll have to do it in your code). Bounds checking is, in most current languages, as in VB, a user-selectable option that _most_ people turn off in debugged production code for speed. The feature you wish for of automagic allocation does exist in some languages (Matlab, for one) although generally in interpreted rather than compiled ones. It does come at the costs outlined above whether you're aware of them or not. >> As for zero- vis a vis one-based array indexing, that again, is a >> choice that has many reasons for being one or the other--there are >> historical reasons of compatibility as well as applications where one >> or the other makes common sense. > > I think it's a remain from the old days and also an inheritance from low > level languages, but it's not good for a high level language. > A high level language must be rather friendly with the programmer... and > humans count starting with 1. That is a _VERY_ narcissistic and provincial way to think of a language design--just because you prefer one thing doesn't mean that's best for everybody who might use the language and certainly lacking flexibility is _NOT_ a feature to be wished for in any programming language. > OK, you have some cases where 0 is the better and less confusing choice, > but in the most of the cases 1 is the less confusing choice. What if the person developing code works in the "0 is better" field exclusively? Your preference should still reign over their development environment? I don't think so... :) It indicates again the above assessment of your evaluation of the desirability of features. > The 'Option Base' declaration could serve to set the dafault lower bound > to 0, the opposite as it's in VB6. It _does_ serve to set it at either on user choice as it should. > Yes, as I already said, I agree. But at least for me, the most of the > situations I have favor 1. The world of programming doesn't revolve around you (fortunately for the rest of us...) :) -- |