Quantcast
[ 3 / biz / cgl / ck / diy / fa / g / ic / jp / lit / sci / tg / vr ] [ index / top / reports / report a bug ] [ 4plebs / archived.moe / rbt ]

Maintenance is complete! We got more disk space.
Become a Patron!

/g/ - Technology


View post   

[ Toggle deleted replies ]
>> No.73099580

Pointer to memory plus zero increment.

>> No.73099690

>>73099546
Because
#include <iostream>
using namespace std;

int main()
{
int arr[]={0,1,2,3,4};
for(int i=0;i<5;i++)
{
cout<<i[arr]<<endl;
}
return 0;
}

>> No.73099707

>>73099546
Because array[0] == *(array + 0) == *array.
Learn C.

>> No.73099734

>>73099546
Because 0 is the first bumber in a byte you retard.

>> No.73099792

>>73099787
no idea greta was this stacked

>> No.73099833

>>73099546
say you only have 8 bits and an array with 256 elements. You can only represent 0-255 with 8 bits.

>> No.73099897
File: 70 KB, 620x349, miyazaki_smiling.jpg [View same] [iqdb] [saucenao] [google] [report]
73099897

>>73099546
Of course meduka poster has room temperature digit iq.

>> No.73100004
File: 140 KB, 450x399, 1554830443291.jpg [View same] [iqdb] [saucenao] [google] [report]
73100004

>>73099690
>using namespace std;

>> No.73100364

>>73099546
I love homu!!

>> No.73101787

>>73099546
It's so you don't have to write an edge case for accessing the first or last element in an array.
something like *(arr + idx) where idx = 0 will refer to to the first element of the array, and since ancient languages like C have no distinction between arrays and pointers, the pointer arr that isn't being incremented will always refer to the first element of the array.

>> No.73102728

They don't. Ada, Algol 58/60/68, Fortran, Pascal, PL/I, Eiffel, most forms of BASIC, and almost all other languages designed before Java can start at any number, including negative numbers. In Ada they can even be indexed by enum or character types. Forcing arrays to start at 0 is an arbitrary limitation of crippled languages.

>> No.73104051

It leads to less arithmetic in some cases.

Let's say you have a grid of 300 rows, 120 columns. For every cell you want to store one byte

With 0-based indexing you could access a given cell using

array[row * 120 + column]

e.g. row 0, column 0 becomes 0 * 120 + 0 = 0 which is first.

with 1-based indexing it would be

array[(row-1) * 120 + column]

e.g. row 1, column 1 becomes (1-1) * 120 + 1 = 1 which is first.

>> No.73104140

>>73104051
Oh and another thing. It means that all unsigned values are valid indices (assuming the array is big enough).

This is helpful for example for lookup tables. If you have some lookup table from bytes to bytes you can just do

byte_out = lookup[byte_in]

instead of

byte_out = lookup[1+(int)byte_in]

>> No.73104173
File: 424 KB, 1054x1053, wire-16644664-1564426228-394.jpg [View same] [iqdb] [saucenao] [google] [report]
73104173

>>73099792
>>73103375
Greta is flat as a board, and that's a good thing.

>> No.73104182
File: 216 KB, 480x389, 1570075654072.png [View same] [iqdb] [saucenao] [google] [report]
73104182

>>73099546
>array did not begin at NULL

>> No.73104221

>>73103375
The age of consent in europe is 14 in many countries FYI

>> No.73104285 [DELETED] 

>>73104173
why does her head look like a baseball

>> No.73104441

>>73104235
1-based indexing makes common operations (like computing the index of an entry in a multidimensional array, ie x+y*width) much more complicated, it decouples arrays from their underlying representation as pointers (ie a[x] == *(a+x)), it wastes an unsigned integer which no longer corresponds to anything valid (in 0-index, a[0] through a[255] are all meaningful, in 1 indexed a[0] is meaningless and you need a larger integer type to get the 256th value), it's inconsistent with negative numbers and offsets (is -1 one before the start or two?), and probably many more reasons I'm not thinking of right now.

1-indexing is terrible and preferring it generally means you have more experience counting beans than programming.

>> No.73104500

>>73104477
if you seriously think this you've never worked with large data sets, or more importantly do not know either C or Fortran

>> No.73104514

>>73099787
the glasses can't hide the butterface but them titties tho

>> No.73104654

>>73104571
What your are describing is called "unnecessary overhead". You can build an equivalently powerful abstraction in any language, regardless of the style of array indexing, but you can't "take away" the overhead that comes with 1-based indexing.

That is to say, you can easily build a "slice" array reference type in C that has stride and multidimensional bounds. But you cannot address a 256-element lookup table with an 8-bit number without abusing wraparound or introducing a new abstraction in a 1-indexed language. At some point, the computer needs to read a memory address, and at that point you'll need to unify the representation of plain integers, pointers, and array indexing types. In a 0-indexed language, that's a no-op, in a 1-indexed language it isn't.

>> No.73104794

>>73104754
addressing a array that goes all the way up to the bounds of the integer type of its index is an extremely niche use case in 2019. 0-based indexing made sense decades ago, it doesn't make sense today, that's the point

>> No.73104811

>>73104754
Oh yeah and you don't need to compute the offset obviously, it can be done at compile time in any statically typed language

>> No.73104844

>>73104794
That's hardly an argument.

