Want to get first element from an array

>want to get first element from an array
>array[0]
wtf i hate programming now

Attached: facebook_zuck.jpg (600x600, 40K)

It still gets me from time to time when going back and forth from C and MATLAB.

Truly the dumbest shit. Who came up with this? HURR ZERO IS THE FIRST NO IT IS NOT

It makes sense if you think of it as offset from the first element.

>int* p points to first number in array
>p + 1 points to second number in array
makes sense

>array index is 1
>ok fine makes logical sense
>grab first element with array[1], second with array[2]
>try to grab array[0] by accident or out of curiosity
>whole computer explodes injuring dozens and killing your dog

>want to get first element from an array
>[0]array
wtf I love C programming now

>xhe doesn't use a language that has `#first`
[":^)", 420, "blaze it faggot", "lmao"].first
=> ":^)"
[/code/]

it makes sense if you actually fucking know how arrays are implemented.

Just use matlab, it is better anyways.

>want to get first element from array
head array
wtf i love programming now

That's because it's the offset from the first element and not the actual index you imbecile.

A documentation doesn't change the fact that it's shit.

go use Lula then you brainlet

*array

I mean lua

It makes sense from a hardware perspective

Please dont do programming than. There are enough brainlet programmers.

Use n = -1 to fix that bug.

well I'm not programming hardware now am I?

Well user thing is you actually are, all the code is actually converted into machine code which the hardware runs

ur mum gey
It looks cool starting from 0, just saying. My autism digs programming.

>"than"
>calls others brainlets
Are you okay?

Attached: brainman.png (355x365, 100K)

>High level language
>Hardware perspective

>count up to 5
>1, 2, 3, 4, 5
>count down from 5
>5, 4, 3, 2, 1, ZERO

life is confusing

>not keeping array size in [0]
That 3 week bootcamp is really printing good devs I see

I hate how iterating from a value to zero with unsigned integer you can't use some simple condition, e.g.
>for (i=10; i >=0; i--)
and have to use other loop
>inb4 you shouldn't iterate decrementaly

Why can't you?

underflow and overflow of unsigned integers is defined and completely legal behavior
the condition is checked _before_ the body runs and decremented after the body finishes
thus when i gets decremented to 0 for last iteration (first element of array) and gets decremented it's now the highest value the integer size can hold, which is of however >= 0 thus it results in infinite loop
and using signed integer for indexing arrays is allegedly bad practice and you should be always using size_t (in C)

>not just terminating your arrays with \0
pleb

>abusing type system this much
debug yourself

reminds me of pascal strings

anyway, allocator in glibc stores sizes and even provides API to access it, so storing it by yourself is redundant

You could just use a modern language, OP.

(first array)

We use the decimal number. They go from 0 to 9 and combinations of it.
Is this thread bait? holy shit if not this is really dumb

>trusting glibc
Pleb.

>his country doesn't have ground floors

LMAO @ 3rd world peasants

Attached: smug future king.jpg (820x1200, 212K)

Ooooh.. well that is stupid.

Traditionally an array is just syntactic sugar for a pointer. Some language may implement it as a higher level data structure, but usually it's just a pointer. The index you give to an array is just an offset, it addresses p + i * s, where p is the pointer, i is the index and s is the number of bytes the data type you're storing occupies. 0 is the first index because it's stored at pointer p, since it's the first element in the array. It makes way more sense than arrays that start at 1 when you know what an array actually is.

it's more about how memory works than "starting to count from 0 or 1"
it's more efficient

An index being an offset is the most fundamental rule of programming.

Sooner or later you'll figure out why it is that way

>want to get first element from SQL database
>where id=0
>get nothing

Attached: shock, sudden clarity, realisation.gif (200x198, 427K)

huh?
(first (make-array 1))
=>error: #(nil) is not alist

See

Hmm, I don't get tripped up by this and I never thought of thinking of it like that but I will now. Thanks user.

array[x] == *(array + x)
at least in C

>just use Lula

Attached: 1523152816234.jpg (259x267, 119K)

Looks like a buffer overflow waiting to happen.

array.get(1);

arrays are not pointers

>not using 0[array]

Attached: 1511488663495.jpg (447x456, 32K)

Jow ForumsProgramming:
>LMAO ENJOY ADDING ONE ALL THE TIME xD LITERALLY UNUSABLE REPEAT AFTER ME ARRAYS INDEX FROM ZERO

>Let me get the last element in this zero-index language...

that's why you do static analysis of your code

>arrays are not pointers
lol at your life

>I dont know how binary works
you know that 0 is the first number right? makes sense to keep everything consistent

Just use ArrayList.first()

Amusingly enough x[array] is equivalent for that very reason.

*(array+x)==*(x+array)

>not using (decltype(array))0

Attached: 1514092348676.png (321x308, 87K)

wtf i love arrays now

Arrays store the size of all items, pointers store only its own value. That's literally the only difference.
Even then, if a function parameter is declared as an array the compiler just makes it a pointer.

Yeah, like on a number line you start at 0, and 1 is exactly 1 place from 0 which is the origin

Attached: 5-5_41633_lg.gif (1024x138, 7K)

No, it does

>yfw you realize that the name of a number is just it's distance away from zero
It's so obvious but I feel like such an idiot

Attached: 1391735138328.jpg (5000x5000, 2.85M)

R nigger spotted

Yes they are.

>needing arrays ever instead of just using a different key:value for everything

arrays are the work of jews and the cuckolding of programming languages. every variable should be paired with one and only one value, as that creates a kind of harmonic relationship that can lead to proper programming fullness. a line of variables associated to a single name is the same as a line of cocks under the control of a single woman, while (you) are the cuck watching it all

