/sci/ - Science & Math

[Anonymous No.6901112]

Programming in C. What the fuck am I looking at

[Anonymous No.6901128]

>mfw eventually have to learn to code
>mfw I'm so scared of even starting
>horrible experiences with matlab

[Anonymous No.6901129]

bad variable name conventions

[Anonymous No.6901133]

>Using pointers in conditionals
Is that even legal? Sorry, not a c guy.

[Anonymous No.6901142]

>>6901133
>legal?
The pointer is being dereferenced and compared to a literal number, so yes. It's bad style though.

[Anonymous No.6901143]

>>6901128
programming is fun anon

[Anonymous No.6901151]

>>6901128
Matlab is the devil. Don't worry anon, other programming languages are much better, but in my opinion, getting into the theory before diving into a language is more fun.

[Anonymous No.6901153]

>>6901112
Looks like a programming exercise by someone who's trying to figure out how basic features of the language work.

What the hell kind of a question is that? You got the code somewhere. You're looking at it for some reason.

[Anonymous No.6901160]

>>6901143
>>6901151
where the fuck am i supposed to even start? I honestly want to learn and coding sounds really interesting i just want to learn to do more than making a pop up window saying hello world

[Anonymous No.6901162]

>>6901112
>int b[2]
>*b
Good luck trying to compile that.

[Anonymous No.6901164]

>>6901160
http://www.johndcook.com/blog/2014/11/12/hello-world-is-the-hard-part/

[Anonymous No.6901170]

>>6901160
Write programs to do basic math stuff, like solve a quadratic equation with a sieve. Project euler is bretty gud

then move on to more advanced shit

[Anonymous No.6901204]

>>6901153
I'm trying to get a, b[0], b[1], i and j values after they go through the function, but I have no idea the order of the lines

[Anonymous No.6901210]

>>6901204
If you can't coherently express yourself to a human, you're going to find computers a lot less forgiving. They're not very clever at guessing what you mean.

[Anonymous No.6901216]

>>6901204
You read it from top to bottom. C is easy like that. You just need to know the difference between a declaration and a definition to get a good grip on the language.

[Anonymous No.6901232]

>>6901162
No luck required.
In C, arrays are pointers. Are you even trying?

[Anonymous No.6901241]

>>6901232
>arrays are pointers
>ARRAYS
>ARE
>POINTERS
Thank you for showing everyone you do not know a single thing about C. I dare you to try compile that. Don't forget to paste the inevitable error message here.

[Anonymous No.6901255]

>>6901241
#include "stdio.h"

int
main (int argc, char *argv[])
{
int b[2];
b[0] = 1;

int asdf = *b;

printf("%d\n",asdf);


return 0;
}

~$ gcc blah.c;./a.out
1

Have you ever C anon?

[Anonymous No.6901274]

>>6901241
>>6901255
Also, go ahead and compile it yourself. Maybe you learned something today.

[Anonymous No.6901275]

>>6901255
Aw fuck, I did mess it up. Forgot that b is syntactic sugar for &b[0], and *(&b[0]) is of course a legal statement.

My point still stands though. It's impossible to do b++ unless b is explicitely defined as a pointer, since pointers and arrays are not the same thing.

[Anonymous No.6901290]

>>6901275
Ok cool, I messed up too. I forgot that I never mess around with pointer arithmetic because it's usually a bad idea.

[Anonymous No.6901387]

>>6901275
>b is syntactic sugar for &b[0],
Really? I would have said b[0] is syntactic sugar for *b, and b[1] is syntactic sugar for *(b+1).

[fox No.6901691]

>>6901112
That #define needs extra parentheses around each argument in the expression to prevent order-of-precedence problems durung preprocessing

#define fnt(x1,x2,x3) ((x1) * (x2) + (x3))

[Anonymous No.6901702]

>>6901387
post your face when
>[1]b

[Anonymous No.6901711]

>>6901112
>a = 9.;
>b[2] = {2., 3.};
>i = 1;
>j = 2;

what don't you understand about this?

[Anonymous No.6901773]

>>6901702
huh?

[fox No.6901953]

>>6901773
in C, array[index] is equivalent to index[array]

[Anonymous No.6902054]

>>6901953
Example? Skeptical.

[Anonymous No.6902078]

>tfw failed programming class THRICE over the course of two and a half years
>mandatory subject for POWER ELECTRONICS engineer course

there is no hope

[Anonymous No.6902088]

Holy shit this is the worst code I've ever seen.

[Anonymous No.6902092]

>>6902054
Are you seriously too fucking dumb to figure out an example?

make an int b[2] and then print out 1[b]

[Anonymous No.6902107]

>>6901387
That's what it amounts to, yes. The address and dereference operators always cancel each other out, so *(&b[0]) is the same as b[0], and *(&b[0] + 1) the same as b[1].

