Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

Iteration in C

Name: Anonymous 2010-06-14 3:53

Hi there /prog/.

I know Python, and I'm learning C. Both langs have for loops. Python's nicely iterates over a collection of unknown length. C's usually has you specify the length of the collection at compile time, but what if the length is unknown?

My best newbie guess: you terminate the collection with NULL, or you write an iteration function that returns some end-of-collection value when it's done.

Name: Anonymous 2010-06-14 4:14

If you try to iterate beyond the end on an array in C, you'll get an array out of bounds error and crash. So, yeah, you basically need to use a null termination or know your bounds.

Name: Anonymous 2010-06-14 4:17

array out of bounds error
No, you won't. You'll may end up grabbing random data from the memory, and either fill your buffer with all kinds of junk left over from other code, or you'll get an access violation/segmentation fault at the end of that allocation block (depends on how your OS manages memory, if it's something like DOS or certain embedded systems, the whole memory could end up being valid).

Name: Anonymous 2010-06-14 4:20

Depends on the data structure. Usually with unknown length you're iterating through a linked list, which terminates when the pointer to the next item is null.

Name: IHBT 2010-06-14 4:24

collection
Here's your problem.  C doesn't have "collections".  for consists of 3 fields, all of which are optional: an initialization clause, a control expression (evaluated before each execution of the body, and the for loop only executes until the expression is false), and an expression that is evaluated after each execution of the body (usually to increment or decrement a variable that is part of the control expression).  Then a statement (usually a block-statement) follows.

/* i is initialized to 0 */
for (int i = 0; i < 3; i++) {
    /* when i < 3 evaluates to false, execution will go to the next line following the for block */
    printf("%i", i);
    /* i++ is executed after each iteration*/
}


2/10

Name: Anonymous 2010-06-14 4:49

Your stupidity knows no bounds

Name: Anonymous 2010-06-14 4:49

Null termination is one option, another is to store the length as the first element of the array.

Name: Anonymous 2010-06-14 7:48

Ever heard of linked lists ?

Name: Anonymous 2010-06-14 8:38

>>7
I prefer to store it as the last element of the array, with the i!=arr[i] test.

Name: Anonymous 2010-06-14 9:43

>>1
Typical Python programmer

Name: Anonymous 2010-06-14 13:55

>>9
0/10

Name: Anonymous 2010-06-14 14:03

>>11
It's almost better than using the zeroth element--which is the worst of intelligible solutions. I'd be happier using arr[-1].

Name: Anonymous 2010-06-14 14:30

>arr[-1]
This sounds like TROLLGOL

Name: Anonymous 2010-06-14 14:43

>>13
Nope, our arrays start at 2.

Name: Anonymous 2010-06-14 14:47

>>13
You could do it in C if you wanted. Library support isn't there, but it's also not library-incompatible.

Name: Anonymous 2010-06-14 16:22

>>12
Any reason you don't?

int BUFFA[21];
BUFFA = BUFFA + 1;
BUFFA[-1] = 20;

Name: Anonymous 2010-06-14 16:28

>>16
EXPERT ARRAY USER

Name: Anonymous 2010-06-14 16:42

-1[BUFFA]

EXPERY ARRAYISM

Name: Anonymous 2010-06-14 17:51

>>18
BUFFA MY ANUS

Name: Anonymous 2010-06-14 18:15

>>18
EXPERT PRECEDENCE FAILURE

Name: Anonymous 2010-06-15 0:03

>>1,4,7,9,12
Or you store the length separately you goddamn fucking retards.

struct Foo {
  struct Bar* bars;
  int bars_count;
};

Name: Anonymous 2010-06-15 0:09

>>21
Enjoy your unnecessary verbosity.

Name: Anonymous 2010-06-15 0:20

>>16
There are a few reasons. The big one is that free(buf) will not go over well. Another is that it wants a lot of casting in practice.

All trumped by the fact that it's never necessary. I don't use any languages that depend on a worse solution.

Name: Anonymous 2010-06-15 0:29

>>23
free(buff - 1) works just fine. If you're worried you won't remember, #define FREE(x) free(x - 1).

Name: Anonymous 2010-06-15 0:40

>>24
like this?
#define MALLOC_ARRAY(t, s) ((t)malloc(sizeof(t) * (s + 1)) - 1)
#define FREE_ARRAY(p) free((p) - 1)

...
int *int_array = MALLOC_ARRAY(int, 10);
...
FREE_ARRAY(int_array);

Name: Anonymous 2010-06-15 0:41

>>24
Well no... least of all that's not aligned. More importantly: most of my buffers are longer than 256 elements.

Name: Anonymous 2010-06-15 0:44

>>26
Why are you in a C thread if you don't know the first thing about C?

Name: Anonymous 2010-06-15 0:47

>>25
Ugh, nice try but you're still just as bad as >>24 in the end.

Name: Anonymous 2010-06-15 0:48

>>27
Hey, try using that code before you say something like that.

Name: Anonymous 2010-06-15 0:57

>>29
Why don't you try it, since you're the one who doesn't understand the language.

Name: Anonymous 2010-06-15 0:57

>>26
it's aligned just as much as if you do int *array = malloc(sizeof(int) * 10)... and it works just fine with more than 256 elements.

Name: Anonymous 2010-06-15 0:59

>>30-31
Did you try it with char?

Name: Anonymous 2010-06-15 1:14

>>32
Who gives a shit about char? We weren't talking about that.

Name: Anonymous 2010-06-15 1:15

>>32
why would i do something stupid like that? if you're working with text, you should be using wchar_t.

Name: Anonymous 2010-06-15 1:22

>>34
IHBT

Name: Anonymous 2010-06-15 1:23

>>33-34
pantsu

Name: Anonymous 2010-06-15 1:36

>>36
Back to the imageboards, please.

Name: Anonymous 2010-06-15 1:56

>>37
You must be new here.

Name: Anonymous 2010-06-15 2:10

>>38
For knowing proper use of sage doesn't require ``counter-bumping''? Fuck off.

Name: Anonymous 2010-06-15 2:11

>>39
[mail]sage[/mail]

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List