|
Is option base available in VB.NET versions?
- Life is a fountain
|
|
|
|
|
My zero'th thought was: why should I use 1 and not some other number? Just stay with zero which can express both offset from the beginning of an array and element's position.
Greetings - Jacek
|
|
|
|
|
... because it indicates really advanced and complex programming.
|
|
|
|
|
humm ... Starting at 90 degrees ? "Dogy style arrays" ??
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
|
42!!!! How?
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
|
|
|
|
|
Hitch Hiker's Guid to the Galaxy - 'The answer to the life, the universe and everything is: 42' XD
|
|
|
|
|
|
It just occurred to me.
In Australia the first level of the building is the "Ground Floor". Next level up is the First floor. So when you get in a lift, to go one level up you press "1".
Is it in the UK or USA (don't remember) where this is not the case. On ground floor, you ARE on 1st floor! If you want to go one level up you press "2".
So in Australia we use 0 based buildings! What about you?
|
|
|
|
|
Confirmed. I've been to Cyprus and seen that most buildings with ground-level 0th floor (usually non-living) and -1 for basement/parking/tech/etc.
In Russia 99.9999% buildings have floor count starting from 1. I like the 0th floor idea better.
in another thousand years we'll be machines or gods█
|
|
|
|
|
Italy has 0 based buildings. As the most of Europe.
In London I foud high building with no 13 and 17...
Some airplane are 3-based (there is no 1 & 2: probably are the toilets) and skip 17 ...
2 bugs found.
> recompile ...
65534 bugs found.
|
|
|
|
|
<small>Kamran Behzad wrote:
In Australia the first level of the building is the "Ground Floor". Next level up is the First floor.</small>
In the US, generally the floor you walk in on is 1, the one above you is 2, etc.
There seems to be a growing trend to have a star beside the elevator button that most people will think is the "main" floor (generally a lobby).
If there are multiple floors below the main (ground/first) floor, there is generally a prefix (sub/park/etc.) plus a number. The below ground numbers will sometimes be ascending (1 being the lowest available floor) and sometimes descending.
I've heard that older buildings skip the thirteenth floor, but I've only seen that once, so it's either a regional truth or largely a myth - not sure which.
FWIW,
-Chris C.
|
|
|
|
|
As someone suggested it is a religious war. But maybe here is a way to peace.
Here is a scenario:
You load a date value from your DB. Then you want to display an image depending on the month value. So you use something like image[month], month being derived from your date value. Alas you get an error on image[12] and you realise despite voting for zero-based arrays on CodeProject, and implementing such in your code, your evolutionary past has made you make an off-by-one error. Your computer counts the months from 0 to 11 but you do from 1 to 12. And no matter how hard you try, after decades of programming, you cannot not make these mistakes.
So what do you do, Either of two things:
1) Waste image[0] and use image[1] to image[12]
2) Modify your reference in code to read: image[month-1]
Are 90% of voters telling me they prefer not wasting memory (of what could be as little as one byte), instead preferring to have the additional subtraction in their code?
I prefer to sacrifice element 0 for clarity in my code, not to mention saving the extra subtraction operation.
Having said that, as pointed out by many others, many representations require us to also be able to represent absence of something, such as a primary color in a color combination. We simply cannot do without a zero index there.
So, my conclusion: let's put our religious preferences aside. In each case do what is practical and comes more naturally.
|
|
|
|
|
That seems to me like a troubling coding practice.
Consider that if your array is an array of extremely large structures, say of 500 megabytes each, then it can hardly be said that you are losing only one byte (that entire space will be allocated for one such structure, complete with all of it's fields set to their defaults). Yes, I voted zero, and I am not in the habit of wasting 500 megs, or any other sizable chunk of memory, just for the sake of my code being a little more "human-readable"--whatever that's supposed to mean these days. To that end I cringe at the thought of wasting even just one byte, but maybe that's because I had an inspirational C teacher who wanted me to know whether ++i or i++ was faster by a matter of picoseconds, with gcc optimizations turned off, or how to beat quicksort when given numerous details about the distribution and type of data to be sorted (perhaps a non-comparison sort? linear time, anyone?). On the matter of forsaking the entire 0th element in an array for no reason other than "taste," I politely refuse--so fire me.
-Gatsby
|
|
|
|
|
Jay Gatsby wrote: Consider that if your array is an array of extremely large structures, say of
500 megabytes each, then it can hardly be said that you are losing only one byte
(that entire space will be allocated for one such structure, complete with all
of it's fields set to their defaults).
You would be crazy to have an array of large structures. Use an array of pointers to the structures, much more efficient when it comes to sorting and stuff like that. Also, then it not very expensive (4 byte on a 32 bit machine) to skip element zero.
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
That may be so in some cases, but consider that my example is a theoretical to begin with. To the point, I can turn around and say "yeah, but suppose you're programming in some god-forsaken language that completely hides pointers from you entirely, and uses references rather unintelligently." The example I gave was to illustrate the fact that memory is going to waste, period. Whether you're wasting a 4-byte pointer or a 500-megabyte data cell, it's still a waste, and my point still stands--that's just silly.
Suppose you have an algorithm which uses 4 byte pointers to 500 megabyte data cells that requires 125,000,000 copies of this list to be made in order to do some computation. one 4 byte pointer times the 125,000,000 times it's wasted is 500 megabytes total of wasted memory--hah, you see what I did there? I can contrive extreme examples all day, but the point is still the same, a waste is still a waste, regardless of size.
-Gatsby
|
|
|
|
|
"To that end I cringe at the thought of wasting even just one byte..."
So you would rather waste the space taken by the assembly code for subtraction and a tiny bit of time?
"Learn from the mistakes of others. You can't live long enough to make them all yourself."-Unknown
|
|
|
|
|
I would rather be as efficient as possible, period--regardless of what that actually means in any context, which is probably why I write my for loops as for(int i=0; i!=count; ++i) in the same code file where I use the 0th element of the array and index from zero in a mere 10 integer array. The only place where there is even room for debate on this issue is time vs space trade-offs, at which point I'm open for arguments. As it stands, however, the original suggestion here was simply to ditch an entire array element for no reason other than "well, humans count from 1." There is no reason to write bad code, ever, even if you know that the compiler optimizations will fix it, even if you know it's not time or space critical in the slightest, or any other reason to be lax about efficacy. I don't know how else to illustrate it.
-Gatsby
|
|
|
|
|
You don't need to waste anything.
If we're choosing the array bounds we can choose 1 and still let the compiler assign the first element at offset zero.
An RGB color isn't a array (to my way of thinking) it is three values.
We would gain nothing in clarity by using 1-256 instead of 0-255, so I'd leave that alone.
Same with IP addresses, you just leave it alone because you gain nothing by fooling with it.
(doesn't really even mean anything as a number)
And I'll shut up now
|
|
|
|
|
When you start counting something, do you start at zero?
Sure, zero makes sense at the basic level and made sense in assembler and when you deal with pointers and stacks.
But in these days where programmers deal with objects a lot more than they do with bits; where the representation of data has been transformed into something all humans deal with every day of their life, objects; it makes sense that things such as this are also humanized and we should start to count at 1, just as humans do.
For humans, zero is the absence of something. One means that there is at least one element.
Jacques Bourgeois
|
|
|
|
|
Humans start counting at one, but start measuring at zero. So if you say, "On the third day he will come", what you are saying is that it will be two more days before he comes. This leads to a lot of confusion in interpreting ancient texts, because in ancient times they counted (where today = day 1, etc.), but in modern times we measure (today -> third day = 2 days).
|
|
|
|
|
Hans Dietrich wrote: Humans start counting at one, but start measuring at zero.
Heh. I really appreciate you bringing to light that distinction.
Hans Dietrich wrote: This leads to a lot of confusion in interpreting ancient texts
Interesting! I didn't know that!
Marc
|
|
|
|
|
Marc Clifton wrote: Interesting! I didn't know that! Yes, there's an obvious religious text I could quote, that illustrates exactly this problem.
|
|
|
|
|
Hans Dietrich wrote: Yes, there's an obvious religious text I could quote, that illustrates exactly this problem
Genesis?
Marc
|
|
|
|
|
Heh. I'll just say it has something to do with something happening on the third day.
|
|
|
|