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

141–150 of 267 posts

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

#141

Post by pjmlp »

cryptonector wrote: post #132
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…

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: Pointers Are More Abstract Than You Might Expect in C

#142

Post by mcguire »

Koshkin wrote: post #84
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 have always kind of wondered why Ada did not catch on as a systems programming language (I think it was designed to fill that niche as well).

1. At the time (i.e. pre-C++), it was a gigantic language. Further, because of the Ada policies (IIRC), you could not subset the language; you had to include the full multi-process model to call it "Ada", for example.

2. There were no good, cheaply available implementations of Ada. GNAT was originally quite awkward and finicky when I first poked at it, years after seeing Ada in a class (and I can't remember what compiler we used there).

3. Most importantly, no common, popular systems picked it up as the preferred systems programming language. MacOS had Pascal for a while, Windows went with C or C++.

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

#143

Post by jeremiep »

pests wrote: post #119
kbenson wrote: post #103

Earlier quoted context omitted.

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

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 actually able to optimize.

The problem is that either programmers don't care, or they can't make the distinction between premature optimizations and architecture planning.

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

#144

Post by pjmlp »

kibwen wrote: post #104
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.

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…

The biggest issue is not how complicated it is, rather there is no good way to prevent people to write C in C++.

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

#145

Post by pjmlp »

mcguire wrote: post #142
Koshkin wrote: post #84

Earlier quoted context omitted.

I have always kind of wondered why Ada did not catch on as a systems programming language (I think it was designed to fill that niche as well).

1. At the time (i.e. pre-C++), it was a gigantic language. Further, because of the Ada policies (IIRC), you could not subset the language; you had to include the full multi-process model to call it "Ada", for example. 2. There were no good, cheaply available implementations of Ada. GNAT was originally quite awkward and finicky when I first poked at it, years after seeing Ada in a class (and I can't remember what comp…

Rational Software actually started their business selling Ada Machines, yep just like Lisp Machines but with Ada, but they pivoted into selling just compilers.

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

#146

Post by mcguire »

Sharlin wrote: post #133

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

Start with one large array and subdivide it into two segments.

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

#147

Post by pjmlp »

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.

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

If you told this out loud during the 80's and early 90's everyone would just laugh.

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

#148

Post by mcguire »

zubyak wrote: post #122
ChrisSD wrote: post #18

Earlier quoted context omitted.

From reading the spec it seems that is undefined behaviour for anything other than `&b + 1`. That is one past the end of b is fine but not `&b + 2` etc.

I wonder why someone decided that accessing "one past the end" should be fine

Short answer: so you can walk a pointer down the elements of an array without having to have weird code to deal with the end.

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

#149

Post by saagarjha »

clarry wrote: post #134
reza_n wrote: post #96

Earlier quoted context omitted.

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

I don't think struct + function is any more OO than tuple + lambda is. That's a very shallow definition of OO.

Well, that's how C++ does everything…

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

#150

Post by pjmlp »

_0w8t wrote: post #118
ChrisSD wrote: post #4

Earlier quoted context omitted.

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

Actually NVidia's Volta was designed specifically for running C++ code.

http://cppcast.com/2017/09/olivier-giroux/

https://www.youtube.com/watch?v=Ud1savVLALA

Post reply on HN