Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C for high level programmers (slides)

charliethe.ninja

Post reply on HN
Print view View original

61–70 of 129 posts

Re: C for high level programmers (slides)

#61

Post by yoklov »

WalterBright wrote: post #30
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…

I never found C's transition from source code to hardware to be confusing. I struggle to comprehend why so many people, some longtime professional programmers, have trouble understanding what a linker does. On the other hand, I downloaded the CUDA SDK. I couldn't even figure out where the GPU compiled code even resided. I suppose I was just supposed to take it as it "just works" (and it did), but it all left me highl…

Probably in memory? Most GPUs use different ISAs, and they're mostly proprietary, so they usually have to be compiled (at least partially) at runtime.

Then again, never used CUDA so who knows

Re: C for high level programmers (slides)

#62

Post by yoklov »

userbinator wrote: post #39
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…

I don't think you need to learn the build system until after you're comfortable with single-file programs, where "gcc yourfile.c" is enough. Then add compiler options, and get to know Makefiles after your programs grow large enough to require multiple files. GNU coreutils (and in general, a lot of the GNU projects) are rather excessively complex and certainly not what I'd advocate "learning by example" from. Take a l…

Definitely. Not only is it worth doing the wrong thing first to understand why its wrong, its also often worth revisiting after you have more experience with the other alternatives.

Especially when it comes to programming paradigms and stuff like 'best practices'. Theres a lot of cargo-culting in programming culture, and you really shouldn't take it as dogma.

Re: C for high level programmers (slides)

#63

Post by reitzensteinm »

gshrikant wrote: post #59

As someone who occasionally dabbles in C code, I am interested in knowing what is the modern take on `goto`s. I know they are "harmful" but I often come across code riddled with goto statements [1] and I personally feel that as long as it makes the code readable without significantly obfuscating the logic, goto is a perfectly fine way of doing things (although popular opinion and consideration for best practices have…

If it's genuinely easier to understand with gotos, you can safely ignore the opinion of those that object.

Gotos are a specialised tool that many misuse, especially historically, but when you need them, you need them.

Re: C for high level programmers (slides)

#64

Post by prav »

yoklov wrote: post #60
gshrikant wrote: post #59

As someone who occasionally dabbles in C code, I am interested in knowing what is the modern take on `goto`s. I know they are "harmful" but I often come across code riddled with goto statements [1] and I personally feel that as long as it makes the code readable without significantly obfuscating the logic, goto is a perfectly fine way of doing things (although popular opinion and consideration for best practices have…

Goto is fine. The 'harmful' style was using them in favor of ifs and loops. The things I've seen people do to avoid a goto are pretty awful though. If you ever use a 'do {} while (0)' just to break out of it, you should feel bad. Goto is much clearer and cleaner than nonsense like that.

Agree with above comment. Linux kernel code, especially device driver code use goto a lot.

Re: C for high level programmers (slides)

#65

Post by MarkSweep »

gshrikant wrote: post #59

As someone who occasionally dabbles in C code, I am interested in knowing what is the modern take on `goto`s. I know they are "harmful" but I often come across code riddled with goto statements [1] and I personally feel that as long as it makes the code readable without significantly obfuscating the logic, goto is a perfectly fine way of doing things (although popular opinion and consideration for best practices have…

That's not really the best example of using goto's, as that code is generated from this file:

https://github.com/zedshaw/mongrel2/blob/master/src/http11/h...

A nicer example of the use of goto's in Mongrel2 is the check macro:

https://github.com/zedshaw/mongrel2/blob/a884aef0f4a460e130d...

The convention of the project is that every function that has to deal with an error condition has an "error" label. These macro a used to jump to that label to clean up the function before returning. Here's an example:

https://github.com/zedshaw/mongrel2/blob/a884aef0f4a460e130d...

I think that this use of gotos is more clear than the alternative of a lot of nested if statements checking for success or having the clean up logic duplicated in a lot of places.

Re: C for high level programmers (slides)

#66

Post by yoklov »

pkulak wrote: post #37

I was hoping this would actually tell me how to accomplish something in C. I know all about pointers and memory, but I don't know anything about the current state if C development. What libraries do people use? What are common memory management strategies? Etc.

Libraries depend on what you need to do. A lot of work is done with just the std lib.

For domain specific stuff you use domain specific stuff. For generic stuff, well, you tend not to want generic data structure libs that come with other languages stdlibs because its hard to do those both efficiently and cleanly (you can only pick one). Its easy enough to hack up a dynamic array or a hash table with a fixed capacity that can only insert and get, maybe delete, so you tend to do this when you need it. (Also, a sorted array usually does very well in place of a hash table with not much code)

Memory managment it depend what your doing. I use a lot of arenas, and pools, and as a result very rarely have to worry too much about memory management. Some things become harder here like dynamically sized arrays, but you can do this with chunks of fixed length arrays. (or whatever)

I have to do very little string processing most of the time (and when i do they usually have small, known maximum lengths), and i imagine this memory management technique would work less well for that.

Re: C for high level programmers (slides)

#67

Post by mappu »

halayli wrote: post #17

teaching C and not checking malloc, bad idea. using realloc in the way its used in this "tutorial" can cause memory leaks. realloc should be checked before reassigned because it can return NULL and that will overwrite the previous valid memory address.

>teaching C and not checking malloc, bad idea

On Linux, malloc will appear to give you memory even if there is none left to give, so checking the error is not important.

Re: C for high level programmers (slides)

#69

Post by readme »

From slide 12:

    int my_var = 3; // It's an int!
    my_var = "abc"; // COMPILER ERROR! You clearly stated that it was an int!
"abc" gets interned and has a memory address. The statement my_var = "abc" tries to assign that address to my_var, but since it's not a pointer to char it gets cast to int instead, possibly truncating the value.

The program still compiles, just printing a warning.

Re: C for high level programmers (slides)

#70

Post by iamcreasy »

yoklov wrote: post #61
WalterBright wrote: post #30

Earlier quoted context omitted.

I never found C's transition from source code to hardware to be confusing. I struggle to comprehend why so many people, some longtime professional programmers, have trouble understanding what a linker does. On the other hand, I downloaded the CUDA SDK. I couldn't even figure out where the GPU compiled code even resided. I suppose I was just supposed to take it as it "just works" (and it did), but it all left me highl…

Probably in memory? Most GPUs use different ISAs, and they're mostly proprietary, so they usually have to be compiled (at least partially) at runtime. Then again, never used CUDA so who knows

AMD provides their specification. I guess up to HD4000 series.
Post reply on HN