>>6901702
>>6901953
The [] operator is exclusively a postfix operator. Putting an identifier after it and none before it isn't a valid expression.

[Anonymous No.6902116]

>>6902092
>>6902107
Addendum: according to the standard,
>A postfix expression followed by an expression in square brackets [] is a subscripted designation of an element of an array object. The definition of the subscript operator [] is that E1[E2] is identical to (*(E1+(E2))).

Interesting, didn't know that would actually work.

[Anonymous No.6902133]

>>6902092
not too dumb. it didn't compile and I was wondering if I needed a particular syntax

[Anonymous No.6902138]

>>6901133

char* strcopy(char* in, char* out)
while(out++ = in++)

is legal and working C, if I reproduced it correctly

[Anonymous No.6902139]

>>6901691
THIS!! Dear Lord the time wasted on this classic bug.

[Anonymous No.6902155]

>>6902138
Think you'd need
(*(out++)=*(in++))

[Anonymous No.6902204]

~$ cat wat.c
#include <stdio.h>

int main(void){
int a[2]={1,2};

printf("%d %d\n",a[0],1[a]);

return 0;
}
~$ gcc wat.c -o wat; ./wat
1 2


mfw

[Anonymous No.6902222]

>>6902155

Yeah that makes a lot more sense. Still lots of obscure C rules used to create something that works

[Anonymous No.6902246]

>>6902155
Why do idiots like you feel the need to comment on things you know absolutely nothing about?

You absolutely don't need extra parenthesis there.

[Anonymous No.6902247]

>>6902133
1[b] does compile though, unless your compiler is broken.

[Anonymous No.6902252]

Homework thread is homework.

[Anonymous No.6902635]

>>6902246
The point was you need the *

>>6902247
As what? b[1]? no.

[Anonymous No.6902643]

>>6902246
>You absolutely don't need extra parenthesis there.

The point was you need the *

[Anonymous No.6902660]

>everyone is a c expert
>everyone is a c++ expert
>toy examples always have errors
>can't even fizzbuzz

[Anonymous No.6902662]

>>6902204
Neato. It makes sense since 2[b] = *(2+b)=*(b+2)=b[2].

[Anonymous No.6902668]

>using anything else when C# exists

plebs everywhere

[Anonymous No.6902676]

>>6902668
>he still uses curly brace languages

[Anonymous No.6902678]

>>6902676
>le missing identation face.jpg

[Anonymous No.6902682]

>>6902676
>>6902668
>Being two proud random plebs

[Anonymous No.6902685]

>>6901275
>. It's impossible to do b++ unless b is explicitely defined as a pointer

C programmer here, thats wrong.

b has type int*.

b[] = {1,2,3} means you wrote 1,2 and 3 in the memory in a way that you can access its elements with *b, *(b+1) and *(b+2) or b[0], b[1], b[2] .

[Anonymous No.6902703]

>>6901204
>I'm trying to get a, b[0], b[1], i and j values after they go through the function, but I have no idea the order of the lines

a has type int so its printf("%i",a); for a
b[0] has type float so its printf("%f",b[0]); for b[0]
b[1] has type float so its printf("%f",b[1]); for b[1]
j has type int so its printf("%i",j); for j

All togehter its
printf("a: %i and b[0]: %f and b[1]: %f and j: %i",a,b[0],b[1],j);

[Anonymous No.6902719]

>>6901112
The function needs to be above the main Method try compiling it like this:

cc -ansi -Wall -pedantic filename.c -o outputname

For debugging you compile it like that
cc -ansi -Wall -g -pedantic file.c -o outputname

I recommend nemiver for debugging, start it with
nemiver ./outputname

It will show you whats written on what adress and you can set points to stop your programm

[Anonymous No.6902724]

int i = 5;

printf("%&",&&i);

mfw

[Anonymous No.6903537]

>>6902054
even better: 3["word"] == 'd'

[Anonymous No.6903550]

>>6902252
it's turning into a stupid C tricks thread

(seriously, go look up the entries to the annual Obfuscated C Contest and blow your fucking mind)

[Anonymous No.6903582]

>>6902685
Person you replied to here, b is of type int [], not type int *. The confusion stems from being able to access the memory addresses of either with both array subscripting and pointer arithmetic, but the types are completely different.

That's because int [] = {1, 2, 3} while int * = x → {1, 2, 3}, ergo it's possible to do b = b + 5 with pointer types, but not with array types. A subtle but important difference.

What doesn't help either is that function parameters, like y in void func (char y[]), are actually pointer types, since in this case char y[] is syntactic sugar for char *y.

[Anonymous No.6903830]

>>6903550
90% of C programming is stupid tricks, the language really isn't very good

[Anonymous No.6903833]

>>6903582
>Person you replied to here, b is of type int [], not type int *.
what's wrong with you

