Might have been because of the `else if (ch == 'q') break;` line. If he used a switch statement he would have needed to use a goto to break out of the loop.
That's a reasonable guess, but a return would work there. I think I did it this way because all the breaks you need in a switch are noisy -- too noisy if you'd like to write one action per line. However, you can mute the noise by lining it up:
switch (getchar ()) {
break; case ' ': enter_text ();
break; case 'f': view = formulas;
break; case 'h': col = (col == 0 ? 0 : col-1);
which also makes oops-I-forgot-the-break hard to miss. I hadn't thought of that pattern yet. (You could define a macro for "break; case" too; my friend Kragen calls that IF.)
But I mostly stopped coding in C after around this time.
Interestingly, in http://canonical.org/~kragen/sw/dev3/paperalgo, I haven't yet run into the desire to have more than one `case` in a pattern-matching `switch`. I just added that piece of code from Vicissicalc to the paperalgo page.
Not exactly. But it does create a no-op default. I've never seen/used this pattern, so I would have to go compile this down into assembly and play with it to give you a more complete answer.
Dropped by dead-code elimination. A compiler might conceivably issue a warning that the first break is unreachable, though that's never happened so far.
I've requested the paper through my school's inter-library loan, I'll know in about 4 hours if the librarian can get me a copy. If you send me an email and I get a copy I can forward it on to you. (Though it wouldn't surprise me if someone else 'liberates' the paper for everyone before then.)
It's not just that, it also doesn't have automatic destruction of objects, so any local array or structure containing a pointer needs to be laboriously freed by hand.
And in other words, nobody should be writing anything in C. Ever. The need to be compatible with programs written in C violates my rule against writing anything in C and is therefore not a valid reason to write crypto stacks in C.
Pure C does not have automatic destruction of objects, but gcc has an extension to do it. Take a look at systemd's source code to see it in action. It's very similar to C++'s RAII, and can also do things like closing file descriptors.
Would love to hear the answer to this as well. For the types of thing C is used for, I do not know of another language that can _practically_ be used for the same thing, while maintaining the same level of performance. Rust looks promising but is not mature yet.
Isn't Go designed to fill this niche? It's supposed to be a low-level systems language, but with "friendlier" features than C, and built-in concurrency support.
They kind of recanted that statement and said they meant it for "web servers" and stuff like that. However I know there has been at least a window manager made in Go.
I don't think it's the best fit, but it's a lot better than many current solutions. I personally prefer Haskell for anything others would write in Go, however many may find Ocaml or Erlang to fit them better.
However I'm biased and believe that functional programming is a better fit, more bug-free, easier, and simpler for most use cases than imperative programming.
Before there was C, there was Pascal. You didn't have malloc in Pascal. At ETH Zurich the standard OS was written in Oberon: it ran directly on the hardware with a garbage collector collecting everything.
Go also has a very highly quality crypto implementation. It has all of the good-code features that gnutls lacks: comments that make sense, unit tests, automatic memory management (of course), useful types, etc.
How are exceptions like gotos? I don't see any similarity. If by "essence" you mean they jump to a specific line of code, then lots of things can do that - switch/case , if/else, do/while, function calls/returns, etc.
Your first sentence doesn't make any sense -- There is so much more that you can do with a $20/mo internet connection than a $20 DVD. I would go as far as to say that today, in the developed world, an internet connection is a necessity; DVDs on the other hand are not.
