C for high level programmers (slides)

Post by 14113 » Mon, Jun 01, 2015, 1:37 AM UTC

TheAceOfHearts wrote: post #29

qohen wrote: post #24

Earlier quoted context omitted.

May I suggest that you also send them a link to Zed Shaw's "Learn C The Hard Way" online book [0], which presents lessons in modern C programming, including the use of tools like Valgrind, etc.? [0] http://c.learncodethehardway.org/book/

I just wrote a comment [0] about my problems with learning C, would you say this book covers the issues that I raised and is worth reading? EDIT: Well, I just looked over the chapters in this book and I'm now extremely excited to give it a read. It seems to cover most of the topics that I'm interested in, so thank you SO MUCH for sharing! [0] https://news.ycombinator.com/item?id=9636122

Post by fr0styMatt2 » Mon, Jun 01, 2015, 1:40 AM UTC

thelogos wrote: post #36

TheAceOfHearts wrote: post #27

I think the problem with learning C is that you need to learn stuff like make, autoconf, how the compiler + preprocessors work (what do all those flags even mean!?), how making "cross-platform" stuff works, how to pull in and use "libraries", C-isms, how to test, etc. C itself is a very small and simple language, but the tooling and patterns are old and mysterious. In college I learned how to program embedded systems…

Personally, the hardest part for me was keeping track of the size of everything. Coming from a higher level language, keeping track of the bits and bytes takes some getting used to. Working with arrays in C is much tougher especially when the compiler will compile almost anything you give it, and even a small mistake is catastrophic. Before C, I was pampered and took everything for granted. Now I appreciated my life…

Post by missblit » Mon, Jun 01, 2015, 2:11 AM UTC

TheLoneWolfling wrote: post #28

vortico wrote: post #15

Earlier quoted context omitted.

There was a mention of garbage being returned from an out of bounds array.

Unfortunately, UB extends far beyond that. To the point of being (very) logically inconsistent. People not familiar with C would naively expect that, for instance, `x[10] == x[10]` is always true even if 10 is out-of-bounds for x (or rather: it may crash, or it may be true.) . But compilers can - and will - assume that this situation is false if it makes the code faster. This sort of thing is my major pain point with…

Post by NhanH » Mon, Jun 01, 2015, 2:14 AM UTC

fr0styMatt2 wrote: post #43

thelogos wrote: post #36

Earlier quoted context omitted.

Personally, the hardest part for me was keeping track of the size of everything. Coming from a higher level language, keeping track of the bits and bytes takes some getting used to. Working with arrays in C is much tougher especially when the compiler will compile almost anything you give it, and even a small mistake is catastrophic. Before C, I was pampered and took everything for granted. Now I appreciated my life…

My pet hate is #include files. The whole way that C handles multiple source files just seems archaic to me, having worked in higher-level languages. I wish C had a proper package system that was standard, so I don't have to mess around with things like include file path order (or my favorite, the C++ template definitions having to be in the header files thing I only recently learned about).

Post by sjolsen » Mon, Jun 01, 2015, 2:45 AM UTC

_kst_ wrote: post #46

Slide 31 says: Actually, this is how arrays are handled in C. A C array is a set of consecutive memory addresses. The first value is pointed to by a pointer. int a[] = {1, 2, 3}; // create an array // a is just a pointer to the first element... No, "a" is an array, not a pointer. Defining an array object does not create a pointer. The expression "a" is implicitly converted to a pointer to the array's first element in…

    void foo (char bar [42]) {
        // ...
    }

    void foo (char (*bar) [42]) {
        // ...
    }