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

111–120 of 267 posts

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

#111

Post by nine_k »

beojan wrote: post #41
nostalgeek wrote: post #13

Earlier quoted context omitted.

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

> To me Rust is more a C++ replacement than a C replacement Precisely. Rust is what C++ would be if it didn't need to be backwards compatible (though I'm not a fan of some of the syntax choices in Rust). Unfortunately, there's a reason C++ needs to retain backwards compatibility and its for that reason that Rust isn't going to replace C++ anytime soon. > That's what they mean, they love C because you can't really do…

The good thing about no-runtime languages is that you can mix modules written in them, within reason.

So Rust can make inroads into existing C++ code bases where it makes sense faster than we think, without replacing C++ wholesale for a long time. Firefox itsef is likely such a codebase.

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

#112

Post by slededit »

betterunix2 wrote: post #86
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)…

"That is said a lot, but what are actual desicions that are made to conform to the C model?" Among other things, special instructions to support a function call stack, which is very much specific to the C model. In Lisp the call stack is unnecessary because of the use of continuation passing style, which implies that all function calls are tail calls and mostly requires that everything be heap-allocated (many compile…

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?

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

#113

Post by Rusky »

reza_n wrote: post #96
nostalgeek wrote: post #13

Earlier quoted context omitted.

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.

That's not a very satisfying answer, as it doesn't apply to the languages typically compared with C- C++, Rust, or even D, Nim, Zig, etc.

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

#114

Post by bitwize »

icedchai wrote: post #63
nostalgeek wrote: post #13

Earlier quoted context omitted.

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

I've been programming C on and off for 30 years. Rust feels too complex to be a C replacement. C++, yes... C's paradigm is really about working with memory. Anything that restricts memory access with bound or type checking is going to feel like "not C"...

C doesn't have anything to say about whether bounds are checked or not. That's why so many things, including pointers to arbitrary locations in memory, are undefined: the standard was built to accommodate both embedded system implementations where scribbling all over RAM is desirable, and implementations that do things like bound checking.

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

#115

Post by MaxBarraclough »

kbenson wrote: post #103
MaxBarraclough wrote: post #75

Earlier quoted context omitted.

> I think there's room for other languages to occupy a similar space but they're need to focus on no-std-lib no-runtime operation (not always the sexiest target). You're describing the Zig language! It aims to be as fast as C, and unlike most languages that say this is a goal, it means it. There's no "almost as fast as C if you ignore the garbage-collector and the array-bounds-checking", it's actually as fast as C. I…

> faster even than hand-tuned assembly I think you and I are working off different definitions of what that means, as my definition doesn't really allow for a faster implementation (unless there's some really spooky stuff going on in the compiler). I suspect you mean faster than a popular hand tuned implementation.

Obviously Zig's output (courtesy of its LLVM backend) can be expressed and distributed as assembly code, but it's not hand-tuned, it's compiler-generated.

Whether the hand-tuned assembly code they used was the fastest out there, I'm not sure. I'd hope so, or they're being misleading.

I might get time to re-watch the relevant part of the video - it's around the 21 minutes mark - https://youtu.be/Z4oYSByyRak?t=1292

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

#116

Post by slededit »

brandmeyer wrote: post #56
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)…

Support for unaligned memory accesses in hardware is one. The exceeding majority of variable accesses are through pointers of the correct type, and are therefore to variables that are at least naturally aligned. But a very small handful of systems/procedures make unaligned accesses through type-punned pointers. Rather than just crash on these programs, processors will perform multiple memory accesses and stitch the r…

> Hardware doesn't just get turned off for conforming programs. Its there consuming energy and giving off heat on all of them.

Idle CMOS transistors don't have very much leakage current. They do consume some power but not much. Intel has gotten a lot better about clock gating ensuring more of the chip is truly idle.

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

#117

Post by JdeBP »

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…

Because (a) pointers do not point to addresses, and (b) now you have to define the concept of addresses being equal in the language standard and haven't actually reached the goal. (-:

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

#118

Post by _0w8t »

ChrisSD wrote: post #4
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;…

But as you know, CPU ISAs are designed for C programs and compilers are optimized for C programs. So everything, even new languages like Rust, have to buy into C's model to some extent. Truly getting out from under C's shadow is going to be very difficult. Maybe better languages are a first step on that path but they are only a small step.

To get the max performance on modern CPU the code has to be cache-aware. It is painful to program for that in C. One often ends up with very complex macros or writing code generators that writes CPU-specific C code. So modern ISA are not designed for C.

By such arguments one can claim that CPU are designed for Fortran as it's compilers allows to write fast code with less efforts than in C/C++.

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

#119

Post by pests »

kbenson wrote: post #103
MaxBarraclough wrote: post #75

Earlier quoted context omitted.

> I think there's room for other languages to occupy a similar space but they're need to focus on no-std-lib no-runtime operation (not always the sexiest target). You're describing the Zig language! It aims to be as fast as C, and unlike most languages that say this is a goal, it means it. There's no "almost as fast as C if you ignore the garbage-collector and the array-bounds-checking", it's actually as fast as C. I…

> faster even than hand-tuned assembly I think you and I are working off different definitions of what that means, as my definition doesn't really allow for a faster implementation (unless there's some really spooky stuff going on in the compiler). I suspect you mean faster than a popular hand tuned implementation.

I don't believe it is possible to hand tune every program to beat a compiler.

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

#120

Post by jstimpfle »

slededit wrote: post #112
betterunix2 wrote: post #86

Earlier quoted context omitted.

"That is said a lot, but what are actual desicions that are made to conform to the C model?" Among other things, special instructions to support a function call stack, which is very much specific to the C model. In Lisp the call stack is unnecessary because of the use of continuation passing style, which implies that all function calls are tail calls and mostly requires that everything be heap-allocated (many compile…

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?

Right. That's what I actually wanted to ask with my first question (but didn't).
Post reply on HN