To become a good C programmer (2011) • Hacker News Board

Re: To become a good C programmer (2011)

#101

Post by Annatar » Tue, May 03, 2016, 7:48 AM UTC

genop wrote: post #90

Annatar wrote: post #85

Earlier quoted context omitted.

Let us see... in my day, we called an "asm code generator" an assembler... anyone remember MasterSEKA, Devpac, TRASH'M-One and ASM-one?

1. Program that reads some input (e.g., C language) and generates asm and/or opcodes. 2. Program that reads asm and/or opcodes and generates binary numbers ("object files"). No. 1 is what I need. No. 2 is what I call an "assembler". Although terminology means less to me than what a program actually does.

2. is also what I learned as "assembler": a program which takes ASCII source code (written in a language we call assembler), and assembles that source code directly into a binary executable (no linking).

So, back in the day (and still for me, always):

assembler: ASCII source code in assembler language -- "which language did you code that in? - Assembler."

assembler: the integrated development environment (such as ASM-One) which produces executable machine code straight from source, with no linking step in-between; also known as a two-pass optimizing assembler.

Re: To become a good C programmer (2011)

#102

Post by greenpenguin » Tue, May 03, 2016, 10:23 AM UTC

joshumax wrote: post #37

When I first started out with C (and back at that time it was the first programmimg language I started learning) I read a majority of the "standard" books and felt rather confident in my understanding of the basics, but when it came to actually writing C, I never felt like I was writing good, pragmatic code. So I started combing through the sources of popular FOSS software like gtk, musl libc, Linux, OpenRC, gcc, etc…

This sounds like a good way to learn, but I would worry about picking up bad habits. Do you have any recommendations of (C) projects etc. that are particularly well written?

Re: To become a good C programmer (2011)

#103

Post by optforfon » Tue, May 03, 2016, 1:27 PM UTC

ArkyBeagle wrote: post #29

ams6110 wrote: post #24

Earlier quoted context omitted.

I would say generally I feel that way about any language I've learned. Initially they are pretty easy and the examples given include slick solutions to contrived problems. Then you get into wanting to do real work and you learn about all the corner cases and ambiguities and landmines that are hidden farther afield. Can anyone name a language that they've grown to like more the more they learned about it? I would gues…

My favorite language remains 'C'. You don't have to even look at the corner cases, landmines and ambiguities - use the subset of the language that works. Other than things like signed integer weirdness, most complaints about 'C' revolve around the library. Well, don't use those parts of the library.

Except that generally the point of using C is to squeeze performance out of your alogorithms - so you can't limit yourself. But even the simple straightforward stuff has been done just sloppily. I think we just take for granted that it's part of the learning curve and that programming just isn't easy.

And eventually your fingers memorize all the nuanced and sure if you don't screw up it all works. But it's designed in a way where you end up shooting yourself in the foot. It's hard to reason about pointer and reference notations, everyone eventually miss a break in a switch - const is weird, arrays vs. pointers is weird. Symbols are needlessly overloaded to do different hings. Things that seems like they'd work for strange reasons don't EXAMPLE:

foo(const char p) { }

main(int argc, char argv) { foo(argv); }

I really really recommend opening up "Expert C Programming". I promise by page 50 you will be angry - not because there are so many gotchas, but because most of them are completely fixable. Just no one has bothered to do it

Re: To become a good C programmer (2011)

#104

Post by School-Cotton » Tue, May 03, 2016, 2:19 PM UTC

genop wrote: post #100

School-Cotton wrote: post #94

Earlier quoted context omitted.

No. 1 is literally the exact definition of a "compiler". I still don't understand the distinction you're making.

That's because it is a compiler. No. 1 is a program that accepts input (e.g., RTL, MINIMAL, etc.) and generates asm. I like to call this an asm code generator. Because today when people say "compiler" they are often referring to a collection of programs, some of which do not generate asm.

I see. So you are excluding the preprocessor, linker, type-checker (for some languages this is a separate program), assembler, etc.?

Re: To become a good C programmer (2011)

#105

Post by keenerd » Tue, May 03, 2016, 3:52 PM UTC

jsnk wrote: post #19

What's a good practical but small enough project you can do with C? Typically if you are learning Ruby or Node, people recommend creating a blog. What's something like that for C?

Grab an AVR microcontroller. Make a clock.

Microcontroller-C is extremely different from application-C but there are many less complicated concepts. Like never having to touch memory allocation or string munging.

Re: To become a good C programmer (2011)

#106

Post by genop » Wed, May 04, 2016, 4:00 AM UTC

School-Cotton wrote: post #104

genop wrote: post #100

Earlier quoted context omitted.

That's because it is a compiler. No. 1 is a program that accepts input (e.g., RTL, MINIMAL, etc.) and generates asm. I like to call this an asm code generator. Because today when people say "compiler" they are often referring to a collection of programs, some of which do not generate asm.

I see. So you are excluding the preprocessor, linker, type-checker (for some languages this is a separate program), assembler, etc.?

Yeah. I'm sorry about the terminology. I guess I just like the term "code generator".

When I use that term I envision simple filters that take ASCII input, maybe even some sort of "template", and transform it into some other format that's useful. Ideally, asm. But not always.

For example, in GCC, for x86, there's a couple of programs that operate on i386-opc.tbl and i386-reg.tbl. I would not call them "code generators" but I suspect they are needed in order for "gcc -s" to work.