By the way, I'm speaking to you as someone who has six years of professional programming experience, four in C++ and two in Java, and who regularly programs microcontrollers for my personal projects, and has been doing so for around eleven years. This isn't to say that "I'm right because I'm a professional" but rather that I think I have a pretty damn good idea of the most common cases where the difference between 1-indexing and 0-indexing matters. And that's: occasionally in my four years of C++ systems programming, never that I can remember in my two years of Java backend web dev, and all the fucking time in my microcontroller programming.

>> No.73104848

>>73099546
You can just use 1 item longer arrays and skip the first item.

>> No.73104907
File: 15 KB, 250x250, 1562385526952.jpg [View same] [iqdb] [saucenao] [google] [report]
73104907

>>73099546
Really? You're wondering why counting starts at 0? What about the fucking upside down trees?

>> No.73104936

>>73104868
I'd absolutely hate to work on a microcontroller in a language where arrays are 1-based and pointers are 0-based. That's a recipe for bugs. What kind of programming have you been doing for fifteen years? I'll be absolutely stunned if you say embedded (and honestly will probably not believe you), I'll be a bit surprised if you say systems programming, and I'll laugh if you say web dev.

I'm imagining a task I worked on just this week, defining an SPI protocol between a tiny PIC and a beefy Arduino Due, if I had used 1-based indexing on the wire when nearly every value I send was an index. It'd be a huge overhead, and I can think of many situations (such as 256-element lookup tables, which I've mentioned a few times now) where it really matters for embedded. Also consider even in high level languages like Python, the use of negative indexes, which I alluded to in >>73104441.

>> No.73105024

>>73104990
>subtraction
This operation is not available, including Fortran 2018.

>> No.73105087

>>73104981
In Python, negative indexes "wrap around", so a[-1] is the last element, a[-2] is the second to last, etc. This works very well with iteration, as you can start at -2 and go to 2 to get the last two and first two elements of an array as if it was a circular buffer.

>>73104997
I guess my final word here is: the maximum difference will always be the presence or absence of adding or subtracting 1 in terms of converting between styles in a high level language, but while 0-indexing maps cleanly to the underlying machine concepts and can efficiently handle things like indexing a 256-element lookup table with a single byte (generally speaking it matters because you are dealing with a whole array of bytes or a stream of some sort the you're mapping), 1-indexing has unavoidable overhead, no matter how minor, in these situations. Additionally, I think the mental overhead of each system is about the same, and if anything 0-indexing has a simpler mental model once you're familiar with it, which generalizes cleanly to things like negative indexing, used in high level languages like Python.

>> No.73105111

>>73099546
It's purely a matter of convention. Programmers are superstitions as hell, so there is a lot of things which get done which are arbitrary or serve little purpose, but have widely-shared rationalisations.

>> No.73105120

>>73105087
(Another recent example I can think of that works very well with 0-indexing and would be much uglier with 1-indexing is the COBS algorithm, which I again used recently in a microcontroller project)

>> No.73105154

>>73105087
Hadn't considered the point about negative indexing, I don't use Python, it's a probably the most convincing argument I've heard so far but I don't think it outweighs the fact that we start counting at 1

>0-indexing maps cleanly to the underlying machine concepts
That's only assuming the underlying data starts at 0, most languages have a length field which comes before the data. The cost of a single offset ranges from non-existent to trivial, I'm guessing it's non-existent most of the time

>indexing a 256-element lookup table with a single byte
you keep bringing this up but it's such a tiny, niche case. Expand your horizons

>Additionally, I think the mental overhead of each system is about the same
This isn't about mental overhead. I'd have trouble using 1-based indexing if it was standard because I'm so used to 0-based indexing, I'm only arguing that it's the objectively better option for standard indexing of arrays

>> No.73105553

>>73099546
It's how the underlying memory works.
If they started ad 1, early computers would have needed to subtract 1 from every array access.
Modern computers don't care and usually have a variant of mov that will just take the value one address earlier.

>> No.73106220

Rather than thinking about it as a list, think about moving along a block of memory. You start with zero distance moved, the next item is at 1 times the size of each item, etcetera.

>> No.73107446

>>73104979
>and it seems like you could do the same thing for any 0-based language.
Except you can't. Your argument is that non-0-based arrays need extra arithmetic, but it doesn't. If you have a 0-based language like C or Java, you will need extra arithmetic to fake 1-based or N-based arrays on top.

>>73104990
That's undefined behavior in C because the pointer value would be outside the array. If you mean Java, that's not even possible. It is well-defined in languages that have this capability.

>>73105553
There is no difference in speed and no extra subtraction. This was widely taught when Pascal was still popular. Languages like C and Java turned well known parts of computer science into lost art.
https://cs.nyu.edu/web/Academic/Graduate/exams/sample/jan94core.pdf

>>73105676
>>73106220
Array offsets are signed numbers in languages that aren't 0-based.

>> No.73109256

>>73099580
>>73099690
>>73099707
>>73099734
>>73099746
>>73099768
>>73104441
>>73104809
>>73105553
Wrong.
>>73099765
Correct and based.
>>73105111
Also correct.

>> No.73109999

>>73109753
I was making a point. Starting at 1 is just as arbitrary as starting at 0.

>>
Name (leave empty)
Comment (leave empty)
Name
E-mail
Subject
Comment
Password [?]Password used for file deletion.
reCAPTCHA
Action