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

The Descent to C (2013)

chiark.greenend.org.uk

Post reply on HN
Print view View original

71–80 of 96 posts

Re: The Descent to C (2013)

#71

Post by sn41 »

Zababa wrote: post #55
smcameron wrote: post #4

> (In fact, that's what array[i] means – the language defines it to be a synonym for *(array+i).) To really drive home the primitiveness of C arrays, should probably also mention that, because addition is commutative, you could also write i[array] and somewhat surprisingly, it will compile, and work, and it means "*(i + array)" which is equivalent to "*(array + i)" But nobody really does that, because that would be k…

This is actually a really good way to drive home that arrays don't really "exists" in C and are just syntaxic sugar for pointer arithmetic.

This is not entirely a complete view. For example, sizeof() operator returns the declared size of an array. It seems that C recognizes the concept of an array.

Re: The Descent to C (2013)

#72

Post by kevin_thibedeau »

AceJohnny2 wrote: post #69
fsckboy wrote: post #49

Earlier quoted context omitted.

> left undefined, or were designed in a way to be easy to implement rather than easy to program for. I'd tweak your statement a little, or even a lot: "left undefined" most often meant "left to be defined by the compiler writers to fit the architecture of the underlying hardware, in a way that would make it easy to program to beneficially exploit features of the architecture"; and (yes) in a way "that would not be ve…

Sorry, you're absolutely right, and I was lazy in my comment. There is indeed a big difference between "undefined" behavior and "implementation-defined" behavior. For example, there's a lot of spooky "undefined behavior" around dereferencing pointers. In one famous case [1], dereferencing a pointer actually led the compiler to skip a later check on whether the pointer was NULL, because if the pointer was already dere…

16-bit chars still persist in DSP land. It is a tribute to C's flexibility that it can easily be implemented for such architectures.

Re: The Descent to C (2013)

#73

Post by arunc »

doctor_eval wrote: post #63
markhahn wrote: post #59

Surprise: there's a whole bunch of different reality under your the convenient illusions of your "high level" programming language. Hardware is the reality. It's not very much like the Java or Python programming model. We shouldn't hide this from programmers.

I disagree. C is also an abstraction of reality over assembly, assembly is an abstraction over machine code, which abstracts microcode, which abstracts over logic gates, and there are both deeper and adjacent abstractions as well. Underlying it all are different mathematical abstractions from karnaugh maps to quantum physics. A good developer will IMO select an abstraction that best matches their goals. If you’re wri…

In other words, hiding the complexity beneath

Re: The Descent to C (2013)

#74

Post by kaba0 »

munificent wrote: post #47
kaba0 wrote: post #45

Earlier quoted context omitted.

As per the somewhat famous blog post: C is not a low-level language. Especially on todays CPU’s I fail to see why would we consider C anything close to truly low level. It has no real way of managing cache, has absolutely zero support for vector instructions, etc. * With these in mind, Rust is lower and higher level than C at the same time. * other than some compiler specific pragmas, but I would be hesitant to call…

> Especially on todays CPU’s I fail to see why would we consider C anything close to truly low level. It's effectively the lowest you can go without throwing portability out the window. It doesn't let you manage caches directly, but it gives you good control over memory layout in general, and that's often enough to give you good cache usage across a variety of chips. If you want to go lower than that, you're probably…

I’m fairly sure that C++, Rust and Zig are just as much portable.

Any reason for not having native support for vector instructions?

Re: The Descent to C (2013)

#75

Post by pjmlp »

Animats wrote: post #51

It's not inherent in C being a low-level language that it has such a painful memory model. It's a consequence of having to fit the compiler into a really tiny machine by modern standards. Originally, there were no function prototypes. I once proposed a backwards-compatible way out for C.[1] Basically, you get to talk about arrays as objects with a length, even if that length is in some other variable. And you get sli…

By now it should be clear that WG14 doesn't care about improving C's safety.

A type like yours could be added, just like a string library like SDS, but it will never happen.

Re: The Descent to C (2013)

#76

Post by pjmlp »

AceJohnny2 wrote: post #48

> So why is C like this, anyway? Worth mentioning that C is over 40 years old, and was designed to be easily portable across a range of machines that had less compute power and memory than today's smaller microcontrollers. As a result, a lot of things were left undefined, or were designed in a way to be easy to implement rather than easy to program for . There existed other programming languages that were better, but…

C was created to port UNIX from PDP-7 Assembly into the newly acquired PDP-11, for the V5 port, and was for many years only available on UNIX.

Just those other languages were only available on their hosted OS.

The symbolic price for the license, availability of source tapes and the UNIX V6 annotated source code book made the rest.

Re: The Descent to C (2013)

#77

Post by pjmlp »

munificent wrote: post #47
kaba0 wrote: post #45

Earlier quoted context omitted.

As per the somewhat famous blog post: C is not a low-level language. Especially on todays CPU’s I fail to see why would we consider C anything close to truly low level. It has no real way of managing cache, has absolutely zero support for vector instructions, etc. * With these in mind, Rust is lower and higher level than C at the same time. * other than some compiler specific pragmas, but I would be hesitant to call…

> Especially on todays CPU’s I fail to see why would we consider C anything close to truly low level. It's effectively the lowest you can go without throwing portability out the window. It doesn't let you manage caches directly, but it gives you good control over memory layout in general, and that's often enough to give you good cache usage across a variety of chips. If you want to go lower than that, you're probably…

I go just as low level as C with Object Pascal, Basic, Modula-2, C++, Ada compilers.

Or by using any of the kids on the block from the last decade.

Re: The Descent to C (2013)

#78

Post by Zababa »

omegalulw wrote: post #64
Zababa wrote: post #55

Earlier quoted context omitted.

This is actually a really good way to drive home that arrays don't really "exists" in C and are just syntaxic sugar for pointer arithmetic.

"Because real programmers only need void*".

There's a language for that https://github.com/kyouko-taiga/void-lang

Re: The Descent to C (2013)

#80

Post by photojosh »

PEJOE wrote: post #9
globular-toast wrote: post #7

> No object orientation I feel like C exists at a level below such concepts. Simply being able to define a function `void do_stuff(struct mystruct *obj)` opens the door to object-oriented style programming. A lot of people seem to define OOP by the presence of superficial stuff like inheritance, polymorphism etc, but really those are additional concepts that aren't useful for every program. The real difference is mut…

That you can do functional or OOP in C does not make C either kind of language, it just means that C is flexible enough that you can make the computer do things the way you want it to, no matter what that means, and other languages purposefully prevent you from doing what you might want to do. C++ is object oriented not because it has compile time support for polymorphism or any of that other bad programming practice…

Yep, can definitely do OOP in C. Except over here in embedded land those structs don't live in the heap... but as globals (still referenced via pointers tho).

Was demonstrating the difference between inheritance and composition in OOP C to my junior dev just this week.

Post reply on HN