Pointers Are More Abstract Than You Might Expect in C • Hacker News Board

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

#221

Post by steveklabnik » Mon, Jul 02, 2018, 9:26 PM UTC

blub wrote: post #196

whyever wrote: post #95

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.

The biggest ones people ask for are non-type templates, HKT, and sometimes move constructors.

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

#222

Post by jjnoakes » Mon, Jul 02, 2018, 9:28 PM UTC

Rusky wrote: post #219

jjnoakes wrote: post #210

Earlier quoted context omitted.

"Not meaningful" and "undefined behavior" have very different meanings. I agree it's not meaningful, but the standard does define the result of comparing pointers to two unrelated objects with "==", so it's not UB.

Where? The post cites C11 section 6.5.8 paragraph 5, which seems to disagree with you. Of course == comparing unrelated pointers is something you need to be able to do, but relational comparisons (including those based on pointer arithmetic) don't seem to be defined anywhere...

Right, comparisons with are UB, but I'm talking about ==, which is well-defined. It's hard to tell which operator "tzahola" was originally talking about, but I took "comparing the address" in this context (especially given his example code) to mean "==", or at least, include it, which makes the statement "comparing the addresses of stack variables is undefined behavior" incorrect in this context.

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

#223

Post by _0w8t » Mon, Jul 02, 2018, 9:30 PM UTC

mhh__ wrote: post #209

_0w8t wrote: post #118

Earlier quoted context omitted.

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++.

I think it is fair to say that modern ISA are built around a C-speaking world if that's more reasonable. This may also be especially true - on a technicality: Does the ISA actually specify the exact cache structure of a CPU? If not, then it is definitely reasonable to say that the ISA (if not the whole microarchitecture?) then is designed with C in mind.

Surely nobody designs ISA that performs badly for C programs. But it does not mean that it was designed to run average C programs optimally.

If one searches for "data oriented programming", then a typical link is about game programming and how using struct of arrays instead of array of structs improves performance due to better cache locality. But such struct of arrays are hard to use and maintain in a general purpose code. It works ok only in game engines or in numerical code when one have a lot of things with the same attribute and the total number of different attributes is low. So if anything, ISA is tailored to allow max performance when coding games or numerical recepeices in particular style. That style is not feasible to apply, for example, in kernel as C has very poor support for it and one gets too many different attributes to get real benefits from following such style.

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

#224

Post by CyberDildonics » Mon, Jul 02, 2018, 9:31 PM UTC

pjmlp wrote: post #155

CyberDildonics wrote: post #85

Earlier quoted context omitted.

I feel like C++11 and Rust have shown a way forward and the C standard should focus on a design that takes into account ownership and protected arrays in a simple way, hopefully as backwards compatible as possible. Maybe the solution is for the major compilers to default to strong static analysis. Even though there are safe languages, the enormous integration and compatibility of C means that it isn't going anywhere…

It is a matter of mindset, multiple safe C variants have been attempted throughout the years. Even lint was already available in 1979, yet hardly anyone used static analysis tools on C codebases.

Which is why I mentioned defaulting to strong static analysis. Having it as a separate tool or an unknown flag is not enough.

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

#225

Post by mabynogy » Mon, Jul 02, 2018, 9:38 PM UTC

Not related to the content but I find the colored links in the nav a simple and very good idea.

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

#226

Post by MaxBarraclough » Mon, Jul 02, 2018, 9:39 PM UTC

jeremiep wrote: post #143

pests wrote: post #119

Earlier quoted context omitted.

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

When you realize the compiler's optimizations only account for about 10% of the total program's performance you find that the other 90% is entirely up to the programmer. Architecture, data structures, batching operations, memory locality, and a bunch of other metrics are all concepts the compiler can't really help you with whatsoever and they have a much larger impact on performance than the 10% the compiler is actua…

You're right to emphasise good data-structures and algorithms (also concurrency, parallelism, etc), but compiler optimisation is nothing to sneeze at. '10%' is laughably off-base.

From a quick google: compiler optimisation can accelerate CPU-bound code to over 5x the unoptimised performance. https://www.phoronix.com/scan.php?page=article&item=clang-gc...

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

