241–250 of 267 posts
Earlier quoted context omitted.
The layout of things on the stack is completely implementation-defined.
It has been a while since I read the standard, but this seems well into the realm of undefined behavior, not implementation defined.
Earlier quoted context omitted.
Why not? As long as your program is standards-compliant, it should work on any computer with a working C compiler…
- integral sizes aren't standard - little vs big endian - signed int layout - float layout - includes vary - bit field implementations vary - loads of undefined and implementation-defined behavior
Earlier quoted context omitted.
> OOP" done right (aka no inheritance, simply method polymorphism). Why do you consider inheritance a bad feature of OOP?
Say you decide to make a video game, and you decide to make a couple of classes for your game objects to inherit from. You make the classes Tool and Weapon . You have just prevented yourself from making the game Clue . The solutions to this tend to be ugly, and your object relations will tend to change over time, often in ways that are difficult to reconcile. Thus, GoF suggests to prefer composition instead of inheri…
Earlier quoted context omitted.
Say you decide to make a video game, and you decide to make a couple of classes for your game objects to inherit from. You make the classes Tool and Weapon . You have just prevented yourself from making the game Clue . The solutions to this tend to be ugly, and your object relations will tend to change over time, often in ways that are difficult to reconcile. Thus, GoF suggests to prefer composition instead of inheri…
GoF?
Earlier quoted context omitted.
Say you decide to make a video game, and you decide to make a couple of classes for your game objects to inherit from. You make the classes Tool and Weapon . You have just prevented yourself from making the game Clue . The solutions to this tend to be ugly, and your object relations will tend to change over time, often in ways that are difficult to reconcile. Thus, GoF suggests to prefer composition instead of inheri…
GoF?
> ...or one is a pointer to one past the end of one array object and the other is a pointer to the start of a different array object that happens to immediately follow the first array object in the address space. I was not aware of this special case. What's the rationale? Is there even a way in standard C to guarantee that two array objects are laid out in memory like that, with no padding?
A two-dimensional array?
Earlier 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.
Ok then please prove that C++ is more complicated than Rust by listing which features of C++ are not available in Rust. It's nice that the compiler can tell me when I do something wrong, but I still have to know how to write it correctly in the first place. In Java it's more or less code and forget. And yes, I meant memory safety.
Earlier quoted context omitted.
Another example of arbitrary pointer comparison I'm familiar with is for resolving lock ordering problems. If I have a big set of locks that I need to take to complete a particular operation, a simple way to prevent deadlocking is to acquire those locks in the order of their pointers. 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…
If order of locks is important maybe it's worth considering putting them in an array.
Earlier quoted context omitted.
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…
Rust also has features which interact in subtle and surprising ways. Generics and operator traits bumping into the "coherence" rules is my personal pet peave. I doubt any user would have predicted that interaction, and even though the compiler gives a detailed pointer to why, it's cold comfort. Honestly, after hating C++ for years, trying to use Rust made me appreciate more about C++. I wish someone would make a lang…
https://dlang.org/ https://dlang.org/blog/2017/08/23/d-as-a-better-c/
Ummm, when I run this on gcc 7.3.0 on OS X I actually get: 0x7fff5dbd89fc 0x7fff5dbd89fc 1 Which kind of shoots the whole article in the foot ...