1. 13

  2. 16

    This is another case where I feel a low-quality downvote option would be highly useful. There are plenty of inaccuracies in these slides and I would very much not recommend this to someone learning C.

    1. 5

      Care to enumerate some examples?

      1. 20

        Slide 2:

        Don’t pick C as your first language.

        C is fine as a first language – I’m glad it was mine (I’ll grant this is at least somewhat subjective).

        Slide 3:

        You only need C for projects that require low-level hardware access or blazing-fast speeds.

        These are hardly the only valid reasons to write something in C.

        Slide 12:

        int my_var = 3; // It’s an int!

        my_var = “abc”; // COMPILER ERROR! You clearly stated that it was an int!

        A warning, possibly, but not an error.

        Slides 17-22: “memory layout”? I’m guessing this is referring to the necessity of avoiding invalid memory access, but “memory layout” means something very different to me (things like which members are where in a struct – which while a valid concern in some cases is definitely not something a beginner would need to care about).

        Slide 30:

        I like to think of a pointer as a directory and the value as a file.

        Not a very good analogy. File names & inodes would perhaps be marginally closer I guess, but still not a good one.

        Slide 31:

        int a[] = {1, 2, 3}; // create an array

        // a is just a pointer to the first element…

        Wrong, a is decidedly not a pointer; it’s an array. Yes, the expression a will decay to a pointer in some contexts, but it’s still fundamentally an array. They’re different.

        Slide 42:

        char letter = ‘a’;

        int x = (int) a; // look. it’s now an int

        Kind of a weird choice of example – I’m guessing the author is unaware that the expression 'a' is itself actually of type int, not char. The (int) cast in the second line is just as extraneous as the (char) cast omitted in the first line.

        Does it throw a warning because ints aren’t the same size as pointers? Yes.

        Maybe, if you’re on (say) an LP64 platform (but probably silent on ILP32).

        Does it make sense? No.

        It certainly could in some contexts.

        Slide 43:

        And that covers the all difficult C concepts for beginners

        Ignoring the spottiness of the topics it attempted to cover, that’s still pretty presumptuous. Just off the top of my head, what about, say, the distinction between stack and heap space? (i.e. why you don’t want to return a pointer to a local variable, which I imagine could easily be confusing to C neophytes.) I’m sure there are plenty of others as well.

        The whole thing smells very much like a case of someone kind of half-learning C and then deciding they’re qualified to start teaching other people about it.

        1. 9

          The idea that a[] is the same as *a is a misconception I see spreading around a lot. The C FAQ on Arrays and Pointers clears up some of the relationship between pointers and arrays.

          1. 1

            In regard to slides 17-22, this also puzzled me. I believe the author was wanting to impress how mindful you need to be with your data types, but that’s as far as I got. If this were a 6502 tutorial I’d probably have those slides as point #1, but…

        2. 1

          I feel like low-level languages have a simplicity that allows people to deceive themselves into thinking they understand them more than they do. I know how to write and read C, and I’ve used some of the tools, but I wouldn’t say that I “know C”. It’s actually pretty frustrating that so many C resources are from people who know little more than I do, but who’ve recently become enamored of low-level programming and think they understand it.

          There’s also an issue of feedback. Undefined behavior may or may not bite you. Often it doesn’t, or the failure is predictable (e.g. a hard crash for division by zero) which misleads a person into thinking that a pattern of behavior works. Most people don’t know that (under typical two’s complement assumptions) MIN_INT / -1 is undefined, for example, because they rarely get bitten by this corner case.

        3. 4

          I would like to point out that C++ is a completely different language. None of the things presented here (pointers, malloc, memory layout) need to be learned to learn C++.

          C++ really has a C-compatiblity-mode, but it’s not C. Death to the “C/C++” idea! They are two different languages!

          1. 3

            Are pointers confusing? -> vs . is the only instance I can think of that might be confusing until you read what those do.