Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
I tried Hackerrank and the book "The C programming languace " by Dennis Ritchie.
If u have some programming exp read the book and do the exercises
If u are really new, try hackerrank but it sucks in my opin.
IDEs have solid dwbugging and building options if u feel motivated try doing these things from the terminal. leaening Makefiles paid off big time for me
Fast-Nop2698551dMake sure you understand integer promotion, pointer aliasing, and operator precedence (especially & and | being weaker than ==), all of which will otherwise haunt you later with really strange bugs.
aggelalex68050dBecause C is pretty featureless, people using it rely a lot on conventions. Follow the conventions recommended by your development environment, and C will become a piece of cake...
matt-jd37350dDon't be afraid of pointers, just master the pointer magic and life will be fun
Fast-Nop2698550dOh and compiler warnings are your friends because they save debugging time, so crank them up and make sure your code compiles without warnings. With GCC, I recommend:
-Wall -Wextra -Wlogical-op -Wshadow -Wstrict-prototypes -Werror
The last one treats all warnings as errors so that the compilation will fail if any warnings are present.
WildPotato20650dYou're pretty much in control of everything, that means ot easy to screw up.
Code blocks os an amazing IDE for C. I recommend it, it's easy to set up and the debugger is pretty good.
*DON'T IGNORE WARNINGS*
Be careful when dealing with null pointers. If you get a seg fault, chances are you tried to access a null pointer. Just run the debugger and it will stop on the problametic line.
You might want to implement a bunch of data structures to really get things going.
hjk101233349d@Fast-Nop never heard of pointer aliasing before. I do have a good grasp of memory though (did some x86 assembly). Found that rather important to understanding arrays, pointers, and structs.
From what I read about aliases it's two pointers that point to the same address and sometimes optimisation can mess up the order of things is that what you are trying to warn against?
Fast-Nop2698549d@hjk101 Yeah, if you manipulate the same memory through incompatible pointer types, the changes may not show up because the compiler can optimise that away. One classic is this attempt of "pointer type punning":
long int i;
float *fp = &i;
*fp = 0;
if (i == 0) puts("Yo");
You would excpect "Yo" to be printed, but it may not. In fact, reading i is accessing an uninitialised variable unless i is a global. Using memcpy is the best way here - the compiler will not generate a function call in this example and instead generate the code that would have been expected in the example code above.
On the other hand, this works because the pointer types are compatible:
unsigned int *up = &i;
*up = 0;
if (i == 0) puts("Yo");
Also, the pointer type char* is allowed to alias anything.
hjk101233349d@Fast-Nop yeah never did crazy stuff like that. I can imagine using void pointers and indeed char pointers to do some some magic. But yeah I can imagine that the generated assembly would use a different register and be done with it.
Does this issue also size with pointer/array arithmetic and referencing?
Fast-Nop2698549d@hjk101 Pointer arithmetics and array indexing (you can't do array arithmetics) always work based on the element size of their type, but that's independent from aliasing.
So if you have this pointer to a 4 byte type:
and increment it by one (in terms of elements):
Then the resulting assembly will add 4 because that's the element size.