151–160 of 396 posts
"Better tools exist to do this job"
"C is not needed anymore" (Yet no contender has ever come close to it, hehehe --my2c)
There, saved you a ton of reading time.
Earlier quoted context omitted.
> "grunt" I'm sorry, you cannot use this keyword as it will cause a conflict with Javascript tools.
Most people use gulp now -- the reimplementation of the reimplementation of make in JavaScript because reasons.
Earlier 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?
Earlier quoted context omitted.
C was not the only way of doing it. Many of us were enjoying the danger of getting low level with Think/Quick/Turbo Pascal and Modula-2.
Turbo Pascal even allowed to mix in assembler right in your source code. That was super awesome at that time. No need to write separate assembly code, no need to link ! (not to say that Turbo Pascal was the only one to do that, just fond memories...)
Earlier quoted context omitted.
Usually declare variables one per line, so, type is still clear when: char* var1; char var2;
C does not in anyway forbid having two definitions on the same line hence char var2, *var1; is valid C while in Java this would be illegal char var2, [] var1; So the syntax is correct and all you are doing is to add style rules that make it less readable.
That said, I understand the differences in traditions.
I think that C's syntax is flexible that we can each go to our own, and decide which is more readable.
for (size_t i = 9; i EDIT: Ugh, just found this too:
isset[!!largeA[i]] += 1;
EDIT2: In section 5 is the statement than unsigned integers "can be optimized best." This is flatly untrue on x86 and I suspect many other architectures. Compilers can and do take advantage of undefined signed overflow to optimize signed arithmetic; the same is not possible with unsigned arithmetic. See https://kristerw.blogspot.com/2016/02/how-undefined-signed-o...
Earlier quoted context omitted.
There is also the issue of undefined and implementation defined behavior. When developing on one platform for an extended period of time, it is human nature to forget which features are implementation defined as you use them day after day and then have unexpected errors/flaws when porting.
Undefined behaviour actually isn't the monster that most C language lawyers want you to believe it is. With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Compilers are also mature enough to issue warnings about the use of uninitialized variables, missing return statements or mismatched printf specifiers. Heck, Clang maybe has more than 250 -W options.
Earlier quoted context omitted.
There is also the issue of undefined and implementation defined behavior. When developing on one platform for an extended period of time, it is human nature to forget which features are implementation defined as you use them day after day and then have unexpected errors/flaws when porting.
Undefined behaviour actually isn't the monster that most C language lawyers want you to believe it is. With tools like valgrind, address sanitizers and modern debugging toolchains, most of these issues can be caught. Compilers are also mature enough to issue warnings about the use of uninitialized variables, missing return statements or mismatched printf specifiers. Heck, Clang maybe has more than 250 -W options.
It's been a decade or more since I've worked in C (and have never been a heavy C coder). Is "modern C" really a thing? I mean, is there some subset of C that is safer than what I think of when I think of C? I know about stuff like reference counting techniques, rather than manual memory management, for example, and that goes miles towards safer coding. But, even so, the variety of ways you can shoot yourself in the f…
Go has chosen to omit assert(), because assert() is frequently misused they say. Antibiotics are also frequently misused, but that is not a good reason to prohibit them. The omission of assert() makes Go a non-starter. Rust seems more promising, but it is still not to the point where I am interested in rewriting SQLite in Rust, though I may revisit this decision in future years. Some current reasons to continue to pr…
I can see the latter, but why the former? Package management that has understanding of language dependencies is a huge productivity booster.
> (5) Rust has "immutable variables". Seriously? How can an object be both variable and immutable? I realize this is just an unfortunate choice of terminology and not a fundamental flaw in the language, but I believe details like this need to be worked out before Rust is considered "mature".
A variable/binding is mutable, the object is not. I don't see the problem.
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.