Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.
I've found goto to be a good way of dealing with exceptions in low-level C. For example: void* foo() { int handle = get_some_handle(); if (handle I've seen this pattern frequently in the Linux source code. I think this is an example of a case where usage of goto improves readability and reduces errors.
Modern C [pdf]
321–330 of 396 posts
Re: Modern C [pdf]
#322Earlier quoted context omitted.
Depends on what you are writing. C isn't 100 percent replaceable right now but the more people bitch about it and support the alternatives, the better for the future.
Just curious, what are us C apologists supposed to be apologizing for: - A lack of suitable replacement for C? - C is too ubiquitous? - C has been an integral part of most of the best software ever written?
I would guess the "C apologism" in the original comment is referring to defenses of C that pretend C is safe "in practice" (or "for people who know what they're doing") or minimise/ignore the strong correlation between the use of C and serious problems/vulnerabilities.
Re: Modern C [pdf]
#323Earlier quoted context omitted.
> "what does `public static void main` mean?" The problem with this question is that there is a ton of stuff you need to understand before you can really answer that question fully. To know what public means, you need to understand classes, and visibility rules for classes. To understand static fully, you kind of need to know how c++ works, since it's equivalent to a bare function in a namespace. Void is the type of…
Then why start teaching programming with Java in the first place when understanding those concepts involves an at least mediocre understanding of object orientation? There are many more languages that implement a "Hello, world!" with one line of code. If explaining "public static void main" is too hard, maybe one is using the wrong tool.
For me and probably many others having it go unexplained was like dangling carrot in front of me. I went home and read more about it.
Re: Modern C [pdf]
#324Earlier quoted context omitted.
Yeah, again and again. it's like blaming a hammer for the potential of breaking your finger when you use it, and proposing the use of a spoon, instead.
This C apologism is holding the industry back. Software development has changed many times over since C came out and it just isn't a good tool for tackling a lot of the issues that we have today. Just about every software project written in C has some serious bugs. I personally judge a language by how well it lets you to define abstractions. In C's case, it doesn't let you do that very well.
Re: Modern C [pdf]
#325Earlier quoted context omitted.
"Just about every software project written has some serious bugs" There, fixed it for you. Seriously, vulnerabilities and bugs are found everywhere not just in C. I've been programming for 35 years, in so many languages I lost count, and every time I've seen the 'let's not use C because it'll lead to bugs' it was to be replaced by another thing that was ALSO leading to bugs, and/or become so bloated it was in itself.…
The big problem with C is the memory safety issues. It is extremely difficult to write C code and be safe from malicious input. If you use a memory safe language these difficult issues are erased. I realise the compiler/runtime can't stop all bugs but fixing these simple errors goes a long way to producing robust secure software.
Re: Modern C [pdf]
#326Earlier quoted context omitted.
Well, there are two types of people in this world 1. the type that do something 2. the type that claim they could do it better than the first group (this is by no means limited to programming, it is for example pretty common in politics) So please show me an OS written in Go or Rust or Ruby or Python or Java that people can actually use for day-to-day tasks.
There is such a thing as path dependence. C got ubiquitous because of reasons (UNIX?), and now we're stuck with it. Now the historical accident theory is pretty obvious: it could have been an Algol, Fortran derivative instead of C, if only UNIX used that as a basis. C itself could have been designed differently, and if so would probably have different flaws and qualities. Asking for a Rust/Go/Whatever OS is dishonest…
Lots of Pascal, but Pascal really was an engineering constraint at the time if you were doing actual system programming. And back then, that was a serious consideration.
Re: Modern C [pdf]
#327Pardon my noobness, but if I learned and became proficient in C and knew nothing else, would I have a marketable skill? Is it possible for C to be a standalone skill, where ones job could be 100% programming in C, or do you need a lot of auxiliary knowledge outside of that?
Re: Modern C [pdf]
#328Earlier quoted context omitted.
Well, yes, I agree in general bounds should be checked at runtime when it isn't possible to statically verify access at compile time. I'm not sure how default access in C or C++ isn't explicitly avoiding checks. By definition "a[b]" is an unchecked dereference. It doesn't get more explicit than "by definition." Of course if by "explicit" you mean "syntax exists that demarcates unchecked access" then C and C++ will ne…
I mean something like Ada's pragmas: https://en.wikibooks.org/wiki/Ada_Programming/Pragmas/Suppre...
Re: Modern C [pdf]
#329Earlier quoted context omitted.
I've found goto to be a good way of dealing with exceptions in low-level C. For example: void* foo() { int handle = get_some_handle(); if (handle I've seen this pattern frequently in the Linux source code. I think this is an example of a case where usage of goto improves readability and reduces errors.
This looks fine to me. I wonder if C/C++ could be improved by introducing a new keyword `bail` which is the same as `goto` but is only allowed to jump to the bottom of the function. That way, codebases can outlaw `goto` but keep `bail`.
Re: Modern C [pdf]
#330Goto is considered useful by the book: The use of goto and similar jumps in programming languages has been subject to intensive debate, starting from an article by Dijkstra [1968]. Still today you will find people that seriously object code as it is given here, but let us try to be pragmatic about that: code with or without goto can be ugly and hard to follow.
I've found goto to be a good way of dealing with exceptions in low-level C. For example: void* foo() { int handle = get_some_handle(); if (handle I've seen this pattern frequently in the Linux source code. I think this is an example of a case where usage of goto improves readability and reduces errors.
"error(handle, "could not open handle", free_something)"