#227

Post by cryptonector » Mon, Jul 02, 2018, 9:47 PM UTC

pjmlp wrote: post #141

cryptonector wrote: post #132

Earlier quoted context omitted.

The only thing I ask of any C-replacement languages is that they make it possible to describe ABIs, message layouts, and on-disk formats in detail. C historically does that well enough, though not really all that well (e.g., bitfields and enums have issues, and struct packing is not always easy to get right). There is a lot of value to this! The ability to mix object code from multiple languages (FFI) is critical, an…

C is the common denominator for FFI for OS that happen to be written in straight C, which then mix the C ABI with OS ABI. That is not true in mainframes, Windows (ongoing replacement of Win32 with COM, it is lot of fun to do COM in C, more so UWP), Android (JNI, AIDL), Web (JavaScript/WebAssembly), iOS/macOS (Objective-C runtime), Fuchsia (IDL).

Re: COM, that works because MSFT can a) commit to an ABI for C++, b) they can stick to a subset of C++ that makes that easy enough. Similarly for OS X.

The point isn't to stay in a C-like world. The point is that it must be possible to specify an ABI, file formats, and so on, in the host language. Yes, we can use external IDLs (even user them as DSLs if you like). I know all about and have worked with quite a lot of them (e.g., ASN.1, XDR, and many many others). But when you get down to a certain level, a light-weight approach really pays off. For example, at the system call level, and for many sufficiently simple file formats and such. At a higher end in complexity, on the other hand, then ASN.1 and friends pay off instead, mostly in a) obtaining interoperability with implementations written in other languages, b) managing extensibility.

Another thing is that some of us think about how things work at many levels. It's nice to be able to think about an interface and accurately picture what goes on at a low layer. It's difficult to do that with HLLs. But HLLs can easily have features that allow fine-grained control of or exposure of low level details, and that's what I'm saying I want to have as an option.

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

#228

Post by ash_gti » Mon, Jul 02, 2018, 9:50 PM UTC

tzs wrote: post #39

Note that if the two pointers are passed to a function, and the comparison is done in the function, the results are different: #include void pcmp(int *p, int *q) { printf("%p %p %d\n", (void *)p, (void *)q, p == q); } int main(void) { int a, b; int *p = &a; int *q = &b + 1; printf("%p %p %d\n", (void *)p, (void *)q, p == q); pcmp(p, q); return 0; } That is giving me: 0x7ffebac1483c 0x7ffebac1483c 0 0x7ffebac1483c 0x7…

Did you use gcc or clang or...?

When I ran this locally I get:

    0x7ffeee2a4808 0x7ffeee2a4810 0
    0x7ffeee2a4808 0x7ffeee2a4810 0

With -O0 I get 1/1 instead of 0/0 so this appears to be a compiler optimization.

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

#229

Post by tzahola » Mon, Jul 02, 2018, 10:10 PM UTC

jjnoakes wrote: post #222

Rusky wrote: post #219

Earlier quoted context omitted.

Where? The post cites C11 section 6.5.8 paragraph 5, which seems to disagree with you. Of course == comparing unrelated pointers is something you need to be able to do, but relational comparisons (including those based on pointer arithmetic) don't seem to be defined anywhere...

Right, comparisons with are UB, but I'm talking about ==, which is well-defined. It's hard to tell which operator "tzahola" was originally talking about, but I took "comparing the address" in this context (especially given his example code) to mean "==", or at least, include it, which makes the statement "comparing the addresses of stack variables is undefined behavior" incorrect in this context.

You're right. There's no undefined behaviour for ==:

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.

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

#230

Post by shakna » Tue, Jul 03, 2018, 12:51 AM UTC

mpweiher wrote: post #78

shakna wrote: post #43

Earlier quoted context omitted.

Except clang's behaviour changes depending on the optimisation level. If you use -O1, then you get a different result.

Yes, because the pointers are different at -O. As there are no guarantees as to the relative placement of auto/stack variables relative to each other, that is perfectly fine.

If the behaviour differs at optimisation levels, would that not suggest that it is not a sane behaviour?