Yes, the difference between Open Source and closed source is that often the Open Source project gets visible before it gets finished, therefore you see the projects that failed early on. OTOH closed source is usually not released before the developer considers it ready for use, therefore you'll never get to see most failed close source projects.
When adding, the processor set a bunch of flags, some of which (like carry) only make sense when interpreting as unsigned values, others (like sign or overflow) only make sense when interpreting as signed values. Therefore it is wrong to say that the processor only interprets the numbers as unsigned. Anyway, even if there's no difference, it is nonsense to single one of them out and claim that the processor uses that. If both are indistinguishable, then the processor obviously doesn't distinguish between them.
But then, addition/subtraction is special in that regard. You already mentioned one example, arithmetic shift. Other examples are multiplication and division instructions. And yes, of course they are separate instructions, just as in signed magnitude implementations you need separate instructions for signed and unsigned addition, because they simply have separate results. But that there are instructions for both means that the processor does not single one out as the "correct" one. A processor which had only instructions (and flags) for one of the interpretations could be said to do that.
(BTW, it's two's complement, not two's compliment; it's not about telling people nice things about them).
Oops, "Thus you cannot imply from the existence of an element 0, that there is an element 0." is of course nonsense. It should read "Thus you cannot imply from the existence of an element 0, that the first element is element 0."
Which, due to 20 bit addressing and wrap-around is directly followed by the address 0.
So you agree there's an address 0? The rest is just a lot of handwaving to try and avoid admitting that its counting from zero.
From the processor's view (which has arithmetic operations, and therefore a natural interpretation of binary patterns as numbers), there is indeed an address 0. I never denied that. But that does not imply that the memory is naturally(!) a zero-based array. First, the (-128)-based array of 256 elements has also an element with index 0. Thus you cannot imply from the existence of an element 0, that there is an element 0. Second, as I already explained several times, there may (and in general will) be holes in the range of existing memory, making the 0-based array model of memory not an exact fit.
To avoid holes in memory you then tried to turn to single memory bars, which are not only completely irrelevant as far as the programming model goes, but at which level the address is no longer naturally a number. You can somewhat recover a numeric value if you look at the physical design of a memory chip, except that it consists of a two-dimensional array of memory cells, so the address from that view is not one number, but two. And if you look at the complete memory bar, then some of the address lines will be used for chip selection, so you'll get three numbers. That is, even then at the chip level you don't really have an address 0, but at best an address (0,0,0) (and that's assuming that the bits are addressing the lines/columns/chips in order, which may not actually be true).
The reset vector for the 8086 processor is at address FFFF0h (16 bytes below 1 MB).
Yes. But (and I put it in bold because copy repeatedly ignored that fact, despite me repeatedly telling you): At that point I was no longer speaking about the reset vector. Maybe you get back to my original post and actually read it. Here's a hint for you: Context matters.
Its somewhat clumsy, but there is nothing unnatural about the actual numbering itself. the segment and offset overlap in a very simple logical way.
Logical != natural.
As if you don't know the answer:
0000 = 0 0001 = 1 0010 = 2 0011 = 3
Only if you interpret them as binary numbers. Which in the memory hardware isn't natural. Rather, each bit by itself gives a two-way selection of different subsets of memory cells.
Whatever cell 1111 wired to is logical 15.
Anfd here you're even wrong as far as the processor goes (well, assuming a full value, of course). An all-1 can as well be interpreted as -1. The processor has instructions for both interpretations.
For example, the 8086 expects to be able to read instructions starting at address FFFF0 (note that 8086 physical addresses had 20 bits). Therefore if you interpret addresses as signed values, you could say that the natural base of 8086 memory is -16.
That's the reset vector, and its not the 'first address' it can read, its simply the address it reads from by default after a reset.
Are you intentionally misinterpreting what I wrote? This address is the temporally very first address the processor reads, and therefore the processor assumes that there's something to read starting at that address because otherwise it could not work. And due to the way the hardware wrks, this means that all of F0000 to FFFFF is available. Which, due to 20 bit addressing and wrap-around is directly followed by the address 0.
Therefore you could also say the original IBM PC had a natural base of -65536.
Yes, clearly that would be the most natural way of interpreting that... no. wait. That would be a pointlessly convoluted way of interpreting it. Ditto for treating FFFF0 as -16, which is just plain silly because its probably more accurate to write it as FFFF:0000. That would be address 0, in segment FFFF.
Sorry, but that address I was speaking about at that point (first address of BIOS ROM in the original IBM PC) is definitely not represented by FFFF:0000. Anyway, the address represented by FFFF:0000 can as well be represented as F000:FFF0. Or as FF00:0F00. Or as FF80:07F0. Or as F123:EDC0. Or...
Anyway, this segmentation is a speciality of the 8086; it is in no way natural, but was done mostly to provide the possibility of automatic code translation from the earlier 8080.
Of course that neglects the video memory mapped in a region
Sorry. No. That all happens on top of the physical address space. Think about the RAM or ROMs, not the more complicated stuff layered on top of them.
In the original PC, this happened at the hardware level. For the CPU, there was no difference between normal RAM and video RAM. I don't know how it is in more modern computers, but I guess it gets still mapped at hardware level for efficiency reason.
But anyway, even if you don't consider video memory, the point remains that if you consider the memory as starting at 0, there was generally a gap between the last RAM address and the first ROM address.
Therefore (a) the interpretation of memory as an array is not a perfect match,
A stick of RAM as an array of cells is really about as perfect as it gets.
The processor doesn't address a stick of RAM (you don't have instructions to read cell X from stick Y). The fact that your memory is organized in sticks is just as irrelevant for the programming model as the fact that it is made of semiconductors, and that the electrons are ultimately described by quantum mechanics. Anyway, even on that lever, you're wrong.
and (b) even if you do so, there's absolutely no reason to assume it is 0-based.
How are the physical addresses in a DRAM chip numbered? (and what signals would you need to put on the wire to read or write to the cell? )
If you go to a single stick of RAM, you'll find that for any address there is a corresponding memory cell. Which one is the first is therefore simply a question of declaration, not a question of naturalness. Indeed, if you look at early memory chips without all the modern optimizations, you'll see that if you exchange two address lines on the chip it won't really matter, because while it will read a different physical memory cell, it will do so consistently. Which demonstrates that at this level the address isn't even a number, but just a bit pattern.
That's right, they start at 0, always. Whether its a 128 byte rom from 197
If the plane was shot down and that fact was covered up (that theory is IMHO much more credible than the theory that the plane didn't exist at all), then of course you'd not find a single impact site (because the plane exploded in the air), The debris would then probably be distributed over a wide area, so that very little would be at any place. Moreover they would probably have been eager to remove any evidence of the shooting before presenting the place to the public, further reducing the debris.
Unlike arrays, memory may have arbitrary holes. For example, most 8086 PCs had a hole between the end of RAM and the beginning of ROM. Moreover, each address may or may not correspond to a memory cell; it's purely the hardware which decides which addresses correspond to available memory cells.
Anyway, address 0 is no special in this regard, unless there's something in the processor which expects memory there; but that's true for any address where the processor expects something. For example, the 8086 expects to be able to read instructions starting at address FFFF0 (note that 8086 physical addresses had 20 bits). Therefore if you interpret addresses as signed values, you could say that the natural base of 8086 memory is -16. Of course the 8086 also expects the address 00000 to be available, because it puts the interrupt table there. Moreover, in the original IBM PC, you were guaranteed to have ROM starting from F0000 through FFFFF is available as ROM and from 00000 to 7FFFF is available as RAM; memory above that may or may not exist. Note that this is a continuous area if you consider address wrap-around. Therefore you could also say the original IBM PC had a natural base of -65536.
Of course that neglects the video memory mapped in a region which may or may not be adjacent to existing RAM and/or ROM memory addresses. So the total memory is in general not even contiguous. And even if it is, the address 0 is not special in any case.
Moreover, if you don't look at the real memory, but at the virtual memory in modern CPUs/operating systems, you'll find that address 0 (more exactly, the memory page 0; on x86 that's the address range from 0 to FFF) is typically not mapped (so that null pointer dereferences are caught by the hardware). Therefore you might also claim that virtual memory is a 4096-based array, because that's the first virtual address which actually corresponds to existing memory. Which of course assumes that virtual memory is assigned as a single block; this assumption may well be violated if your program uses shared memory and/or memory-mapped files.
To summarize: There's nothing special to the memory address 0 which would make it the natural "begin" of memory, and there's no guarantee that memory is contiguous (which arrays per definition are), and this applies both to physical and to virtual memory. Therefore (a) the interpretation of memory as an array is not a perfect match, and (b) even if you do so, there's absolutely no reason to assume it is 0-based.
Google patented a method to help cover the costs of free wireless access balloons.
More exactly, Google applied for that patent and asked for that application to be kept secret, and then promoted that method as a way to give cheap broadband to rural areas without revealing that they had applied for a patent for this.
I couldn't care less about the fact that they might also make money by using that method on festivals. But promoting a technology, especially as solution for the poor, without revealing that you applied for a patent on that very technology is dishonest.
Given that the attackers planned to crash into the white house, I can imagine that at that time, they were no longer that high.
I don't see any plausibility for the claim that the airplane didn't exist in the first place. After all, the planes crashing into the WTC definitely existed. Even if you believe in a government conspiracy crashing those planes into the WTC, then it should not have been a problem for them to get another plane crashing into the floor. And given that they could get it, not getting it would have been incredibly stupid.
So no matter whether you believe in a government conspiracy or not, assuming that plane didn't exist does not make sense.
I guess the family members didn't ask "how are you able to call me" and didn't really think about the question. For them it was a no-brainer that if their relatives called them it was by cell phone. That this would have been a problem on the plane probably didn't occur to them.
If all you want to do is to test for equal/not equal, you don't need a subtraction. You can just do a bitwise comparison.
Of course the way you'd do it in hardware is to xor the corresponding bits and test the result against zero, so at the fundamental level you're right. But the circuit is so simple that I'd expect it to still finish in one cycle, so a processor implementing that would not necessarily be slower in comparing a value to zero than in comparing two values to each other.
However usually the processor, when doing arithmetic, already does certain tests anyway, and one of those tests you get "for free" is the test for zero. So in many cases (especially in the case of loops), the test for zero needs zero additional instructions; it's part of the loop arithmetic anyway.
Mathematically, it does: The set-theoretic definition of the natural numbers (and more generally, the ordinals, which also include infinite numbers) is that every number is the set of all preceding numbers. So the number three is the set containing exactly the numbers zero, one and two.
So he enumerates the elements of the number of stones ("zero, one, two") and then tells the name of that number ("three").
The abstract concept of a type and the implementation details of that type are not the same thing, although they are both important for a programmer to know.
Agreed.
But obviously not understood:
Languages that have a richer abstract model for arrays, rather than having arrays be merely syntaxic sugar for pointer arithmetic, also allow far more static analysis, allowing opportunities for the elimination, optimization or parallelization of processing that a C compiler would struggle to identify.
That tries to argue the point by suggesting that a richer language and more abstract models hides the implementation details. It hides the implementation detail that its still zero based.
No. The array is completely a language-level concept. At the machine-level, there are no arrays, neither zero-based ones, nor otherwise. You just have memory addresses and arithmetic operations. Zero-based arrays enable a particularly simple mapping between both (but not as simple as you seem to imply, because for almost all arrays, you'll have to do a multiplication with the array element size, which probably costs much more performance than the addition of 1).
Things are still zero based. You can jump through some hoops to try and hide this from the programmer if you want, but that's all you are doing, and if the programmer ever has to dig into the real guts of what's going on he or she is faced with the cold reality that everything is zero based behind the scenes.
No. It is trivial to code an 1-based array (or a 42-based array) in assembly: Instead of the true address of your array, use a value that differs by the element size (or 42 times the element size) to denote your array. You may need to rely on overflow-wrapping to do this, but that's OK, because overflow-wrapping is well-defined in assembly. Note again that the array is not in the computer (in case of assembly, it is not even really in the assembly code), but only in your interpretation of what the code does. The code itself does nothing but arithmetic and indirect memory accesses.
And its not just arrays. Its strings. Its the virtual pointer table internal to a c++ class object instance. If they dig all the way down to assembly language its the stack, its the member offsets of class/object members. Anything and everything that uses offsets.
You just proved that you don't have understand C++'s object model. What the virtual table contains is function pointers pointing to member functions of the object (those are ordinary addresses, not offsets). It may in addition contain an offset of the object as base object in a derived object (that's not the only possible implementation, but probably the most common; if it's a complete object, those offsets are of course all zero). But it never contains offsets of members (well, strictly speaking you can put whatever you want into a virtual table because it is not specified by the standard, but putting member offsets there would just be a waste of resources).
If we want to mostly hide that for programmer convenience in high level languages that's fine. But lets not pretend its some "artifact of C". Its how computers really work. And a good programmer should know that, even they use a higher level language where they don't have to think about it most of the time.
Since the computer doesn't know arrays at the fundamental level, every property of an array (including its existence) is an artefact of the language.
Anyway, the reasonable choice it to let the user choose the lower index according to his needs. Because if the index numbers you get are 1-based, all your 0-based arrays do is to move the subtraction of 1 from being created by the compiler to being explicitly written by the programmer. Which doesn't make the code the slightest bit more efficient.
There are many cases where 0-based indexing is just the right choice, but there are also cases where 1-based indexing is more natural, and there are even cases where you'd start somewhere else (because your numbers happen to start at that value).
Also, making all arrays 0-based is a premature optimization, which is the root of all evil.
Add 0 to the well-ordered set and change the algorithm so you start taking out elements from the sorted set. This way you naturally include the empty set and you tag the algorithm (retiring the zero means "hey, I start counting)
That's a very unnatural way of including zero. Versus the natural way outlined in the last paragraph of the parent.
Slashdot Mirror
There may not be "the rest of the team". You are confusing "closed source" with "company-developed".
Yes, the difference between Open Source and closed source is that often the Open Source project gets visible before it gets finished, therefore you see the projects that failed early on. OTOH closed source is usually not released before the developer considers it ready for use, therefore you'll never get to see most failed close source projects.
When adding, the processor set a bunch of flags, some of which (like carry) only make sense when interpreting as unsigned values, others (like sign or overflow) only make sense when interpreting as signed values. Therefore it is wrong to say that the processor only interprets the numbers as unsigned. Anyway, even if there's no difference, it is nonsense to single one of them out and claim that the processor uses that. If both are indistinguishable, then the processor obviously doesn't distinguish between them.
But then, addition/subtraction is special in that regard. You already mentioned one example, arithmetic shift. Other examples are multiplication and division instructions. And yes, of course they are separate instructions, just as in signed magnitude implementations you need separate instructions for signed and unsigned addition, because they simply have separate results. But that there are instructions for both means that the processor does not single one out as the "correct" one. A processor which had only instructions (and flags) for one of the interpretations could be said to do that.
(BTW, it's two's complement, not two's compliment; it's not about telling people nice things about them).
No, the most natural assignment is to not assign anything at all, but to take the bit pattern as what it is: A bit pattern.
Until someone breaks into the system and deliberately spills your coffee.
Oops, "Thus you cannot imply from the existence of an element 0, that there is an element 0." is of course nonsense. It should read "Thus you cannot imply from the existence of an element 0, that the first element is element 0."
From the processor's view (which has arithmetic operations, and therefore a natural interpretation of binary patterns as numbers), there is indeed an address 0. I never denied that. But that does not imply that the memory is naturally(!) a zero-based array. First, the (-128)-based array of 256 elements has also an element with index 0. Thus you cannot imply from the existence of an element 0, that there is an element 0. Second, as I already explained several times, there may (and in general will) be holes in the range of existing memory, making the 0-based array model of memory not an exact fit.
To avoid holes in memory you then tried to turn to single memory bars, which are not only completely irrelevant as far as the programming model goes, but at which level the address is no longer naturally a number. You can somewhat recover a numeric value if you look at the physical design of a memory chip, except that it consists of a two-dimensional array of memory cells, so the address from that view is not one number, but two. And if you look at the complete memory bar, then some of the address lines will be used for chip selection, so you'll get three numbers. That is, even then at the chip level you don't really have an address 0, but at best an address (0,0,0) (and that's assuming that the bits are addressing the lines/columns/chips in order, which may not actually be true).
Yes. But (and I put it in bold because copy repeatedly ignored that fact, despite me repeatedly telling you): At that point I was no longer speaking about the reset vector. Maybe you get back to my original post and actually read it. Here's a hint for you: Context matters.
Logical != natural.
Only if you interpret them as binary numbers. Which in the memory hardware isn't natural. Rather, each bit by itself gives a two-way selection of different subsets of memory cells.
Anfd here you're even wrong as far as the processor goes (well, assuming a full value, of course). An all-1 can as well be interpreted as -1. The processor has instructions for both interpretations.
Are you intentionally misinterpreting what I wrote? This address is the temporally very first address the processor reads, and therefore the processor assumes that there's something to read starting at that address because otherwise it could not work. And due to the way the hardware wrks, this means that all of F0000 to FFFFF is available. Which, due to 20 bit addressing and wrap-around is directly followed by the address 0.
Sorry, but that address I was speaking about at that point (first address of BIOS ROM in the original IBM PC) is definitely not represented by FFFF:0000. Anyway, the address represented by FFFF:0000 can as well be represented as F000:FFF0. Or as FF00:0F00. Or as FF80:07F0. Or as F123:EDC0. Or ...
Anyway, this segmentation is a speciality of the 8086; it is in no way natural, but was done mostly to provide the possibility of automatic code translation from the earlier 8080.
In the original PC, this happened at the hardware level. For the CPU, there was no difference between normal RAM and video RAM. I don't know how it is in more modern computers, but I guess it gets still mapped at hardware level for efficiency reason.
But anyway, even if you don't consider video memory, the point remains that if you consider the memory as starting at 0, there was generally a gap between the last RAM address and the first ROM address.
The processor doesn't address a stick of RAM (you don't have instructions to read cell X from stick Y). The fact that your memory is organized in sticks is just as irrelevant for the programming model as the fact that it is made of semiconductors, and that the electrons are ultimately described by quantum mechanics. Anyway, even on that lever, you're wrong.
If you go to a single stick of RAM, you'll find that for any address there is a corresponding memory cell. Which one is the first is therefore simply a question of declaration, not a question of naturalness. Indeed, if you look at early memory chips without all the modern optimizations, you'll see that if you exchange two address lines on the chip it won't really matter, because while it will read a different physical memory cell, it will do so consistently. Which demonstrates that at this level the address isn't even a number, but just a bit pattern.
If the plane was shot down and that fact was covered up (that theory is IMHO much more credible than the theory that the plane didn't exist at all), then of course you'd not find a single impact site (because the plane exploded in the air), The debris would then probably be distributed over a wide area, so that very little would be at any place. Moreover they would probably have been eager to remove any evidence of the shooting before presenting the place to the public, further reducing the debris.
Unlike arrays, memory may have arbitrary holes. For example, most 8086 PCs had a hole between the end of RAM and the beginning of ROM. Moreover, each address may or may not correspond to a memory cell; it's purely the hardware which decides which addresses correspond to available memory cells.
Anyway, address 0 is no special in this regard, unless there's something in the processor which expects memory there; but that's true for any address where the processor expects something. For example, the 8086 expects to be able to read instructions starting at address FFFF0 (note that 8086 physical addresses had 20 bits). Therefore if you interpret addresses as signed values, you could say that the natural base of 8086 memory is -16. Of course the 8086 also expects the address 00000 to be available, because it puts the interrupt table there. Moreover, in the original IBM PC, you were guaranteed to have ROM starting from F0000 through FFFFF is available as ROM and from 00000 to 7FFFF is available as RAM; memory above that may or may not exist. Note that this is a continuous area if you consider address wrap-around. Therefore you could also say the original IBM PC had a natural base of -65536.
Of course that neglects the video memory mapped in a region which may or may not be adjacent to existing RAM and/or ROM memory addresses. So the total memory is in general not even contiguous. And even if it is, the address 0 is not special in any case.
Moreover, if you don't look at the real memory, but at the virtual memory in modern CPUs/operating systems, you'll find that address 0 (more exactly, the memory page 0; on x86 that's the address range from 0 to FFF) is typically not mapped (so that null pointer dereferences are caught by the hardware). Therefore you might also claim that virtual memory is a 4096-based array, because that's the first virtual address which actually corresponds to existing memory. Which of course assumes that virtual memory is assigned as a single block; this assumption may well be violated if your program uses shared memory and/or memory-mapped files.
To summarize: There's nothing special to the memory address 0 which would make it the natural "begin" of memory, and there's no guarantee that memory is contiguous (which arrays per definition are), and this applies both to physical and to virtual memory. Therefore (a) the interpretation of memory as an array is not a perfect match, and (b) even if you do so, there's absolutely no reason to assume it is 0-based.
A patent covers not the charging for a technology, it covers the use of the technology. Any use, including offering it for free.
More exactly, Google applied for that patent and asked for that application to be kept secret, and then promoted that method as a way to give cheap broadband to rural areas without revealing that they had applied for a patent for this.
I couldn't care less about the fact that they might also make money by using that method on festivals. But promoting a technology, especially as solution for the poor, without revealing that you applied for a patent on that very technology is dishonest.
Well, they clearly heard the sound of one hand clapping. ;-)
Given that the attackers planned to crash into the white house, I can imagine that at that time, they were no longer that high.
I don't see any plausibility for the claim that the airplane didn't exist in the first place. After all, the planes crashing into the WTC definitely existed. Even if you believe in a government conspiracy crashing those planes into the WTC, then it should not have been a problem for them to get another plane crashing into the floor. And given that they could get it, not getting it would have been incredibly stupid.
So no matter whether you believe in a government conspiracy or not, assuming that plane didn't exist does not make sense.
I guess the family members didn't ask "how are you able to call me" and didn't really think about the question. For them it was a no-brainer that if their relatives called them it was by cell phone. That this would have been a problem on the plane probably didn't occur to them.
I guess you'd also have to implant an oxygen tank if you want that dynamite to explode inside your body.
Does anyone really teach such nonsense? (To avoid misunderstandings: The "0 as modifier" is the nonsense.)
Do you know what "idiomatic" means?
There's also a third kind:
42) Those who start their array at whatever index is convenient for their problem at hand.
If all you want to do is to test for equal/not equal, you don't need a subtraction. You can just do a bitwise comparison.
Of course the way you'd do it in hardware is to xor the corresponding bits and test the result against zero, so at the fundamental level you're right. But the circuit is so simple that I'd expect it to still finish in one cycle, so a processor implementing that would not necessarily be slower in comparing a value to zero than in comparing two values to each other.
However usually the processor, when doing arithmetic, already does certain tests anyway, and one of those tests you get "for free" is the test for zero. So in many cases (especially in the case of loops), the test for zero needs zero additional instructions; it's part of the loop arithmetic anyway.
Mathematically, it does: The set-theoretic definition of the natural numbers (and more generally, the ordinals, which also include infinite numbers) is that every number is the set of all preceding numbers. So the number three is the set containing exactly the numbers zero, one and two.
So he enumerates the elements of the number of stones ("zero, one, two") and then tells the name of that number ("three").
The abstract concept of a type and the implementation details of that type are not the same thing, although they are both important for a programmer to know.
Agreed.
But obviously not understood:
Languages that have a richer abstract model for arrays, rather than having arrays be merely syntaxic sugar for pointer arithmetic, also allow far more static analysis, allowing opportunities for the elimination, optimization or parallelization of processing that a C compiler would struggle to identify.
That tries to argue the point by suggesting that a richer language and more abstract models hides the implementation details. It hides the implementation detail that its still zero based.
No. The array is completely a language-level concept. At the machine-level, there are no arrays, neither zero-based ones, nor otherwise. You just have memory addresses and arithmetic operations. Zero-based arrays enable a particularly simple mapping between both (but not as simple as you seem to imply, because for almost all arrays, you'll have to do a multiplication with the array element size, which probably costs much more performance than the addition of 1).
Things are still zero based. You can jump through some hoops to try and hide this from the programmer if you want, but that's all you are doing, and if the programmer ever has to dig into the real guts of what's going on he or she is faced with the cold reality that everything is zero based behind the scenes.
No. It is trivial to code an 1-based array (or a 42-based array) in assembly: Instead of the true address of your array, use a value that differs by the element size (or 42 times the element size) to denote your array. You may need to rely on overflow-wrapping to do this, but that's OK, because overflow-wrapping is well-defined in assembly. Note again that the array is not in the computer (in case of assembly, it is not even really in the assembly code), but only in your interpretation of what the code does. The code itself does nothing but arithmetic and indirect memory accesses.
And its not just arrays. Its strings. Its the virtual pointer table internal to a c++ class object instance. If they dig all the way down to assembly language its the stack, its the member offsets of class/object members. Anything and everything that uses offsets.
You just proved that you don't have understand C++'s object model. What the virtual table contains is function pointers pointing to member functions of the object (those are ordinary addresses, not offsets). It may in addition contain an offset of the object as base object in a derived object (that's not the only possible implementation, but probably the most common; if it's a complete object, those offsets are of course all zero). But it never contains offsets of members (well, strictly speaking you can put whatever you want into a virtual table because it is not specified by the standard, but putting member offsets there would just be a waste of resources).
If we want to mostly hide that for programmer convenience in high level languages that's fine. But lets not pretend its some "artifact of C". Its how computers really work. And a good programmer should know that, even they use a higher level language where they don't have to think about it most of the time.
Since the computer doesn't know arrays at the fundamental level, every property of an array (including its existence) is an artefact of the language.
Where you would otherwise have stored x?
Anyway, the reasonable choice it to let the user choose the lower index according to his needs. Because if the index numbers you get are 1-based, all your 0-based arrays do is to move the subtraction of 1 from being created by the compiler to being explicitly written by the programmer. Which doesn't make the code the slightest bit more efficient.
There are many cases where 0-based indexing is just the right choice, but there are also cases where 1-based indexing is more natural, and there are even cases where you'd start somewhere else (because your numbers happen to start at that value).
Also, making all arrays 0-based is a premature optimization, which is the root of all evil.
Add 0 to the well-ordered set and change the algorithm so you start taking out elements from the sorted set. This way you naturally include the empty set and you tag the algorithm (retiring the zero means "hey, I start counting)
That's a very unnatural way of including zero. Versus the natural way outlined in the last paragraph of the parent.
By the license explicitly disallowing to disassemble the machine code.