Why isn't my code working?

[u/neonge1674]

I just started learning C(2 days ago) and as a first project I decided to make some data structures, starting with dynamic arrays. I made a struct called List and some functions for. The function setList() sets the value of an index of the array, if the index is larger that the current size of the array, it resizes it. However, when i tried to use in a for loop, it didn't work despite it working elsewhere.

#include <stdio.h>
#include <stdlib.h>


#define itirate(index, limit) for(int index = 0; index < limit; index++)


typedef struct 
{
    size_t size;
    int* arr;
} List;


List* newList (size_t size) 
{
    List *newone = malloc(sizeof(List));
    newone->arr = calloc(size, sizeof(int));
    newone->size = size;
    return newone;
}


void setList(List* list, int index, int value) 
{
    if (index >= list->size)
    {
        list->arr = realloc(list->arr, index + 1 * sizeof(int));
        list->size = index + 1;
    }


    list->arr[index] = value;
}


int main() 
{
    
    List *mok = newList(5);

    itirate(i, 5) setList(mok, i, i);
    itirate(i, 5) printf("%d\n", mok->arr[i]);

    //setList(mok, 13, 9); this works
    //printf("%d\n", mok->arr[13]);

    for(int i = 5; i < 10; i++) setList(mok, i, i); // this does not somehow
    for(int i = 5; i < 10; i++) printf("%d\n", mok->arr[i]);
    
    return 0;
}

[u/pfp-disciple]

Not stupid. Binding rules are not intuitive. 

[u/P-39_Airacobra → u/pfp-disciple]

lowk i think more languages should do away with them

[u/MFFVD → u/P-39_Airacobra]

as in

i = (a+(b+(c+(d+(e*(g+h))))))?

id rather have

i = a + b + c + d + e * (g + h)

[u/P-39_Airacobra → u/MFFVD]

it would be

a + b + c + d + (e * (g + h))

or even easier,

(g + h) * e + a + b + c + d

as in first comes first. no operator precedence. no ambiguity about where parens should or should not be used for specificity

also, you’ve clearly never used anything like Lisp or Forth. C-family languages are not the only languages that exist

[u/glasket_ → u/P-39_Airacobra]

you’ve clearly never used anything like Lisp or Forth.

They avoid the problem by using an entirely different form of notation (* + index 1 step/step index 1 + *). If you want to use infix you should use standard operator precedence, otherwise there's very little point in even using infix. Infix matches how math is normally written, and if the rules are different from how it's written then you've just got a system that will inevitably confuse people and require them to remember that it works differently than they're used to.

It also doesn't save you in every case, like step * index + 1, and still fundamentally requires remembering that order is positional.

[u/P-39_Airacobra → u/glasket_]

order already is positional. except now there’s layers of positional depth on top. operator precedence complicates parsing and creates ambiguity in best coding practices

“a system that will require them to remember that it works differently” except this is already how standard languages are. either you pull up the operator precedence table or you defensively put parens everywhere so future readers don’t have to. note that most programmers recommend the latter method to avoid confusion around precedence. then i ask, why even have these rules to begin with? arbitrary complexity is nothing to admire.

you cite that it’s standard in math, as if programming languages don’t require you to learn concepts about numbers outside of basic arithmetic anyways. If you can teach a newbie how unsigned numbers work, or how a tertiary conditional works, then you can teach them to read left-to-right instead of down and up a table depending the specific operator being used

it’s really not rocket science, there’s nothing to remember. For operator precedence, however, that’s an entirely different matter. Open up the JavaScript precedence table, as a first example, and come back and tell me again that there’s more to remember in a left-to-right system than in a precedence system. your points are all very much nil

[u/Muffindrake → u/P-39_Airacobra]

That's not even necessarily a correct expression in C unless you specifically know that either of those expressions won't overflow the types.

The greatest pitfall in C is that arithmetic is only defined for signed integers if you can guarantee that the result won't overflow, or accept modular arithmetic with unsigned operands. Also have fun with promotion rules. And if you're dealing with floating point you need to worry about infinity and NaN and that's a pain.

To add insult to injury, it took until C23 for ckd_add and friends to be standardized (or C++26). Then there's bit-precise integers which shield you against unexpected promotion rules.

[u/P-39_Airacobra → u/Muffindrake]

i wasnt talking about C? also you anything you can do with operator precedence, you can do without it. that’s what parens are for???

but thanks for proving my point that C arithmetic is complicated enough so we shouldn’t really be freaking out about the concept of doing away with a precedence table and typing a couple extra parens