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

22nd Century C

procedural.github.io

Post reply on HN
Print view View original

61–70 of 106 posts

Re: 22nd Century C

#61

Post by cyber_dude »

user5994461 wrote: post #39
mieko wrote: post #9

I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…

> Notice how smooth the 32-bit to 64-bit transition went? (and yes, it was smooth.) I credit most of that to Microsoft and the insane efforts they make to support backward compatibility. They made an extremely complex abstraction layer to run 32 bits applications on 64 bits OS, yet it works very well. To this day, it's possible to run lot of applications that were written 15 years ago, seamlessly, as they were built…

You should credit AMD for introducing AMD64/x86_64. Without that backward compatibility wouldn't have been possible.

Re: 22nd Century C

#62

Post by andrioni »

gcr wrote: post #60
tbirdz wrote: post #30

Earlier quoted context omitted.

I completely agree with you when it comes to function return types. For data structure fields, especially structs used many, many times like in very large arrays, I'd say it's sometimes worth using fixed size types to get better control over memory use. Using a 64-bit int for a field a 16-bit integer can handle will use up 4x as much memory. And if you've got a ten or a hundred million structs of that type, then it r…

I strongly disagree with your sentiment. If you wrote an application that's as efficient as possible without any wasted bits in the size_t type, it then only works on your machine. If I wanted to run such an application on my supercomputer with 2TB of RAM (such machines exist), I would then have to recompile for a 41-bit size_t. We use machine-neutral (but architecture-specific) size_t for these kinds of things expli…

2TB of RAM isn't close to a supercomputer nowadays, you can even get one of those at AWS now (the appropriately named x1.32xlarge instance).

Re: 22nd Century C

#64

Post by dahart »

mieko wrote: post #9

I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…

I was working in console games during the 32->64 transition, and watched our game engine code suddenly go crazy with data size specificity.

It was a little weird. I don't know whether it's good or bad overall, but there was definitely a reason for it, the need was clear. Suddenly you didn't know how big an int was, and that matters a lot when you're sending ints over the network and stuffing ints into save games, and it matters a lot when you use an int expecting 64 bits, but you're still compiling code for a Wii and only get 32. It matters for multiply overflows and negative numbers and bit flags and for a bunch of things besides deciding how high your for loop will go or what your largest return value is.

As you say, very few people want to decide what size to use when declaring functions. But everyone wants to know exactly what to expect. If you do declare something and don't actually know what size it is, you have a real problem that can and will lead to crashes.

> Notice how smooth the 32-bit to 64-bit transition went?

I'm not certain, but is it possible it went smooth because everyone working in C/C++ started paying attention to their data sizes?

As a user of Ruby/JS/Python, it would be worth checking what happened to the source code for the interpreters of those languages. When you program in them, yes, you're buffered from a lot of data size issues, but the internals of the languages themselves may be just as fixed-size centric as anything.

Re: 22nd Century C

#65

Post by ci5er »

TickleSteve wrote: post #46

