Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pointers Are More Abstract Than You Might Expect in C

stefansf.de

Post reply on HN
Print view View original

91–100 of 267 posts

Re: Pointers Are More Abstract Than You Might Expect in C

#91

Post by CyberDildonics »

kibwen wrote: post #65
NeedMoreTea wrote: post #33

Earlier quoted context omitted.

That was the argument of C++ advocates in the 90s.

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…

Wasn't it originally a much bigger deal to be able to have the facilities for more generic programming before templates? These days people's threshold for bloat seems much higher, while the penalty for allocation and jumping around in memory are much higher as well.

Re: Pointers Are More Abstract Than You Might Expect in C

#92

Post by bluejekyll »

blub wrote: post #80
bluejekyll wrote: post #64

Earlier quoted context omitted.

> To me Rust is more a C++ replacement than a C replacement. People make this comparison a lot, but it’s not fair. Rust is far simpler, in terms of number of features of the language, to that of C++. It’s fair to say that Rust is far more expressive than C, but this just represents an initial learning curve that is higher than C, but not as high as C++. The type system is fairly simple in Rust, but it can be used to…

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 memory safety as Java. In terms of concurrency, it is safer because of the single mutable reference guarantees across threads, enabled by a better type system. The type system is stronger, which allows for more details about code to be put into types, like algebraic data types of Rust, without the limitations of Java’s non-generic enums.

And the big one: no bare nulls allowed. This reduces a huge set of logic errors. Now Java is getting Value types in a future release which will allow for a true Option type in Java, ie one that cannot itself be null, the other points still stand.

On top of that, in large applications the GC can become an Achilles Heel, where it eventually pauses the application with dire consequences. Rust of course has no GC. And a great side effect of this is that Drop (java Finalizers) actually work in Rust, which is amazing.

Basically for these reasons, Rust is safer than Java.

Re: Pointers Are More Abstract Than You Might Expect in C

#93

Post by betterunix2 »

jstimpfle wrote: post #72
lmm wrote: post #60

Earlier quoted context omitted.

Very speculative, don't take any of this as gospel: The very concept of "the stack" implies a C-style evaluation model. Having a single address space for both code and data mainly just gives an opportunity for optimisation to fail. Everything-is-mutable gives a lot of opportunity for optimisation to fail. The compiler wants the program in SSA form, it register-allocates to a bunch of reused names, only for the CPU mi…

The stack is one of those things that would fall under "support for common paradigms". I checked that PDP-11 (the machine on which C was created) already had a hardware stack - and probably even older machines. There are many other programming languages that have the concept of a call stack. Hardware stacks are just an optimization to support this paradigm, and you are not required to use it. Conversely, C does not r…

"The stack is one of those things that would fall under "support for common paradigms"."

Maybe for imperative languages where there is no support for lambda expressions (like C), but in Lisp or in functional languages call stacks are not part of the basic semantics. To put this in C terms, compilers for those languages will rewrite functions to take an extra argument called the "continuation", which is itself a pointer to a function, that is called when a function "returns." The result is that all function calls are tail calls, and by heap-allocating arguments and local variables (which is also necessary because it is possible to create and return a lexical closure), no call stack is needed (but you do wind up relying on a garbage collector). Other continuations are also used e.g. to support exceptions in Common Lisp.

Re: Pointers Are More Abstract Than You Might Expect in C

#94

Post by bitwize »

lmm wrote: post #60
jstimpfle wrote: post #26

Earlier quoted context omitted.

That is said a lot, but what are actual desicions that are made to conform to the C model? What would be good ideas in CPU design that aren't made since they are not compatible with C? (I get it that CPUs have to support some common paradigms and use cases. For example, virtual memory / process isolation, maybe branch prediction things, or support for calling conventions. However, I don't think that is specific to C)…

Very speculative, don't take any of this as gospel: The very concept of "the stack" implies a C-style evaluation model. Having a single address space for both code and data mainly just gives an opportunity for optimisation to fail. Everything-is-mutable gives a lot of opportunity for optimisation to fail. The compiler wants the program in SSA form, it register-allocates to a bunch of reused names, only for the CPU mi…

C doesn't assume a single address space for code and data. Function pointers are quite different beasts than regular pointers (and this is where the "two bit-identical pointers can be unequal in C" bit comes in).

Re: Pointers Are More Abstract Than You Might Expect in C

#95

Post by whyever »

blub wrote: post #80
bluejekyll wrote: post #64

Earlier quoted context omitted.

> To me Rust is more a C++ replacement than a C replacement. People make this comparison a lot, but it’s not fair. Rust is far simpler, in terms of number of features of the language, to that of C++. It’s fair to say that Rust is far more expressive than C, but this just represents an initial learning curve that is higher than C, but not as high as C++. The type system is fairly simple in Rust, but it can be used to…

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.

Re: Pointers Are More Abstract Than You Might Expect in C

#96

Post by reza_n »

nostalgeek wrote: post #13
gilgoomesh wrote: post #2

This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…

The following is purely my opinion. Rust might have gone too far the other way. Yes it strives to be a modern language, with a lot of functional programming features and "OOP" done right (aka no inheritance, simply method polymorphism). To me Rust is more a C++ replacement than a C replacement. A replacement for C should try to be as simple as possible while fixing C weak typing mess with strong typing for instance,…

> C aficionados often claim they love C because it's "simple"(it isn't) That's what they mean, they love C because you can't really do OO with it

I do not think C programmers are anti OO. Infact, a lot of C patterns are modeled on OO (struct + function). I think the appeal of C is that you are able to write the fastest implementation any given algorithm, something that just isn't possible in most other languages.

Re: Pointers Are More Abstract Than You Might Expect in C

#97

Post by Koshkin »

gilgoomesh wrote: post #2

This scratches the surface of why I hope C slowly fades away as the default low-level language. C sounds simple when you look through K&R C. C lets you feel like you understand the stack, ALU and memory. A pointer is just an integer and I can manipulate it like an integer. But the reality is filled with a staggering number of weird special cases that exist because memory doesn't work like a simple flat address space;…

Road to Rust is paved with good intentions. (Same is true about C++.)

Re: Pointers Are More Abstract Than You Might Expect in C

#98

Post by foxhill »

jameshart wrote: post #30
foxhill wrote: post #17

the 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…

> Instead, it looks like the compiler assumes that the pointers won’t be the same and refuses to let you entertain the possibility at all.

and indeed it should - it’s sane to use the address of a stack variable for the purposes of writing something into it, but assuming that it forms some sort of array in memory is sure to cause pain if you rely on that assumption.

Re: Pointers Are More Abstract Than You Might Expect in C

#99

Post by crehn »

Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, 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.

Can someone explain to me the rationale behind this? Why not just "two pointers compare equal if they point to the same address"?

Re: Pointers Are More Abstract Than You Might Expect in C

#100

Post by Kenji »

crehn wrote: post #99

Two pointers compare equal if and only if both are null pointers, both are pointers to the same object (including a pointer to an object and a subobject at its beginning) or function, both are pointers to one past the last element of the same array object, 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 rationale behind this "mess" is precisely that people cannot write code like in the first example of the blog post, effectively relying on undefined behaviour, and have this ugly code work most of the time.
Post reply on HN