Attached: nepubun.jpg (2015x1501, 2.61M)

if bracket notation is just syntactic sugar for pointer artithmetic in C, why does it work for data structures that aren't the standard word size? is whatever[i] actually translated to *(whatever + i*sizeof(whatever)) instead of just *(whatever + i)?

/thread

inb4 BUT MUH LUA

R starts with 1 and not 0. You must be a Python fag. Here is your daily reminder that Python sucks dick when it comes to statistical analysis compared to R.

array[0] is perfectly logical you just do not understand what is happening. The number contained in the brackets is an offset. The first value it has an offset of 0, in other words you do not move at all because it is first.

Currently visiting India, every building has a ground floor here, compared to America where G = 1.
The absolute state of the union.

Pointer arithmetic works that way as well. You can't perform arithmetic on void pointers.

if you're in python you can do this:
class mylist(list):
def __getitem__(self, n):
return list.__getitem__(self, n-1)

>Enters a candidate for post quantum crypto
>Multiple academic peer review
>NIST review code for months

Spot the bug.

Attached: The State of Post Quantum Crypto.jpg (1200x640, 93K)

How about this?
const char foo[5] { 's', 'h', 'i', 't', '\0' };
const char* tard = &foo[-1];
// get first element for tard
std::cout

That inner for loop is gonna have a bad time.

I automatically assume that a language with 1-based indexing was designed for retards.

what's the problem?

first element is already extracted, so they start with 1. the compiler probably warns about bitwise operations, but it explicitly says that they want to extract the last bit (which is what they're doing)

>for (j=1;jfor (blah);
>;

loop counts up to 8, then exits, then executes the block underneath exactly once with j = 8.

/Additionally, this is why hoisting variables to the top is a shitty idea. If it was declared as
for (size_t j = 1; j < 8; j++); the compiler would error on j being undefined in the block underneath

bait

what lang?

I don't disagree that it's questionable practice (desu I didn't spot that) if they are consistent they'll reset it back to whatever when they use it in a loop again.

there are legit reasons to declare them outside, although this is probably not one.

however, how do you know it's misused in the block underneath?

honestly it's only annoying when trying to get last elements without negative indexes. doing array[array.length-1] would be slightly more tolerable if it were just array.length.

>a-arrays are pointers because my shtity language has array -> ptr decay.

clets please stop

some languages have negative indexing. (-1 is the last, -2 is the second to last)

>however, how do you know it's misused in the block underneath?

I didn't look at their use of j in the block underneath. I just recognized that their code was equivalent to :
for (i = 0; i < LENGTH_OF_HASH * 2; i++)
{
for (j = 1; j < 8; j++) // semicolon here shitted up their codeflow
{
}

seed[i]

>>however, how do you know it's misused in the block underneath?
>I didn't look at their use of j in the block underneath. I just recognized that their code was equivalent to :

oooh

haha

ok yeah

sorry I guess I failed completely. I didn't see that semicolon.

desu I wouldn't have cought that withouth the warning unless I went in with a debugger.

I guess that's why I'm only a 0.3X developer.

What's wrong with this?

std::string TestResult(bool passed) {
std::string message = "The test has" +
passed ? "Passed" : "Failed";
return message;
}

AFAIK neither g++7 nor clang++5 warn with -Wall -Wextra -Wpedantic

You're less likely to make fencepost errors.

DESU i have't touched c++ in 7 years now, but my guess is that it always shows passes because it probably evaluates (const string + whatever) ? a : b to (true) ? a : b to a , i.e. "Passed" at compile time.

this happens because ? has priority 15, while + has priority 3 or something.

other than that maybe it can't cast bool to string.

Yep, exactly.
"The test has" is a string literal, not a std::string.
String literals are "const char*" which do not have an operator+ overload for string concatenation.
binary + has higher precedence over the ternary operator
Pointers can decay really fast
Thus the code is equivalent to return "Passed"

Even if you wrapped parentheses around the ternary, you wouldn't get what you want. You'd need to do it on two lines or use printf or similar, since string literals don't have concatenation with plus. (you can do it compile time with "there is a space" " inbetween concatenates")

It's zero array elements in distance from the start of the array you absolute fucking mongoloid brainlet shitstain.

[ element ][ element ][ element ][ ...
^ ^ ^
0 x e 1 x e 2 x e, etc

you could use a lambda lol

what clang are you using? mine literally screams all the issues with this.

└─> clang++ t.cpp
t.cpp:5:42: warning: adding 'bool' to a string does not append to the string
[-Wstring-plus-int]
std::string message = "The test has" +
~~~~~~~~~~~~~~~^
t.cpp:5:42: note: use array indexing to silence this warning
std::string message = "The test has" +
^
& [
t.cpp:6:16: warning: operator '?:' has lower precedence than '+'; '+' will be evaluated
first [-Wparentheses]
passed ? "Passed" : "Failed";
~~~~~~ ^
t.cpp:6:16: note: place parentheses around the '+' expression to silence this warning
passed ? "Passed" : "Failed";
^
)
t.cpp:6:16: note: place parentheses around the '?:' expression to evaluate it first
passed ? "Passed" : "Failed";
^
( )
└─> clang++ --version
clang version 6.0.0 (tags/RELEASE_600/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

Just add parentheses around the ?:

So why does it use an offset?
I mean, we could add like
PositiveInteger(1)+PositiveInteger(1)=PositiveInteger(3)
... using offsets from the first positive integer, but unless there's a reason it should probably just be 2+2=4

programming was a mistake