301–310 of 381 posts
Earlier quoted context omitted.
I'm confused as well. Klabnik is no doubt reading this thread. I'd like to know more about the "virtual machine" he supposes the C language targets.
I suspect that by "virtual machine" he means "the C abstract machine". There's arguably little relevant difference between an abstract machine and a virtual machine—for example, Android has an AOT compiler for the Java "virtual machine".
Earlier quoted context omitted.
Here is my (arbitrary) definition of small 1. Have a concise crisp book capturing the language 2. Give you a (false) sense of being productive in a couple of days (maybe a week) 3. Limited syntactic extensibility / metaprogrammability so that you dont run into extremely "clever" online discussions. 4. Ability to be productive without learning a new build tool / ide. 5. Ability to be productive without requiring auto…
I don't see how C passes 2 (it's notorious as a language where it takes 200 lines to make a HTTP request) or 3 (it has arbitrary textual macros, so there's all sorts of "cleverness" e.g. GObject). And I'd regard 4 and 5 as false as even C-with-IDE is less productive than e.g., to return to the same example, OCaml-without-IDE.
As for C, I was looking at small purely from the views of a new comer who is using a book to come upto speed with a language. You can write the programs from c books as is in a simple text editor and just compile / run them. C Books dont spend a huge amount of focus on arbitrary textual macros so in practice you do not run into macros as a newcomer.
C doesn't necessarily teach you how computers work. But it does teach you how software works. Our modern software empire is built on mountains of C, and deference to C is pervasive throughout higher-level software design. >You may have heard another slogan when talking about C: “C is portable assembler.” If you think about this slogan for a minute, you’ll also find that if it’s true, C cannot be how the computer work…
Also, C is learn once, write anywhere. If there is some kind of computer, then there is probably a C compiler for it. That's not true of any other language to the same extent. Know C and you can program anything.
Earlier quoted context omitted.
Here's the C99 standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf There are no occurrences of the words "stack" or "heap" in this document. What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about. If you want to know about the stack and the heap, saying "learn…
People don’t learn C by learning the spec, and virtually every c implementation and runtime I know, it uses a stack and heap. Oddly you seem to recognize this, so I’m not sure what your point is.
's funny, I am certainly aware of having, at some point, at least skimmed over the C99 standard encountered the concept of a storage duration. But, aside from that brief few hours, virtually the entirety of my C-knowing career has been spent thinking and talking in terms of stacks and heaps.
Meanwhile, in my .NET career, I really did (and, I guess, still do) feel like it was important to keep track of how .NET's distinction is between reference types and value types, and whether or not they were stack or heap allocated was an implementation detail.
Earlier quoted context omitted.
C at the very least teaches the difference between stack and heap memory, a crucial concept obscured by most higher-level languages.
Here's the C99 standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf There are no occurrences of the words "stack" or "heap" in this document. What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about. If you want to know about the stack and the heap, saying "learn…
Earlier quoted context omitted.
Here's the C99 standard: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf There are no occurrences of the words "stack" or "heap" in this document. What the spec actually discusses is "storage durations". Now, in many cases you can say, well, "automatic storage duration" means it's on the stack, but that's not something C has any opinions about. If you want to know about the stack and the heap, saying "learn…
Debates about the "stack" rage every couple of years on comp.lang.c. Invariably people conflate two different meanings: (1) an abstract data structure with LIFO ordering semantics, and (2) #1 implemented using a contiguous block of [virtual] memory. The semantics of automatic storage necessarily imply #1, but they do not require #2. Indeed, there are widely used implementations which implement #1 using linked lists (…
Earlier quoted context omitted.
> I think it's fair to say that that remains a problem created by C. That is fair, however, I don't think it's inherently due to C. Yes, most languages use the C ABI for FFI, but that doesn't mean they have to; it's a more general problem when combining two systems, they cannot track statically the guarantees of the other system. With Rust, it has nothing to do with LLVM; it has to do with the fact that we cannot tra…
> With Rust, it has nothing to do with LLVM; it has to do with the fact that we cannot track things, that's why it's unsafe! Even if an implementation of the language does not use LLVM, we will still have UB. I can see that any implementation of unsafe Rust would always have assembly-like unsafeness (e.g. reading an arbitrary memory address might result in an arbitrary value, or segfault). But I don't see why you wou…
> I don't see why you would need C-style "arbitrary lines before and after the line that will not execute, reads from unrelated memory addresses will return arbitrary values" UB
This reason this happens is because we don't compile things down to obvious assembly, they get optimized. Each of those optimizations requires assumptions to be made about the the code. If you break those assumptions, then the optimizations can result in arbitrary results happening. Those assumptions determine what is and isn't UB.
Most languages just don't give the programmer any way to break those assumptions, but languages like C and Rust do. Thus, Rust will always have this 'problem' because it can/will make even more aggressive optimizations then C will, meaning badly written `unsafe` code will have arbitrary behavior and results from the optimizer if the compiler doesn't understand what you're doing.
Earlier quoted context omitted.
true. it's like interior decorator vs. interior designer if you're just going to move couches around and put down throw pillows, who cares about a solid foundation of design fundamentals and architectural psychology.
Yep. In truth, one can almost never win the argument of, "...but do I really need to know this?" But people should be aware that knowing fundamental things provides insight and advantages.
Earlier quoted context omitted.
They don't solve problems created by C, they just solve problems C doesn't. The problems still exist, and sometimes the high-level compiler even picks the wrong solution. Learning C helps you understand when and why this has happened.
Arguably those problems did not exist before the C-era as software wasn't large or complicated enough. C++ directly attempts to improve over C by providing new mechanisms to solve problems encountered by C developers every day. Point is that out of context, a lot of the things modern languages provide seem superfluous. Why have objects? Why have templates, closures, or lambdas? For a novice programmer, these are many…