I want to make a zero element array. I know that Nothing is not the same as a zero element array, since I can't get the length of, or iterate through, an array = Nothing. I could make a zero element array like this, but it seems like overkill: Dim emptyArray as Byte() = System.Text.Encoding.Default.GetBytes("") Is there a better way? Zytan
[quoted text, click to view] > Dim emptyArray as Byte() = New Byte() {}
Right, of course. [quoted text, click to view] > I don't know why you can write it both ways. There will be an esoteric > reason but I just don't know what it is.
I'd like to know why, as well. [quoted text, click to view] > Both forms DO compile to identical IL.
Ok. [quoted text, click to view] > My own preference is for the 2nd form.
Mine, too. Thanks again!! Zytan
Don't get me wrong Zytan - I have no inclination to find out why - In that case I'm happy enough to accept that it just is. There aren't enough hours in the day to chase down the reasons behind all the foibles that one comes across. I'm prepared to accept that the writers of VB.NET let a 'foible' exist because: a. they had a momentary aberration b. it was early on a monday morning/late of friday afternoon c. there is a really good reason for doing so d. all of the above Whether or not I like a particular 'foible' is a different matter but I'm not going to lose any sleep over it. That said, the various 'foible's do certanly make for som lively discussions in here. :) [quoted text, click to view] "Zytan" <zytanlithium@yahoo.com> wrote in message news:1171849025.106742.167000@v33g2000cwv.googlegroups.com... >> Dim emptyArray as Byte() = New Byte() {} > > Right, of course. > >> I don't know why you can write it both ways. There will be an esoteric >> reason but I just don't know what it is. > > I'd like to know why, as well. > >> Both forms DO compile to identical IL. > > Ok. > >> My own preference is for the 2nd form. > > Mine, too. > > Thanks again!! > > Zytan >
Dim emptyArray() as Byte = New Byte() {} Console.Writeline(emptyArray.Length) or Dim emptyArray as Byte() = New Byte() {} Console.Writeline(emptyArray.Length) I don't know why you can write it both ways. There will be an esoteric reason but I just don't know what it is. Both forms DO compile to identical IL. My own preference is for the 2nd form. [quoted text, click to view] "Zytan" <zytanlithium@yahoo.com> wrote in message news:1171847658.125812.151060@p10g2000cwp.googlegroups.com... >I want to make a zero element array. I know that Nothing is not the > same as a zero element array, since I can't get the length of, or > iterate through, an array = Nothing. I could make a zero element > array like this, but it seems like overkill: > > Dim emptyArray as Byte() = System.Text.Encoding.Default.GetBytes("") > > Is there a better way? > > Zytan >
"Zytan" <zytanlithium@yahoo.com> schrieb: [quoted text, click to view] >I want to make a zero element array. I know that Nothing is not the > same as a zero element array, since I can't get the length of, or > iterate through, an array = Nothing. I could make a zero element > array like this, but it seems like overkill:
\\\ Dim a(-1) As Integer /// -- M S Herfried K. Wagner M V P <URL: http://dotnet.mvps.org/>
Herfried, That's what done before in VBA and was just trying to figure it out the other day in .Net. Thanks for the answer. So simple once you know. Doug [quoted text, click to view] "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message news:%232DIg9GVHHA.868@TK2MSFTNGP05.phx.gbl... > Cor, > > "Cor Ligthert [MVP]" <notmyfirstname@planet.nl> schrieb: >> Or I misunderstood it, or we are coming now on really problems which will >> never exist in a real world. >> >> \\\ >> Dim a(-1) As Integer >> /// >> (I take Herfrieds sample because this shows it in my idea the nicest.) >> >> Therefore all was it alone for me, what can be the use of this? > > Imagine a method like 'Directory.GetFiles' would be called on an empty > directory. Then I'd expect a zero-length array to be returned instead of > 'Nothing'. > > -- > M S Herfried K. Wagner > M V P <URL: http://dotnet.mvps.org/> > V B <URL: http://dotnet.mvps.org/dotnet/faqs/>
[quoted text, click to view] On 2007-02-19, Cor Ligthert [MVP] <notmyfirstname@planet.nl> wrote: > Zytan, > > Or I misunderstood it, or we are coming now on really problems which will > never exist in a real world. > > \\\ > Dim a(-1) As Integer > /// > (I take Herfrieds sample because this shows it in my idea the nicest.) > > Therefore all was it alone for me, what can be the use of this? > > Cor
It's sort of a variation of the null object pattern. If a method returns an array, it's often nice to not have to check for a null reference (nothing)... for each i as integer in getintegerarray () ' do cool stuff with integer next i Instead of: dim a() as integer = getintegerarray () if not a is nothing then foreach i as integer in a ' do cool stuff with integer next i end if --
Zytan, Or I misunderstood it, or we are coming now on really problems which will never exist in a real world. \\\ Dim a(-1) As Integer /// (I take Herfrieds sample because this shows it in my idea the nicest.) Therefore all was it alone for me, what can be the use of this? Cor "Zytan" <zytanlithium@yahoo.com> schreef in bericht news:1171847658.125812.151060@p10g2000cwp.googlegroups.com... [quoted text, click to view] >I want to make a zero element array. I know that Nothing is not the > same as a zero element array, since I can't get the length of, or > iterate through, an array = Nothing. I could make a zero element > array like this, but it seems like overkill: > > Dim emptyArray as Byte() = System.Text.Encoding.Default.GetBytes("") > > Is there a better way? > > Zytan >
Cor, "Cor Ligthert [MVP]" <notmyfirstname@planet.nl> schrieb: [quoted text, click to view] > Or I misunderstood it, or we are coming now on really problems which will > never exist in a real world. > > \\\ > Dim a(-1) As Integer > /// > (I take Herfrieds sample because this shows it in my idea the nicest.) > > Therefore all was it alone for me, what can be the use of this?
Imagine a method like 'Directory.GetFiles' would be called on an empty directory. Then I'd expect a zero-length array to be returned instead of 'Nothing'. -- M S Herfried K. Wagner M V P <URL: http://dotnet.mvps.org/> V B <URL: http://dotnet.mvps.org/dotnet/faqs/>
Tom/Herfried, I don't see it clear, however I get the idea where you guys want to use it. Thanks, Cor "Tom Shelton" <tom_shelton@comcastXXXXXXX.net> schreef in bericht news:l7adnXtDJJUc1UfYnZ2dnUVZ_uninZ2d@comcast.com... [quoted text, click to view] > On 2007-02-19, Cor Ligthert [MVP] <notmyfirstname@planet.nl> wrote: >> Zytan, >> >> Or I misunderstood it, or we are coming now on really problems which will >> never exist in a real world. >> >> \\\ >> Dim a(-1) As Integer >> /// >> (I take Herfrieds sample because this shows it in my idea the nicest.) >> >> Therefore all was it alone for me, what can be the use of this? >> >> Cor > > It's sort of a variation of the null object pattern. If a method returns > an > array, it's often nice to not have to check for a null reference > (nothing)... > > for each i as integer in getintegerarray () > ' do cool stuff with integer > next i > > Instead of: > > dim a() as integer = getintegerarray () > if not a is nothing then > foreach i as integer in a > ' do cool stuff with integer > next i > end if > > -- > Tom Shelton
[quoted text, click to view] > Don't get me wrong Zytan - I have no inclination to find out why - In that > case I'm happy enough to accept that it just is.
Well, at least now I know they are the same, and I can flow with the concept that () means an array of whatever the type is, regardless of where it is placed. [quoted text, click to view] > There aren't enough hours in the day to chase down the reasons behind all > the foibles that one comes across.
Yes, it impedes my progress, but I can't help but ask. And sometimes an answer finds a better alternative, and that's how we progress. [quoted text, click to view] > I'm prepared to accept that the writers of VB.NET let a 'foible' exist > because: > > a. they had a momentary aberration > b. it was early on a monday morning/late of friday afternoon > c. there is a really good reason for doing so > d. all of the above
I would think it is most likely: e. backwards compatibility So, far almost all the messes I've seen with C++ and VB .NET is due to backwards compatibility. I can understand why it is important to maintain it. [quoted text, click to view] > That said, the various 'foible's do certanly make for som lively discussions > in here. :)
Well, I hope that's a good thing! Zytan
[quoted text, click to view] > \\\ > Dim a(-1) As Integer > ///
Ok, right, thanks. I ran across this recently, actually. Now why didn't I use this. I must have asked the question before this, or forgot about it. So, there are these possibilities: Dim zero1(-1) As Integer Dim zero2() As Integer = {} Dim zero3 As Integer() = {} Zytan
[quoted text, click to view] > Or I misunderstood it, or we are coming now on really problems which will > never exist in a real world. > ... > Therefore all was it alone for me, what can be the use of this?
I want an array that will be 0 in size when there are 0 'answers'. If there are more 'answers', then it will be an array of the answers. The array will be used in a loop. If I used Nothing, instead, the loop would fail, and I'd need more code to check for that. So, I'd rather use an empty array. Cor, I don't follow. Are you saying you don't know of any real reason there would ever be an empty array? Perhaps there's a better way of handling the above, with more exotic language contructs, but for now, being a beginner, I can't see any better (simple!) way of doing this other than using an empty array. [quoted text, click to view] > \\\ > Dim a(-1) As Integer > /// > (I take Herfrieds sample because this shows it in my idea the nicest.)
Actually, VB .NET's attempt to ease code porting from VB6 by declaring arrays using the highest index, rather than the array size like every other language, is, personally, the worst thing I've even seen in the language. The reasoning behind is interesting but very unconvincing: http://www.thecodingmonkey.net/2006/03/24/YouHaveToUnderstandTheHistory.aspx Having said that, I'd rather using " = {}" than "a(-1)", since an empty set is { }. -1 holds little meaning, it can only be understood by logical extension of what the maximum index means. But, by using "a(-1)", it does remind me of this language quirk. I think perhaps explicitly showing the array bounds from min to max may be best practive, to indicate precisely what is going on: Dim tenElements(0 To 9) As Integer But, it doesn't quite look as good for 0 length ararys: Dim zeroElements(0 To -1) As Integer So, I'm not sure. I think, personally, I like { } best. Zytan
Zytan, You wrote my answer always yourself. [quoted text, click to view] > Actually, VB .NET's attempt to ease code porting from VB6 by declaring > arrays using the highest index, rather than the array size like every > other language, is, personally, the worst thing I've even seen in the > language. The reasoning behind is interesting but very unconvincing: >
Two answer, with the above I don't agree with you. And before you understand it wrong, I have had much discussion with a very longtime C# guy on this board. In my opinion VB was using the 1 as starting indexer in fact the way it should be, the figure for first is 1. Numbers are represented by a characterset from 0 to 9. However oldies like me are used by the 0 as first indexer although it is in my eyes in fact completely foolish. Before somebody start to write why it is a zero. I know that. The other point an array is in fact in Net only usefull for fixed arrays. For the rest the IList and Icollection implementing classes are much better including the generic ones. The array has everytime to be redimmed. Therefore I did not see the reason to use of a fixed array with a lenght of real 0. Cor
[quoted text, click to view] "Stephany Young" <noone@localhost> wrote in message news:%234DnRtSVHHA.3948@TK2MSFTNGP05.phx.gbl... > "Why isn't C/C++ more like BASIC/VB?".
Because BASIC wasn't intended to be used to write operating systems. Why isn't a Mercedes-Benz more like the Ford Model-T since the Ford came first? [quoted text, click to view] > Before anyone launches in, that, of course, is purely rhetorical, but does > help to put things in perspective.
It's an odd perspective that suggests that modern things should be more like the things cavemen used because they were first. Why aren't MP3s more like 33 1/3 LPs, can't they make them scratch and warp? [quoted text, click to view] > As for zero or 1 based indexing, we Homo Sapiens do not, intuitively start > count counting from zero.
Homo sapiens do not calculate divisions accurate to 64- bits nor do run at 65 MPH. These are machines. They aren't supposed to emulate people, we have people for that. [quoted text, click to view] > You don't hear someone say "I've made my zeroth million.".
I hear them say "my bad" so this should be the error message when the CPU overflows? :-) [quoted text, click to view] > Certainly, Option Base is no longer supported in VB.NET (2005), but arrays > are still 'sized' by supplying the value for the upper-bound, the same way > it has been since before C was invented.
The article points out (if I read it correctly) that the arrays are sized one larger than expected. Expect a bank transfer error any day now and it will be due to "oh yeah the array was one larger than we thought." [quoted text, click to view] > If you had a nice white fence and your neighbour painted his cacky yellow, > I'm sure that you would be more than a bit miffed if people started saying > that you should paint your's cacky yellow just because he did.
Yeah when your neighbor uses the new fire resistant paint it is important to stick to your principals. He's going to have to pay when a fire at your house burns his down anyway so who honestly cares as long as 1963 is the basis of all future decisions? We don't need energy efficient light bulbs (they're oddly shaped). If people want to flush their toilets directly into the Thames I say "why not" they were doing it in 1830. Tom :-)
Next time I'll staet clearly that my question isn't rehtorical and then nobody will reply :) [quoted text, click to view] "Tom Leylan" <tleylan@nospam.net> wrote in message news:uPKdw3UVHHA.2256@TK2MSFTNGP02.phx.gbl... > "Stephany Young" <noone@localhost> wrote in message > news:%234DnRtSVHHA.3948@TK2MSFTNGP05.phx.gbl... >> "Why isn't C/C++ more like BASIC/VB?". > > Because BASIC wasn't intended to be used to write operating systems. Why > isn't a Mercedes-Benz more like the Ford Model-T since the Ford came > first? > >> Before anyone launches in, that, of course, is purely rhetorical, but >> does help to put things in perspective. > > It's an odd perspective that suggests that modern things should be more > like the things cavemen used because they were first. Why aren't MP3s > more like 33 1/3 LPs, can't they make them scratch and warp? > >> As for zero or 1 based indexing, we Homo Sapiens do not, intuitively >> start count counting from zero. > > Homo sapiens do not calculate divisions accurate to 64- bits nor do run at > 65 MPH. These are machines. They aren't supposed to emulate people, we > have people for that. > >> You don't hear someone say "I've made my zeroth million.". > > I hear them say "my bad" so this should be the error message when the CPU > overflows? :-) > >> Certainly, Option Base is no longer supported in VB.NET (2005), but >> arrays are still 'sized' by supplying the value for the upper-bound, the >> same way it has been since before C was invented. > > The article points out (if I read it correctly) that the arrays are sized > one larger than expected. Expect a bank transfer error any day now and it > will be due to "oh yeah the array was one larger than we thought." > >> If you had a nice white fence and your neighbour painted his cacky >> yellow, I'm sure that you would be more than a bit miffed if people >> started saying that you should paint your's cacky yellow just because he >> did. > > Yeah when your neighbor uses the new fire resistant paint it is important > to stick to your principals. He's going to have to pay when a fire at > your house burns his down anyway so who honestly cares as long as 1963 is > the basis of all future decisions? We don't need energy efficient light > bulbs (they're oddly shaped). If people want to flush their toilets > directly into the Thames I say "why not" they were doing it in 1830. > > Tom :-) > >
Time for a revisit on this one Zytan. I had a bit of time this afternoon and I was getting a tad curious. This page here http://msdn2.microsoft.com/en-us/library/7ee5a7s1(VS.80).aspx is the key to understanding why these forms are both valid. Dim emptyArray() as Byte = New Byte() {} Dim emptyArray as Byte() = New Byte() {} It won't tell you in so many words, but the content of that page and some of it's links show the following. The page states that to specify that a variable is an array, you follow its variablename immediately with parentheses (as in the first form). Other information shows that Byte and Byte() are distinct data types. Byte is a value type. Byte() is a reference type derived from System.Array. If you attempt to code: Dim emptyArray() as Byte() = New Byte() {} you get a compiler error that reads: Array modifiers cannot be specified on both a variable and its type. More specifically, the compiler error code is BC31087 which has the longer description of: Array modifiers are present on both the variable and its type, indicating an array of arrays. and the recommended fix is to remove the array modifier from the type specifier. This is also what the intellisense error correction option recommend for this condition. This means that the form recommended by both the documentation and the compiler is: Dim emptyArray() as Byte = New Byte() {} If you code: Dim emptyArray as Byte() = New Byte() {} then because the variable name is not followed by () and because Byte() is a distinct type, it follows that declaration is quite legal. The documentation further recommends that a zero-length array be declared as: Dim emptyArray(-1) As Byte If you attempt to code: Dim emptyArray As Byte(-1) you get compiler error code BC31087: Array bounds cannot appear in type specifiers. This reinforces that the recommendations we came across earlier. As to why we appeared to not know these things off the top off our heads, we probably did, but because using these 'features' has become second nature, the whys and wherefores are probably in an archived part of memory and not readily accessible. [quoted text, click to view] "Zytan" <zytanlithium@yahoo.com> wrote in message news:1171849025.106742.167000@v33g2000cwv.googlegroups.com... >> Dim emptyArray as Byte() = New Byte() {} > > Right, of course. > >> I don't know why you can write it both ways. There will be an esoteric >> reason but I just don't know what it is. > > I'd like to know why, as well. > >> Both forms DO compile to identical IL. > > Ok. > >> My own preference is for the 2nd form. > > Mine, too. > > Thanks again!! > > Zytan >
Unfortunately, that blog only gives part of the history. One hears a lot of people ask "Why isn't BASIC/VB more like C/C++?". This would be a fair question if BASIC was "invented" after C. But it was the other way around and therfore the more appropriate question should be "Why isn't C/C++ more like BASIC/VB?". Before anyone launches in, that, of course, is purely rhetorical, but does help to put things in perspective. As for zero or 1 based indexing, we Homo Sapiens do not, intuitively start count counting from zero. You don't hear someone say "I've made my zeroth million.". Likewise there was no year zero between BCE and CE which is also why the year 2000 was in the 20th century and is not in the 21st century. Certainly computers count from zero quite happily because all bits off just happens to be zero. Once it was determined that indexing from zero was actually a very good idea the Option Base was introduced to BASIC to allow it without destroying existing code, but this still predates VB. Another aspect to consider is that, unlike a lot of other languages, BASIC is NOT controlled by a commitee. COBOL is controlled by CODASYL, C++ is controlled by ANSI, etc. Those languages MUST, at least, comply with the ratified standard, and anything else is a compiler-specific extension. What VB/VB.NET does (or doesn't do) is purely up to Microsoft. Certainly, Option Base is no longer supported in VB.NET (2005), but arrays are still 'sized' by supplying the value for the upper-bound, the same way it has been since before C was invented. If you had a nice white fence and your neighbour painted his cacky yellow, I'm sure that you would be more than a bit miffed if people started saying that you should paint your's cacky yellow just because he did. <snip> [quoted text, click to view] > Actually, VB .NET's attempt to ease code porting from VB6 by declaring > arrays using the highest index, rather than the array size like every > other language, is, personally, the worst thing I've even seen in the > language. The reasoning behind is interesting but very unconvincing: > > http://www.thecodingmonkey.net/2006/03/24/YouHaveToUnderstandTheHistory.aspx </snip>
Tom, This is an International board with international standards. [quoted text, click to view] > > Because BASIC wasn't intended to be used to write operating systems. Why > isn't a Mercedes-Benz more like the Ford Model-T since the Ford came > first? > .
http://www.cyberparent.com/wheels/mercedes.htm I thought that Mercedes was the name it was sold in Brittain. Cor
I see I wrote a complete unreadable message. Starting part of it was: [quoted text, click to view] > You wrote my answer always yourself. >
Were I did mean:. "You wrote the answer almost yourself". And more of that stuff, Stephany gave however an excelent correction from the first part so I keep it with that. Cor [quoted text, click to view] >> Actually, VB .NET's attempt to ease code porting from VB6 by declaring >> arrays using the highest index, rather than the array size like every >> other language, is, personally, the worst thing I've even seen in the >> language. The reasoning behind is interesting but very unconvincing: >> > Two answer, with the above I don't agree with you. > And before you understand it wrong, I have had much discussion with a very > longtime C# guy on this board. In my opinion VB was using the 1 as > starting indexer in fact the way it should be, the figure for first is 1. > Numbers are represented by a characterset from 0 to 9. However oldies like > me are used by the 0 as first indexer although it is in my eyes in fact > completely foolish. Before somebody start to write why it is a zero. I > know that. > > The other point an array is in fact in Net only usefull for fixed arrays. > For the rest the IList and Icollection implementing classes are much > better including the generic ones. The array has everytime to be redimmed. > Therefore I did not see the reason to use of a fixed array with a lenght > of real 0. > > Cor > > >
Tom, [quoted text, click to view] > If people want to flush their toilets directly into the Thames I say "why > not" they were doing it in 1830. >
Because there are now much more people than in 1830 surrounding the Thames. Assuming you mean with the Thames that River witch goes through the Thames Valley to the North Sea/Canal and not a River in the USA. I assume that the problem about this is much less in most places in the country were you and Stephany live than were I live. (And that is global wise seen beside that Thames). With this you show well, that problems have forever to be seen in its own context and own and current environment. Cor
[quoted text, click to view] > This page here http://msdn2.microsoft.com/en-us/library/7ee5a7s1(VS.80).aspx > is the key to understanding why these forms are both valid. > [snip] > The page states that to specify that a variable is an array, you follow its > variablename immediately with parentheses (as in the first form). Yup, I can see that. Also, from that page, it links to "How to: Create an Array with No Elements" http://msdn2.microsoft.com/en-us/library/18e9wyy0(VS.80).aspx which says "Declare one of the array's dimensions to be -1", as you mention later in your post. [quoted text, click to view] > Other information shows that Byte and Byte() are distinct data types. > > Byte is a value type. > > Byte() is a reference type derived from System.Array.
Ok, so they really are two different things. [quoted text, click to view] > If you attempt to code: > > Dim emptyArray() as Byte() = New Byte() {} > > you get a compiler error that reads: > > Array modifiers cannot be specified on both a variable and its type.
I tried this, too. And that answer indicates that they are one and the same. [quoted text, click to view] > This means that the form recommended by both the documentation and the > compiler is: > > Dim emptyArray() as Byte = New Byte() {}
Yup. [quoted text, click to view] > If you code: > > Dim emptyArray as Byte() = New Byte() {} > > then because the variable name is not followed by () and because Byte() is a > distinct type, it follows that declaration is quite legal.
Yes. This still doesn't explain why the two produce the same IL. But, now, at least, I follow the recommended method, since you are saying "emptyArray is an arrary of type Byte", which follows: "Dim emptyArray() as Byte", although they could have borrowed some syntax ideas from Pascal to make it a little more clear. [quoted text, click to view] > If you attempt to code: > > Dim emptyArray As Byte(-1) > > you get compiler error code BC31087: Array bounds cannot appear in type > specifiers. > > This reinforces that the recommendations we came across earlier.
Yup, I tried that, too, and I agree with you. So, now, it is definitely more 'proper' to use the () on the variable, not the type. You've changed my mind. [quoted text, click to view] > As to why we appeared to not know these things off the top off our heads, we > probably did, but because using these 'features' has become second nature, > the whys and wherefores are probably in an archived part of memory and not > readily accessible.
Totally makes sense. But, I'm sure you can see how, by understanding (getting an answer to 'why?'), it allows a beginner to get to the position you are are. Thanks, Stephany, Zytan
[quoted text, click to view] > > Actually, VB .NET's attempt to ease code porting from VB6 by declaring > > arrays using the highest index, rather than the array size like every > > other language, is, personally, the worst thing I've even seen in the > > language. The reasoning behind is interesting but very unconvincing: > > Two answer, with the above I don't agree with you. > And before you understand it wrong, I have had much discussion with a very > longtime C# guy on this board. In my opinion VB was using the 1 as starting > indexer in fact the way it should be, the figure for first is 1. Numbers are > represented by a characterset from 0 to 9. However oldies like me are used > by the 0 as first indexer although it is in my eyes in fact completely > foolish. Before somebody start to write why it is a zero. I know that.
I know counting from 1 makes more sense to humans. I've used BASIC before VB, and I was happy with option base 1. Learning about pointers and C and Pascal made me realized why 0 is better. But, this is all *irrelevant* to the issue I was raising: If I want 10 elements, I want to write 10. VB .NET says I need to write 9. That's the issue I was bringing up. In fact, my point was that the issue of 0-based indexing or 1-based indexing was a very unconvincing argument to start using the maximum index instead of the array length. [quoted text, click to view] > The other point an array is in fact in Net only usefull for fixed arrays. > For the rest the IList and Icollection implementing classes are much better > including the generic ones. The array has everytime to be redimmed. > Therefore I did not see the reason to use of a fixed array with a lenght of > real 0.
In my case, the array is created once. No ReDim. It returns a length of 0, or a length of x, x = number of solutions. But, yes, for something that is continually ReDimensions, collections are better. I know little about them other than that is what they are designed to improve. Zytan
I think people are misinterpreting my post. Just to be clear again: I am not stating anything about what option base the language should be. I just think, as with every other language in existence, when I want 10 elements, I should type "10" somewhere in the statement (unless I specify the min AND max bounds, like "0 to 9" or "11 to 20", which also indicates the number of elements I will get). This is independent of the Option Base status. [quoted text, click to view] > One hears a lot of people ask "Why isn't BASIC/VB more like C/C++?". > > This would be a fair question if BASIC was "invented" after C. But it was > the other way around and therfore the more appropriate question should be > "Why isn't C/C++ more like BASIC/VB?".
Right. And there's good answers to that last question. But, until I knew them, I liked 1-based indexing better. And I still see no reason why BASIC today can't have Option Base 1. [quoted text, click to view] > As for zero or 1 based indexing, we Homo Sapiens do not, intuitively start > count counting from zero. You don't hear someone say "I've made my zeroth > million.". Likewise there was no year zero between BCE and CE which is also > why the year 2000 was in the 20th century and is not in the 21st century.
Of course. The fact that you're explaining this to me indicates you misunderstood my post. Because I totally understand and agree. I wouldn't have any problem with VB starting its indexing at 1. Every BASIC I used did that, and I was happy. [quoted text, click to view] > Certainly computers count from zero quite happily because all bits off just > happens to be zero. Once it was determined that indexing from zero was > actually a very good idea the Option Base was introduced to BASIC to allow > it without destroying existing code, but this still predates VB.
Yes, and I never used Option Base, because I liked to count from 1, as all humans do, until they become programmers and realize what's happening under the hood. Option Base was a great option, it allowed people to 'move forward' with 0-based indexing, and as you said, allowed people to not destroy older code. [quoted text, click to view] > Another aspect to consider is that, unlike a lot of other languages, BASIC > is NOT controlled by a commitee. COBOL is controlled by CODASYL, C++ is > controlled by ANSI, etc. Those languages MUST, at least, comply with the > ratified standard, and anything else is a compiler-specific extension. What > VB/VB.NET does (or doesn't do) is purely up to Microsoft.
Yup. Microsoft wrote a lot of different BASICs back in the day. I'm not sure if people today realize this. They were certainly meant for people to grasp it quickly, as what BASIC means in both its name and its meaning. And to do that, you have to count starting at 1. [quoted text, click to view] > Certainly, Option Base is no longer supported in VB.NET (2005), but arrays > are still 'sized' by supplying the value for the upper-bound, the same way > it has been since before C was invented.
No. Arrays have always been sized by their length. Always. Every other language other than VB .NET is consistent with this. It is convenient to argue that it has "VB arrays have always been made using the highest index", since it is *technically true*. But, this coincidental truth is only true as a result of their decision to support old code. Just because it's true, it doesn't mean it has weight. It holds no meaning. It just happened to be. When reading code, people think, "that array is 10 elements in size", not "the highest index is 10". Many other 0-based languages use this same concept. They make you write "10" even though you get indexes 0 to 9. Pascal does this, and it is a language based on pseudo-code which is something meant for everyone to read, regardless of their language of choice. We could argue which (length or highest index), if not both, the original concept was intended to be. But, there is no argument as to what people believed it meant, or what is intuitively correct, which is what is important. There is overwhelming evidence that the vast majority of programmers thought of the number they were typing was 'length', not 'highest index'. All other languages fit that mold. Even when 0-based languages came about and made length <> highest index, people still made 0 to 9 index arrays by typing the length (10), not highest index (9). Only VB has broken the mold by making you use the highest index. And further evidence is the backlash of everyone who hates it. And people who don't hate it are wondering why there's an extra element in all of their arrays. The article I posted states this would be a known consequence, but it's better than breaking old code, which MS does care about. Zytan
[quoted text, click to view] > > "Why isn't C/C++ more like BASIC/VB?". > > Because BASIC wasn't intended to be used to write operating systems. Why > isn't a Mercedes-Benz more like the Ford Model-T since the Ford came first? > > > Before anyone launches in, that, of course, is purely rhetorical, but does > > help to put things in perspective. > > It's an odd perspective that suggests that modern things should be more like > the things cavemen used because they were first. Why aren't MP3s more like > 33 1/3 LPs, can't they make them scratch and warp? > > > As for zero or 1 based indexing, we Homo Sapiens do not, intuitively start > > count counting from zero. > > Homo sapiens do not calculate divisions accurate to 64- bits nor do run at > 65 MPH. These are machines. They aren't supposed to emulate people, we > have people for that. > > > You don't hear someone say "I've made my zeroth million.". > > I hear them say "my bad" so this should be the error message when the CPU > overflows? :-)
Well, Tom, I follow everything you are saying here, but I do believe that if VB is intended to be BASIC - Beginner's All-purpose Symbolic Instruction Code, then BASIC really should count from 1. Because it's FOR humans. I don't personally care, myself, since I know how to count from 0. My mind is wrapped around it, as is yours. Maybe even for the star programmer starting out at 4 years old, its best to have him understand 0-based indexing right away, but that's not was BASIC was originally meant for. [quoted text, click to view] > > Certainly, Option Base is no longer supported in VB.NET (2005), but arrays > > are still 'sized' by supplying the value for the upper-bound, the same way > > it has been since before C was invented. > > The article points out (if I read it correctly) that the arrays are sized > one larger than expected. Expect a bank transfer error any day now and it > will be due to "oh yeah the array was one larger than we thought."
Exactly. The code could be accessing an out of bounds element, but since you have 1 more than expected, you won't ever get the error during debugging. Ouch. And this is because when people type "10" they are thinking "length" not "highest index". I think VB forcing us to think "highest index" is absurd. AGAIN, they did it so that (most) older code will not break. It's a trade off. That's why VB has mistakes like this. It's ok to admit to them. It wouldn't have happened if VB6 didn't exist. Saying it was always like this because of a coincidental truth that VB arrays are always made by typing the 'highest index' doesn't negate the truth of the matter. (And I'm not even sure if that coincidental truth is actually true: When using Option Base 0, for old BASIC, did you really state the array size by its highest index? or was it still by array length?) Zytan
[quoted text, click to view] > 'Byte' and 'Byte()' are different, but 'Dim b() As Byte' and 'Dim b As > Byte()' will both declare an array of type "array of 'Byte'" ('Byte()'), > which contains items of type 'Byte'.
Yes, I know. My previous post was pointing out a seemingly contradiction, in that they are different, yet result in the same IL, so they are the same. Zytan
"Zytan" <zytanlithium@yahoo.com> schrieb: [quoted text, click to view] >> This page >> here http://msdn2.microsoft.com/en-us/library/7ee5a7s1(VS.80).aspx >> is the key to understanding why these forms are both valid. >> [snip] >> The page states that to specify that a variable is an array, you follow >> its >> variablename immediately with parentheses (as in the first form). > > Yup, I can see that. > > Also, from that page, it links to "How to: Create an Array with No > Elements" > http://msdn2.microsoft.com/en-us/library/18e9wyy0(VS.80).aspx > which says "Declare one of the array's dimensions to be -1", as you > mention later in your post. > >> Other information shows that Byte and Byte() are distinct data types. >> >> Byte is a value type. >> >> Byte() is a reference type derived from System.Array. > > Ok, so they really are two different things. 'Byte' and 'Byte()' are different, but 'Dim b() As Byte' and 'Dim b As Byte()' will both declare an array of type "array of 'Byte'" ('Byte()'), which contains items of type 'Byte'. -- M S Herfried K. Wagner M V P <URL: http://dotnet.mvps.org/> V B <URL: http://dotnet.mvps.org/dotnet/faqs/>
"Zytan" <zytanlithium@yahoo.com> wrote... [quoted text, click to view] > Well, Tom, I follow everything you are saying here, but I do believe > that if VB is intended to be BASIC - Beginner's All-purpose Symbolic > Instruction Code, then BASIC really should count from 1. > > Because it's FOR humans.
Discussions of this type tend to avoid defining (in any meaningful way) what "basic" or "easy" means with each person operating against their own definition. Keep in mind that BASIC supported the GOTO statement but not in GOTO <label> (which one might accept) but rather GOTO <line number> and of course line numbers change as the code is edited. But furthermore BASIC supported "computed GOTOs". In any case does this make GOTO statements "easy and basic" or "difficult, error prone and ultimately time consuming?" What (I suggest) would need to be done is a study on how many people-hours were wasted overcoming a feature designed to be easy. If the majority of the "target user" actually makes mistakes using a language feature then it is (by definition) not very easy. Personally I'm not affected by most of these design choices and in large part is the reason I suggest people avoid certain constructs even when a language permits them. These "features" have been determined (at least by me) to cause the problems that waste the time, and eventually the money. Take care, Tom
Zytan, This was just a silly decission in the time the conversion was made from VB6 to VBNet. Now all methods are working, those which are starting with a 1 (left) and those who are starting with a zero .Substring In my opinion there could have been done then a better job. Cor "Zytan" <zytanlithium@yahoo.com> schreef in bericht news:1172069066.125718.300400@h3g2000cwc.googlegroups.com... [quoted text, click to view] >> > Actually, VB .NET's attempt to ease code porting from VB6 by declaring >> > arrays using the highest index, rather than the array size like every >> > other language, is, personally, the worst thing I've even seen in the >> > language. The reasoning behind is interesting but very unconvincing: >> >> Two answer, with the above I don't agree with you. >> And before you understand it wrong, I have had much discussion with a >> very >> longtime C# guy on this board. In my opinion VB was using the 1 as >> starting >> indexer in fact the way it should be, the figure for first is 1. Numbers >> are >> represented by a characterset from 0 to 9. However oldies like me are >> used >> by the 0 as first indexer although it is in my eyes in fact completely >> foolish. Before somebody start to write why it is a zero. I know that. > > I know counting from 1 makes more sense to humans. I've used BASIC > before VB, and I was happy with option base 1. Learning about > pointers and C and Pascal made me realized why 0 is better. But, this > is all *irrelevant* to the issue I was raising: > > If I want 10 elements, I want to write 10. VB .NET says I need to > write 9. That's the issue I was bringing up. > > In fact, my point was that the issue of 0-based indexing or 1-based > indexing was a very unconvincing argument to start using the maximum > index instead of the array length. > >> The other point an array is in fact in Net only usefull for fixed arrays. >> For the rest the IList and Icollection implementing classes are much >> better >> including the generic ones. The array has everytime to be redimmed. >> Therefore I did not see the reason to use of a fixed array with a lenght >> of >> real 0. > > In my case, the array is created once. No ReDim. It returns a length > of 0, or a length of x, x = number of solutions. > > But, yes, for something that is continually ReDimensions, collections > are better. I know little about them other than that is what they are > designed to improve. > > Zytan >
[quoted text, click to view] > Discussions of this type tend to avoid defining (in any meaningful way) what > "basic" or "easy" means with each person operating against their own > definition. Keep in mind that BASIC supported the GOTO statement but not in > GOTO <label> (which one might accept) but rather GOTO <line number> and of > course line numbers change as the code is edited. But furthermore BASIC > supported "computed GOTOs". In any case does this make GOTO statements > "easy and basic" or "difficult, error prone and ultimately time consuming?"
I agree definition is important. Its the root of most arguments. I think it was 'easy' to just say GOTO 10, then to define a label, then type GOTO [label]. Even though it was error prone, it was easy. Easy isn't the same as robust. Learning GOTO was easy. Learning labels is harded (still somewhat easy, but not as easy). We are having a difference of definition already. [quoted text, click to view] > What (I suggest) would need to be done is a study on how many people-hours > were wasted overcoming a feature designed to be easy. If the majority of > the "target user" actually makes mistakes using a language feature then it > is (by definition) not very easy.
I agree and disagree. I disagree that features that allow mistakes means they are difficult. GOTO is easy. It can be taught in 2 seconds. Most people never screw it up. I never did. I never changed line numbers except with the automatic renumbering that hanldes GOTOs, as well. I agree that if something is prone to error, then it should be rethought. But, removed? I am not sure. To help the 1% of people who screw up their GOTOs by making it many times harder by introducing labels perhaps isn't a worthwhile tradeoff. [quoted text, click to view] > Personally I'm not affected by most of these design choices and in large > part is the reason I suggest people avoid certain constructs even when a > language permits them. These "features" have been determined (at least by > me) to cause the problems that waste the time, and eventually the money.
I think this is very smart. Zytan
[quoted text, click to view] > We're going to have to disagree. I can see no way that "line number 3500 is > the SAVE routine" could be easier than remembering that SAVE is the label > for the save routine and I'm left wondering why more languages don't operate > this way if that is the case.
I never said "3500" is easier to remember than "SAVE". "SAVE" is easier to remember. Anybody would agree with that. Definition, remember? Let me try to explain again: Explain to someone JUST STARTING to be capable of understading program flow. You're talking about subroutines. I'm talking 4 year old kids. 10 PRINT "FIRST" 20 PRINT "NEXT" 30 PRINT "THIS HAPPENS LAST" then, add program flow direction: 10 PRINT "HELLO" 20 GOTO 10 That's easier than labels. Procedures come into play on a higher level. First, you have to comprehend the computer does one thing at a time, in order. The above is what BASIC was for. Really. People actually (or used to) write 8 line length BASIC programs. It's used in school math books everywhere. [quoted text, click to view] > As far as you not messing it up. I'd be surprised if you didn't type in the > wrong line number once in awhile but are you talking about 15 developers > working on a 500,000 line project or you working alone on a small utility?
Hahahaha, sorry, we are on different wavelengths. I'm talking 100 to 200 line length programs MAX when I was a kid. GOTOs were on the same screen. Of course MUCH more code could fit onscreen at once, like 5 or 10x more than today's languages using the colon ":" (it still exists, no one uses it, though), since it helped speed it up giving that it was interpreted. So, I'm talking elementary, basic BASIC. Not making OS's. Here's an idea of some code: http://en.wikipedia.org/wiki/BASIC [quoted text, click to view] > If you have anything which backs up the claim that people learned the GOTO > statement in 2 seconds, that only 1% of the developers screwed up and that > labels are "many times harder" I'd love to see it. Are functions and > procedures harder as well? And aren't they specialized labels?
I have no evidence. I just know I learned GOTO in 2 seconds. Label adds two things to use, rather than one with GOTO. I think it's easy to see that a 4 year old would understand GOTO 10 much more quickly than using a label. It's just less stuff to take in all at once. Of course to anyone older, it's not that big of a deal, but still, however easy, it's harder. I'm taking relative, you're talking absolute. Yes, functions and procs are harder, of course. Were you serious about that? They are an order of magnitude more difficult! I grasped them in seconds, having programmed without them for years, and thus immediately realizing exactly why they were good. But, go look at any first year programming course, especially in non-comp sci degrees, and see how quickly people grasp functions. It's WAY harder. I can only assume you are speaking from the perspective of an experienced programmer. Yes, I would agree with you that to you and me and other experienced people it's all elementary. Zytan
"Zytan" <zytanlithium@yahoo.com> wrote... [quoted text, click to view] > I agree and disagree. I disagree that features that allow mistakes > means they are difficult. GOTO is easy. It can be taught in 2 > seconds. Most people never screw it up. I never did. I never > changed line numbers except with the automatic renumbering that > hanldes GOTOs, as well. I agree that if something is prone to error, > then it should be rethought. But, removed? I am not sure. To help > the 1% of people who screw up their GOTOs by making it many times > harder by introducing labels perhaps isn't a worthwhile tradeoff.
We're going to have to disagree. I can see no way that "line number 3500 is the SAVE routine" could be easier than remembering that SAVE is the label for the save routine and I'm left wondering why more languages don't operate this way if that is the case. As far as you not messing it up. I'd be surprised if you didn't type in the wrong line number once in awhile but are you talking about 15 developers working on a 500,000 line project or you working alone on a small utility? If you have anything which backs up the claim that people learned the GOTO statement in 2 seconds, that only 1% of the developers screwed up and that labels are "many times harder" I'd love to see it. Are functions and procedures harder as well? And aren't they specialized labels?
Sorry again... this only highlights the need for a definition. I just about never describe programming constructs as easy or hard in terms of children. To me it isn't relevant any more than suggesting that this year's Academy Award for best picture be awarded based upon the movie kids under 5 think is the best. Would you agree that it would be easier for a 4-year old if you removed the need for line numbers? If "easy for anybody" is the goal why not just process code in the order it encounters it? How about if you type PRNIT "FIRST" it figures out you meant PRINT, wouldn't that be easier, ergo an even better language? I don't happen to think so but the kid in the crib across the street surely does. :-) [quoted text, click to view] "Zytan" <zytanlithium@yahoo.com> wrote in message news:1172195039.987265.317950@s48g2000cws.googlegroups.com... >> We're going to have to disagree. I can see no way that "line number 3500 >> is >> the SAVE routine" could be easier than remembering that SAVE is the label >> for the save routine and I'm left wondering why more languages don't >> operate >> this way if that is the case. > > I never said "3500" is easier to remember than "SAVE". "SAVE" is > easier to remember. Anybody would agree with that. > > Definition, remember? Let me try to explain again: > > Explain to someone JUST STARTING to be capable of understading program > flow. You're talking about subroutines. I'm talking 4 year old kids. > > 10 PRINT "FIRST" > 20 PRINT "NEXT" > 30 PRINT "THIS HAPPENS LAST" > > then, add program flow direction: > > 10 PRINT "HELLO" > 20 GOTO 10 > > That's easier than labels. > > Procedures come into play on a higher level. First, you have to > comprehend the computer does one thing at a time, in order. > > The above is what BASIC was for. Really. People actually (or used > to) write 8 line length BASIC programs. It's used in school math > books everywhere. > >> As far as you not messing it up. I'd be surprised if you didn't type in >> the >> wrong line number once in awhile but are you talking about 15 developers >> working on a 500,000 line project or you working alone on a small >> utility? > > Hahahaha, sorry, we are on different wavelengths. I'm talking 100 to > 200 line length programs MAX when I was a kid. GOTOs were on the same > screen. Of course MUCH more code could fit onscreen at once, like 5 > or 10x more than today's languages using the colon ":" (it still > exists, no one uses it, though), since it helped speed it up giving > that it was interpreted. So, I'm talking elementary, basic BASIC. > Not making OS's. Here's an idea of some code: > http://en.wikipedia.org/wiki/BASIC > >> If you have anything which backs up the claim that people learned the >> GOTO >> statement in 2 seconds, that only 1% of the developers screwed up and >> that >> labels are "many times harder" I'd love to see it. Are functions and >> procedures harder as well? And aren't they specialized labels? > > I have no evidence. I just know I learned GOTO in 2 seconds. Label > adds two things to use, rather than one with GOTO. I think it's easy > to see that a 4 year old would understand GOTO 10 much more quickly > than using a label. It's just less stuff to take in all at once. Of > course to anyone older, it's not that big of a deal, but still, > however easy, it's harder. I'm taking relative, you're talking > absolute. > > Yes, functions and procs are harder, of course. Were you serious > about that? They are an order of magnitude more difficult! I grasped > them in seconds, having programmed without them for years, and thus > immediately realizing exactly why they were good. But, go look at any > first year programming course, especially in non-comp sci degrees, and > see how quickly people grasp functions. It's WAY harder. > > I can only assume you are speaking from the perspective of an > experienced programmer. Yes, I would agree with you that to you and > me and other experienced people it's all elementary. > > Zytan >
[quoted text, click to view] > Sorry again... this only highlights the need for a definition. I just about > never describe programming constructs as easy or hard in terms of children. > To me it isn't relevant any more than suggesting that this year's Academy > Award for best picture be awarded based upon the movie kids under 5 think is > the best.
Yes, you're right. I guess I assumed we were talking about children since we were talking about BASIC and GOTO [linenumber]. [quoted text, click to view] > Would you agree that it would be easier for a 4-year old if you removed the > need for line numbers?
Perhaps. But labels still require two things, where line numbers don't. The line numbers are labels, yes, but they signify each line. Labels don't. So, it requires something extra to understand. I could see something asked such as "what does that (the label) program statement do?" "nothing, it's just a label that another statement references". Also, a linenumberless BASIC needs an IDE, which is more complex than using the environment for coding and running (like the immediate window). The only way to really know is to test it with kids. [quoted text, click to view] > If "easy for anybody" is the goal why not just > process code in the order it encounters it?
I think line numbers clarify exactly what each statement is. But, you may be right. [quoted text, click to view] > How about if you type PRNIT > "FIRST" it figures out you meant PRINT, wouldn't that be easier, ergo an > even better language?
That's true. But that may teach it as a language like english where it's ok as long as you're close. That's not really a good thing for logic languages. You wouldn't want that in the language of math. Zytan
Don't see what you're looking for? Try a search.
|