|
#define BASEADDR (0xFFFF0000)
char* hardwareX = BASEADDR;
hardwareX[0] = 'a';
printf("%d\n", &(hardwareX[0]));
prints: 0xFFFF0000
printf("%d\n", &(hardwareX[1]));
prints: 0xFFFF0001
printf("%d\n", &(hardwareX[2]));
prints: 0xFFFF0002
printf("%d\n", &(hardwareX[3]));
prints: 0xFFFF0003
Seems very logical to me to use zero based indices
"Program testing can be used to show the presence of bugs, but never to show their absence."
<< please vote!! >>
|
|
|
|
|
|
Seriously, I cannot decide what to vote for, when I do have no CListCtrl option. Please add!
|
|
|
|
|
It's there, but since it lies outside the accepted range of array answers, it's not being displayed.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- "Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
Try shifting your asses off 'The Cloud' and learn a little history and probably some basic computing too
|
|
|
|
|
I have always thought it crazy that the first element of an array had to be element zero.
That makes no sense to me at all, and yet the vast majority here voted for it.
I shake my head in disbelief.
|
|
|
|
|
I'd have been very concerned if the vote had been the other way round.
|
|
|
|
|
Me too, that would mean an over-population of VB coders!
|
|
|
|
|
Never heard of FORTRAN?
|
|
|
|
|
Even VB coders know that starting an array at 1 is just wrong. We did it for years because we had to, but we always felt guilty about it.
There are two kinds of people. Those who need closure
|
|
|
|
|
I don't uderstand all the hate on VB programmer, its kinda discriminating, like somebody "is a lesser being" just because they use a language that somebody dislikes, or considers bad. Anyway I preffer starting in 0, eve though this disscussion is a little pointless and of obvious results.
|
|
|
|
|
I'm not a VB Coder, and never have been, im a Java, C#, and Pascal Coder, and i have been programming for 30 years.
And i have always thought that the first index of an array should be index 1.
'First' and 'One' simply match. Having to use the the length of whatever you are parsing 'minus 1' in every loop, is silly.
IMO 1 .. N, makes more sense than 0 .. N-1,
There are so many here defending the zero based index .. passionately even. Amazing.
|
|
|
|
|
mojp wrote: Having to use the the length of whatever you are parsing 'minus 1' in every loop, is silly.
If you run your loops with a limit < Length instead of <= Length-1 then you don't have to subtract 1 every time.
|
|
|
|
|
May be you should have started with C ...
Think about it another way:
- you have read NOTHING (count=0)
- you read in the FIRST element into an array (array[count]) ==> array[0]
- you increment the read counter (count++)
- you read in the NEXT element into the array (array[count]) ==> array[1]
after you finished, you have the count already.
Additionally, as many others mentioned, an array is nothing more than
an contingous area of memory, and (in C) a reference to the entire array
is the start address of the memory area (array == &(array[0])), and
you can also read an element with dereference of the pointer plus offset
*(array + offset) == array[offset] / array + offset = &(array[offest])
|
|
|
|
|
T GetRandomElement(T[] array)
{
return array[NextRand() % array.Length];
}
T[] Reverse(T[] input)
{
T[] output = new T[input.Length];
for (int i = 0; i < input.Length; i++)
output[output.Length - i] = intput[i];
return output;
}
Try doing these with 1-based arrays and you'll find that you'll need ugly "+1" for most of the array accesses.
In fact this extends to many algorithms; 0-based arrays tend to lead to cleaner code and less potential for off-by-one errors. Dijkstra's argument for 0-based arrays[^] explains why.
modified on Tuesday, March 8, 2011 1:48 AM
|
|
|
|
|
Starting from 0 is also consistent from a mathematical point of view: remind set theory, Peano axioms and natural numbers.
|
|
|
|
|
Does that code work? Because as I read it, say input has a length of 5 (0...4). i = 0 -> 4, therefore in your output = input line output[output.Length (5) - i (0)] is outside of your array. C isn't my primary language, so I might have got it wrong.
In VB, it would work by using UBound() instead of .Length.
I still advocate 0 as base element, because array's are pointers to a chunk of memory, and the element is an offset into that memory. Naturally, there is no offset (0) for the first element.
|
|
|
|
|
Here is where they get ugly:
You have a binary search that not only returns the index of the found item, but if the item is not found it returns the negative of the index that it would have had, had it been in the list. In other words if the user wants to check for duplicate values before inserting an item in the list then a result of say -4 tells him his new value is not in the list but can be inserted at position 4.
All good so far.
Now what happens if the new number is smaller than any number in the list (assuming the list is ascending). It must be inserted at index 0 (assuming 0 base array). What is the algorithm to return? It cannot return -1 because that means the insertion must be at index 1. And there is no -0 !
In my own implementation, in such case I am returning int.MinValue and check for it in the calling process. But it's ugly coding!
|
|
|
|
|
You can just use ~ instead of -. At least that's what System.Array.BinarySearch is doing.
|
|
|
|
|
Actually,
I can't understand that,
the person or group who had firstly made array, what ever language he first created
why using 0 as starting point whereas it is very confusing.
i am confuse about it since i have started learning languages.........
Thanks........
|
|
|
|
|
Because in the early days there was no concept of an array, just a memory pointer.
So, to have a list of numbers, you set a pointer to the first one, and then added the length of the number in bytes to the pointer to get to the next.
When arrays where developed, the code was simple:
array[index] = 6 became
Set pointer to array start;
set accumulator to index;
multiply accumulator by array element length;
add accumulator to pointer;
Set contents of pointer to 6; So, arrays started at zero.
It does make sense, numbering starts at zero in nature: I have no oranges, I have one orange, I have two oranges...
Remember all the fun the Romans had, because they didn't have a zero?
Real men don't use instructions. They are only the manufacturers opinion on how to put the thing together.
Manfred R. Bihy: "Looks as if OP is learning resistant."
|
|
|
|
|
It should start at 1, but the poll shows that the majority has been influnced by C-like languages and accepted the reality...
Best,
Jun
|
|
|
|
|
Well you can't realy expect after all this years using arrays starting in 0 everybody suddently thought "Oh wait, let's start by 1 instead beacuse we're kinda bored with the 0"
|
|
|
|
|
I've a devoted VB programmer... from VB3... zero based was always my preference. I don't really care personally, I just want uniformity and most major big boy languages (including VB) are default to or allow with a lot of use to zero based. In low level systems, it's a requirement. In high level systems it's trivial debate. We all use numbers for arrays (I hope, I've never seen a language that uses letters or counts pipe symbols) so lets just keep one rule.
When I actually thought about this argument I realized I've almost stopped using single dimensional arrays, which I feel like is the only type where this debate has real meaning. More complex collections objects are easier to use unless you really need the performance and multi dimensional arrays so often represent a physical plane which naturally starts at (0,0) or (0,0,0) I feel it's not worth the occasional loop help to have a 1-based system ever... come to think of it, I don't use For much either, always For Each and Do... Loop w/cursor (when deleting from collections).
|
|
|
|
|
I'm just glad they made their minds up and hope they stick with it. What pisses me off is when you run up against some antiquated tool that uses a different (1) base.
Never underestimate the power of human stupidity
RAH
|
|
|
|