This post is also a list of reasons why everyone thinking seriously about becoming computer scientists should start nowhere else than with C
Everything I wish I knew when learning C
241–250 of 401 posts
Re: Everything I wish I knew when learning C
#242I was born in '74 so the last generation to start with C and go to other, higher-level, languages like Python or JavaScript. Going in this direction was natural. I was amazed by all the magic the higher-level languages offered. Going the other direction is a bit more difficult apparently. "What do you mean it does not do that?". Interesting perspective indeed!
I started coding with C and OCaml in 2019. Everything in between these two was so unnatural. With JavaScript as the worst of all
Re: Everything I wish I knew when learning C
#243I've been programming in C forever, one advantage is that the language has not evolved much (especially compared with C++), but it has evolved. There was the big K&R C to ANSI C function declaration transition. For portable code, you used K&R C well into the 90s (because older machines only had the K&R compiler), or used ugly macros to automatically convert from ANSI to K&R. Another was the addition of 'const' to the…
> stdint.h / inttypes.h
Including inttypes also includes stdint.
You use stdint where you need the types only, like a header or non-IO module, and use inttypes where you need the print formatting.
I agree it's a bit weird but that's the way I understand the intended usage.
Re: Everything I wish I knew when learning C
#244Earlier quoted context omitted.
Hmm speaking of nostalgia, are there hobby z80 boards? Perhaps with enough peripherals to run cp/m? I do mean real z80s not emulators.
The Retrobrew community has designed a few of them, even as SBCs[0]. There's definitely more elsewhere. 0. https://www.retrobrewcomputers.org/doku.php?id=boards:sbc:st...
Ah thanks but that's beyond my skills/enthusiasm. I'd rather pay for a ready made board.
Re: Everything I wish I knew when learning C
#245> C has no environment which smooths out platform or OS differences Not true - C has little environment, not no environment. For example, fopen("/path/file.txt", "r") is the same on Linux and Windows. For example, uint32_t is guaranteed to be 32 bits wide, unlike plain int. > Each source file is compiled to a .o object file Is this a convention that compilers follow, or are intermediate object files required by the C…
On Windows you can directly access UNC paths (without mounting) with fopen. You can't do this on POSIX platforms. Also, not all API boundaries are fixed width so you're going to be exposed to the ugliness of variable width types.
I think the article is correct that one must be aware of the platform and the OS when writing C code.
Re: Everything I wish I knew when learning C
#246I like it, but the array details are a little bit off. An actual array does have a known size, that's why when given a real array `sizeof` can give the size of the array itself rather than the size of a pointer. There's no particular reason why C doesn't allow you to assign one array to another of the same length, it's largely just an arbitrary restriction. As you noted, it already has to be able to do this when assi…
I really wish that int arr[5] adopted the semantics of struct { int arr[5]; } -- that is, you can copy it, and you can pass it through a function without it decaying to a pointer. Right now in C:
typedef uint32_t t1[5];
typedef struct { uint32_t arr[5]; } t2;
void test(t1 a, t2 b) {
t1 c;
t2 d;
printf("%d %d %d %d\n", sizeof(a), sizeof(b), sizeof(c), sizeof(d));
}
Re: Everything I wish I knew when learning C
#247Earlier quoted context omitted.
I agree with the factual things that you said (e.g. "entire program execution was meaningless"). Some stuff was hyperbolic ("time-travel back to the start of the universe, delete it"). > [compilers] will make transformations to the program whose effects could manifest before the UB-having code executes [...] It's monumentally rude to us poor programmers who have bugs in our programs. The first statement is factually…
> Integer division is a slow operation, and under the rules of C, it has no side effects. Then C isn't following this rule - crashing is a pretty major side effect.
To my downvoters, since I can no longer edit: I've been corrected that the rule is integer division has no side effects except for dividing by zero. This was not the rule my parent poster stated.
Re: Everything I wish I knew when learning C
#248This looks decent, but I'm (highly) opposed to recommending `strncpy()` as a fix for `strcpy()` lacking bounds-checking. That's not what it's for, it's weird and should be considered as obosolete as `gets()` in my opinion. If available, it's much better to do the `snprintf()` way as I mentioned in a comment last week, i.e. replace `strcpy(dest, src)` with `snprintf(dst, sizeof dst, "%s", src)` and always remember tha…
Would it be a sin to use memcpy() and leave things like input validation to a separate function? I'm nervous any time somebody takes a function with purpose X and uses it for purpose Y.
Uh, isn't using `memcpy()` to copy strings doing exactly that?
The problem is that `memcpy()` doesn't know about (of course) string terminators, so you have to do a separate call to `strlen()` to figure out the length, thus visiting every character twice which of course makes no sense at all (spoken like a C programmer I guess ... since I am one).
If you already know the length due to other means, then of course it's fine to use `memcpy()` as long as you remember to include the terminator. :)
Re: Everything I wish I knew when learning C
#249I was born in '74 so the last generation to start with C and go to other, higher-level, languages like Python or JavaScript. Going in this direction was natural. I was amazed by all the magic the higher-level languages offered. Going the other direction is a bit more difficult apparently. "What do you mean it does not do that?". Interesting perspective indeed!
Im a decade younger and my university taught C for its intro to programing class.
Granted it was a disaster of a programing class.
Re: Everything I wish I knew when learning C
#250I like it, but the array details are a little bit off. An actual array does have a known size, that's why when given a real array `sizeof` can give the size of the array itself rather than the size of a pointer. There's no particular reason why C doesn't allow you to assign one array to another of the same length, it's largely just an arbitrary restriction. As you noted, it already has to be able to do this when assi…
> There's no particular reason why C doesn't allow you to assign one array to another of the same length, it's largely just an arbitrary restriction. IIRC C has an informal guarantee that no primitive syntax will ever cause the CPU to do more than O(1) work at runtime. Assignment is always O(1), and therefore assignment is limited to scalars. If you need assignment that might do O(N) work, you need to call a stdlib f…
> IIRC C has an informal guarantee that no primitive syntax will ever cause the CPU to do more than O(1) work at runtime. Assignment is always O(1), and therefore assignment is limited to scalars.
this is absolutely and entirely wrong. You can assign a struct in C and the compiler will call memcpy when you do.