[Anonymous No.6903836]

Hi
>>6901275
I'm this guy:
>>6901255

I said I messed up too but I retract that and stick to my original statement that arrays are pointers. You're right that int[] and int* are different types but they're both pointers. What's a pointer? It's a data type whose value is the location in memory of something. This is true of both int* and int[]. Witness:

#include "stdio.h"

int main (int argc, char *argv[])
{
int b[2];
b[0] = 1;
b[1] = 2;

int *a = b;

printf("Muh pointer: %d\n",b); // don't do this part
printf("Muh array: %d\n",a); // in real code

// b++; // don't do it, anon!
a++;

printf("%d = %d, u mad?\n", a[0], b[1]);

return 0;
}

~$ gcc blah.c;./a.out
(( produces warnings, no errors ))
Muh pointer: 1645047664
Muh array: 1645047664
2 = 2, u mad?

[Anonymous No.6903847]

>>6903836
>You're right that int[] and int* are different types
citation needed

[Anonymous No.6903884]

>>6903847
Ok.

>>6903847
Ok

#include "stdio.h"
int main (int argc, char *argv[])
{
int b[] = {1, 2};
int *a = b;

a++;
b++; // don't do it, anon!

return 0;
}

~$ gcc blah.c
blah.c: In function ‘main’:
blah.c:11:7: error: lvalue required as increment operand
b++; // don't do it, anon!

[Anonymous No.6903955]

>>6903884
Agree. For multi-dimensional arrays, there is a more fundamental difference. Pic from Numerical Recipes in C.

[Anonymous No.6904251]

>global variables
>ever
Kill yourself.

[Anonymous No.6904255]

>>6904251
>int main

[Anonymous No.6904258]

>>6904255
Why doesn't main return anything in C? I've programmed in C, C++, and Java and it's always seemed weird to me that you're not allowed to return anything from main in C.

[Anonymous No.6904260]

>>6904258
>return 0;

[Anonymous No.6904297]

>>6904258
Main always returns something in C/C++. Microsoft may let you return void, but sane compilers require you to return an int, which gives state information about the process' termination that can be queried by other processes.

>>6903955
What's really fucking annoying is declaring a pointer to a row. I think it's float * (b[9]); or something. I have to hunt and peck every time I need it. The article fails to mention that they do it that way because it is often faster because it needs less memory accesses.

>>6901112
a is 21.0
b[0] is 0.0
b[1] is 20.0
i is 5.0

[Anonymous No.6904417]

>>6902155
while (*(out++)=*(in++)) is always true
while (*(out++)==*(in++))

[Anonymous No.6904421]

>>6904297
>sane compilers require you to return an int
On PC. Where are you going to return an int in an embedded system?

>>6904417
flat fucking busted

[Anonymous No.6904564]

>>6903550
>it's turning into a stupid C tricks thread

While we're on the subject:

int x = 10;

while( x --> 0)
{
printf("%d", x);
}

Don't hate.

[Anonymous No.6904566]

>>6904421
>On PC. Where are you going to return an int in an embedded system?

On all embedded systems I've worked on, you use the compiler/synthesizer the vendor has provided. It may have a special case for void main (many do), but that doesn't make it a standards-compliant compiler.

[Anonymous No.6904570]

>>6903836
>I retract that and stick to my original statement that arrays are pointers
That's a dumb thing to do, since you were correct before, and now you're not. But don't take it from me, take it from the official standard instead. Pic related, a bunch of excerpts that illustrate the point.

>What's a pointer? It's a data type whose value is the location in memory of something
Correct, and in case of an array, it doesn't store any memory location information about itself, it merely guarantees all of its data is sequentially ordered. Remember b is syntactic sugar for &b[0], the latter which generates a memory location through the address operator & which can be applied to any object type. So it's clearly not a pointer type.

>>6903833
I know my ANSI C, unlike you apparently.

[Anonymous No.6904774]

>>6904564
How is this a stupid trick? Looks pretty standard.

[Anonymous No.6904778]

>>6904417
>>>6902155
>while (*(out++)=*(in++)) is always true
>while (*(out++)==*(in++))
No, you want the first one, not the second. It's not always true, it's true until you get to the terminal 0 of the string. The second one won't copy anything.

[Anonymous No.6904790]

>>6904297
>>>6903955
>What's really fucking annoying is declaring a pointer to a row. I think it's float * (b[9]); or something. I have to hunt and peck every time I need it. The article fails to mention that they do it that way because it is often faster because it needs less memory accesses.

I agree with it being annoying. I tend to avoid it by doing what the article suggests, declaring int **a, then using calloc, etc to get a chunk of contiguous memory. You can always treat the data as a 1-d array then, doing the multiplication yourself.

a[0][i*9+j]==a[i][j]

or some such.