Earlier quoted context omitted.
Considering that C doesn't have any good facilities for polymorphism, it's going to continue to be the argument of any language that succeeds C. Unless, that is, that successor language also doesn't have any good facilities for polymorphism, in which case we have Go as a fascinating real-world study in how people will incessantly demand them and deride the language for lacking them (which is saying something, conside…
I presume that you are defining C++'s virtual functions as "not a good facility for polymorphism". Why?
Pointers Are More Abstract Than You Might Expect in C
191–200 of 267 posts
Re: Pointers Are More Abstract Than You Might Expect in C
#192Earlier quoted context omitted.
X86 does have array bounds checking now with MPX. Further everything you've mentioned is useful to all languages including the stack. Can you give an example of a negative trade off made for C?
In some languages a call stack is only useful as an optimization and some other form of control flow must be emitted for certain constructs that violate the stack paradigm (e.g. call/cc in Scheme, conditions/restarts in Common Lisp). C is also one of the only languages where general pointer arithmetic is necessary; in most languages used today more restricted forms of pointer arithmetic would be more than adequate. I…
Most of the X86's CISC "style" predates C, and the reverse is mostly true - C was heavily inspired by the PDP's instruction set. When the 8086 came out originally BASIC was a far more important language for the class of processor it was. "Serious" software was much more likely to be raw assembler than C. The processor was just too small and compilers weren't good enough.
Re: Pointers Are More Abstract Than You Might Expect in C
#193> If we step back from the standard and ask our self does it make sense to compare two pointers which are derived from two completely unrelated objects? The answer is probably always no. The one big counterexample I can think of is the difference between memcpy and memmove. The latter is supposed to be able to do arithmetic on memory regions, to see if they overlap. Is this article saying that the standard C implemen…
E.g. if I have three locks I need to take,
lock_t *a = (lock_t *)0x100;
lock_t *b = (lock_t *)0x300;
lock_t *c = (lock_t *)0x200;
then I'll take them in order a, c, b;Re: Pointers Are More Abstract Than You Might Expect in C
#194Earlier quoted context omitted.
Why would you think that Rust is "far simpler" than C++? Exactly the same concepts (with extras on Rust's side because of the ML-like constructs) must be learned for both, except they're distributed differently on the learning curve. And I wouldn't say that Rust's safer than Java either. Memory access errors are basically non-existant in Java and it has quite robust concurrency primitives and libraries.
That’s based on my experience of working with C++ on and off over the last 18 years and reattempting to learn some of the modern pieces of it, as compared to learning and working with Rust over the last 3. I find Rust simpler, more concise, and nearly no footguns. Edit, I didn’t see your Java comment: > I wouldn't say that Rust's safer than Java either. Here’s why it is safer: It has the same set of guarantees about…
My personal opinion is that they have similar complexity, but in general Rust decides to clearly define behaviour as much as possible and fail fast, preferably at compile time. This can be seen when comparing features: memory management is there (supported by the borrow checker), smart pointers are there, references & pointers are there, generics are there (even if not exactly the same), integer and floating point handling are there, concurrency is there (compile-time checking is nice), macros are there (albeit different and perhaps less error prone), string types are more complex than cpp, enums are more complex (but also more powerful), operator overloading is there, iterators are clearly more complex (and the functional aspects in general), etc.
So the average programmer will have to learn a similar amount of concepts or even more in Rust's case.
Where Rust is indeed simpler is error handling and building.
--- I figured you would bring up concurrency, and while Rust's compile-time verification is really nice, Java also has a simpler form in threading annotations. Additionally, I believe it's rare to use such low-level primitives in Java.
Nulls (and type system holes in general) are a correctness issue, not a safety issue, unless we want to argue that all bugs are safety issues.
GC pauses are a performance issue, as you already know.
Saying that Rust threading is safer than Java's is technically correct and Rust is probably a bit safer than Java because of that, but it's hard to argue that Rust should be chosen for a project because of that (this is the whole point of saying X is safer than Y). Java is super-simple to learn compared to Rust.
Re: Pointers Are More Abstract Than You Might Expect in C
#195Earlier quoted context omitted.
> Why would you think that Rust is "far simpler" than C++? C++ as a language is a lot more complicated. It has a lot of features with weird corner cases that interact in unfortunate ways. > And I wouldn't say that Rust's safer than Java either. Depends on what you mean with safe. If you mean memory safe, then they are about as safe. Rust has fewer runtime failures due to concurrency and null pointers though.
Not sure why the above comment is downvoted. The number of features in C++ isn't the root of the problem with C++. The real problem with C++ is that it both has a lot of features and that all of those features interact in subtle and surprising ways. Even if Rust had as many features as C++ (which it doesn't, not by a long shot; Rust is a medium-sized language like Python (though with a far less forgiving learning cur…
Honestly, after hating C++ for years, trying to use Rust made me appreciate more about C++. I wish someone would make a language which took the best parts of both.
Re: Pointers Are More Abstract Than You Might Expect in C
#196Earlier quoted context omitted.
Why would you think that Rust is "far simpler" than C++? Exactly the same concepts (with extras on Rust's side because of the ML-like constructs) must be learned for both, except they're distributed differently on the learning curve. And I wouldn't say that Rust's safer than Java either. Memory access errors are basically non-existant in Java and it has quite robust concurrency primitives and libraries.
> Why would you think that Rust is "far simpler" than C++? C++ as a language is a lot more complicated. It has a lot of features with weird corner cases that interact in unfortunate ways. > And I wouldn't say that Rust's safer than Java either. Depends on what you mean with safe. If you mean memory safe, then they are about as safe. Rust has fewer runtime failures due to concurrency and null pointers though.
And yes, I meant memory safety.
Re: Pointers Are More Abstract Than You Might Expect in C
#197Earlier quoted context omitted.
> You don't need to use any polymorphism (generics or traits) in Rust. You can use it as a pure structs and functions language like C This just means that the Rust language does not have the feature of being simple. Of course, there are sane subsets of C++ also (e.g., do not use new/delete), but this does not mean that C++ is a sane language. The same goes for Rust, probably.
> The same goes for Rust, probably. Well, at least you have the good grace to admit that you haven't used Rust. :P
What a snarky reply from someone who already knows that Rust is not simple. The person you replied to was right, and yet you cast doubt on what he guessed to be true.
Re: Pointers Are More Abstract Than You Might Expect in C
#198the comparison at the start is nonsense - there is no specification for the ordering or location of stack variables. by taking the address of these variables, you could see that they actually are the same value, and so intuitively you’d think they might be the same, but a different compiler might put them in different locations. or they may be elided entirely through optimisation. it’s far safer to fail the equality…
Surely the point of writing an if-block testing the equality of the pointers is precisely because the code isn’t assuming that they are the same - but maybe it has something it wants to do if it finds itself running somewhere where they are. Writing code which assumed those pointers were equivalent would be bad, but this code doesn’t do that. Instead, it looks like the compiler assumes that the pointers won’t be the…
Re: Pointers Are More Abstract Than You Might Expect in C
#199Re: Pointers Are More Abstract Than You Might Expect in C
#200Earlier quoted context omitted.
The obvious flipside of this is that those C programs written for Burroughs never had any chance of running on anything but Burroughs. The only difference is that C offloads the effort of portability onto the user, whereas other languages at least attempt to make it portable in the compiler.
Why not? As long as your program is standards-compliant, it should work on any computer with a working C compiler…
- little vs big endian
- signed int layout
- float layout
- includes vary
- bit field implementations vary
- loads of undefined and implementation-defined behavior