this is basically an updated version of iso646.h [ https://en.wikipedia.org/wiki/C_alternative_tokens ] ...and no, they're not a good idea, its just a syntactic change. If you want a 'better-C', language-wise, Rust is pretty much best current hope, tho that wont mature for another decade or so.

Really? I haven't had a chance to dig into it and a quick google-based look-see didn't pop up immediately obvious results, but I would have thought that two areas where one would want to use C would include specific bit manipulation and explicit memory management. Both of those violate the high-level principles that I thought Rust was supposed to be about. So, either I was wrong (which happens more and more these days), or Rust has a work-around, or it's not a good fit for that last bastion of C use-cases.

Thoughts?

Re: 22nd Century C

#66

Post by PieterH »

pqhwan wrote: post #5
em3rgent0rdr wrote: post #3

I don't get it. Could someone summarize/explain this.

I'm only guessing, but it looks like a C header file with a set of macros that produces neat-looking C code. Not sure what's the deal with the 22nd century thing.

It's a clever joke and rather cynical deconstruction of our industry. The author suggests that in 100 years the C language will not only still exist and be widely used, it will have advanced almost nothing at all due to the industry's inability to solve real problems and instead focus on virtue signalling languages such as Clojure and Ruby. The author hammers home his point by demonstrating how a simple header file can at once render the code unreadable, while adding absolutely no value at all. I think he or she is specifically talking about Silicon Valley here, though of course since the joke is expressed in code, one can only guess.

Seriously, I'd hope in 2100 we'd have pushed our systems languages beyond facile keyword redefinition. Maybe even towards concurrency and an actor model. Like I explored in my unfinished (sorry, shit happened) book "Scalable C".

Or, Rust.

Re: 22nd Century C

#67

Post by Cyph0n »

karyon wrote: post #58
mieko wrote: post #9

I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…

For a university project I programmed for an Arduino Uno (ATmega328P). Debugging performance problems, we found out that a switch (implemented with a bunch of if/else ifs) with about 12 branches used ca. 200 clock cycles just checking the 12 conditions. Turns out the ATmega328P has only 8bit registers and the ALU operates on 8bit values. We were using 32-bit datatypes in the conditions, which the ATmega328P loaded an…

Whenever I write ATmega32P code, I add the following to a header file:

>> typedef unsigned char uint8;

And then I use uint8 by default (loop counter, accumulator, constant, etc.), unless a larger size number is required.

Re: 22nd Century C

#68

Post by lake99 »

TheNewAndy wrote: post #59
lake99 wrote: post #54

Earlier quoted context omitted.

> Take some correct code that works with int16_t, and replace the "int16_t" with plain "int". What breaks? Memory. Defaulting to 16-bits when an 8-bit variable will do can be incredibly wasteful on an 8-bit µC. Keep in mind that we are not just talking about one variable in isolation. We are talking about all the integers we pass between functions. We are talking about code space, data space, and stack space. There a…

> Memory. Defaulting to 16-bits when an 8-bit variable will do can be incredibly wasteful on an 8-bit µC. I hope it doesn't seem like I'm just moving the goalposts, but the obvious answer here is to use a type which is at least 8-bits wide if you only need 8-bits. Such a type exists, and is called "char" (with the appropriate signedness modifiers). This whole discussion has been about writing portable code. Using a "…

I did not expect you'd say "char", because it's a fixed size numeric type. Isn't that what you have been arguing against so far? Anyway, I'd get yelled at if I checked in code where I do math on char. It has to be on uint8 or int8 (or other widths). Not that I'd ever check in such code, after all, I agree with the company policy there. But "char" is just a part of the problem. We have the same issue with all kinds of bid-widths. When I read PC code with such names, I don't worry about their sizes, and just assume i386 conventions. When I read embedded C code with datatypes of undeclared widths, I get quite annoyed. Thankfully, I can't recall the last time I read such code.

> then uint_least32_t should make you happy

The thing is, I assume all uintX types to really mean at least X bits wide. I am aware that the compiler is free to use its discretion for allocating memory. I worry about finer details only when I need to.

Re: 22nd Century C

#69

Post by mieko »

dahart wrote: post #64
mieko wrote: post #9

I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…

I was working in console games during the 32->64 transition, and watched our game engine code suddenly go crazy with data size specificity. It was a little weird. I don't know whether it's good or bad overall, but there was definitely a reason for it, the need was clear. Suddenly you didn't know how big an int was, and that matters a lot when you're sending ints over the network and stuffing ints into save games, and…

> I'm not certain, but is it possible it went smooth because everyone working in C/C++ started paying attention to their data sizes?

We don't have to guess. A huge amount of the code that made this transition was strewn across the internet in CVS and SVN repos, and now in preserved git history. From compilers and libcs to kernels to linkers, loaders and interpreters. They make concessions where they had to (check out glibc), but stay with traditional K&R-style types when possible. The "i32 calculate_age()" thing is way newer than that.

Re: 22nd Century C

#70

Post by trentnelson »

user5994461 wrote: post #39
mieko wrote: post #9

I've spent two decades writing C and C++, but the last 8-9 years in really high-level languages (Ruby, Javascript, Python). From either end of the spectrum, I've never felt the need for such emphasis on fixed-sized numeric types. I've commonly needed access to fixed size numerics, like when sending texture formats to the GPU, defining struct layout in file formats and network protocols, but I have never once thought:…

> Notice how smooth the 32-bit to 64-bit transition went? (and yes, it was smooth.) I credit most of that to Microsoft and the insane efforts they make to support backward compatibility. They made an extremely complex abstraction layer to run 32 bits applications on 64 bits OS, yet it works very well. To this day, it's possible to run lot of applications that were written 15 years ago, seamlessly, as they were built…

A great paper if you haven't already seen it:

https://github.com/tpn/pdfs/blob/master/A%20History%20of%20M...

Post reply on HN