The "case" and "default" overrides seem kinda dicey.
Yup. Congratulations kid. You broke fall-through, perhaps the biggest advantage of a switch over else-ifs.
22nd Century C
31–40 of 106 posts
Re: 22nd Century C
#32Too little too late. Rust is already taking over, by the 22nd century C will be dead.
I don't know what the systems programming language of the 22nd century will look like, but I do know that it will be called C.
On UNIX yes, it will never change, C is married to UNIX and no alternative will ever change that.
On other OSes, it really depends on how Apple, Google and Microsoft do their work of "our way or the highway" regarding pushing their safe alternatives.
Re: 22nd Century C
#33Earlier quoted context omitted.
Looks like you haven't worked on embedded systems. We need to be very careful with sizes of ints here. Not just because we run the risk of overflows, but also because when we create code that may have to be ported from one architecture to another, we want to minimize re-work. > Notice how smooth the 32-bit to 64-bit transition went? There are many reasons for that. For most PC work, a 32-bit int is more than large en…
I work with embedded systems daily, writing code that is expected to work on multiple different architectures (e.g. systems where char is 8-bit, 16-bit, 24-bit or 32-bit, systems without floating point units, systems with SIMD instructions, systems without, etc). In doing this, I have found that fixed width types make the job harder, and any code that uses fixed width types is generally more difficult to work with. Y…
> How do you port it to a machine without a 16-bit type?
The problem is made more severe when you use "int" and let the compiler decide the size of the variable. I guess I don't know what you're advocating.
> The stuff about communicating with the outside world is quite different.
I meant communicating as a throwaway example. It's a valid example, but really, everything gets affected. For example, a CAN identifier is 29 bits. What generic "int" would you use when you want to fill in this identifier? And no, I work at a level that's lower than an ABI. So, no OS, no file IO, etc.
Re: 22nd Century C
#34Maybe the author wanted this to be C99 compliant but a cool thing is that by using clang we even have lambdas. It's called blocks, the same as in Objective-C.
http://clang.llvm.org/docs/BlockLanguageSpec.html
I've been using them in all my new C code, since I'm stuck to clang anyway, and it's awesome.
Re: 22nd Century C
#35Earlier quoted context omitted.
Looks like you haven't worked on embedded systems. We need to be very careful with sizes of ints here. Not just because we run the risk of overflows, but also because when we create code that may have to be ported from one architecture to another, we want to minimize re-work. > Notice how smooth the 32-bit to 64-bit transition went? There are many reasons for that. For most PC work, a 32-bit int is more than large en…
I work with embedded systems daily, writing code that is expected to work on multiple different architectures (e.g. systems where char is 8-bit, 16-bit, 24-bit or 32-bit, systems without floating point units, systems with SIMD instructions, systems without, etc). In doing this, I have found that fixed width types make the job harder, and any code that uses fixed width types is generally more difficult to work with. Y…
You have an int16_t? How do you port it to a machine without a 16-bit type?
Hint: you're being done a favor by being forced to think about that.
Re: 22nd Century C
#36Earlier quoted context omitted.
I don't know what the systems programming language of the 22nd century will look like, but I do know that it will be called C.
On UNIX yes, it will never change, C is married to UNIX and no alternative will ever change that. On other OSes, it really depends on how Apple, Google and Microsoft do their work of "our way or the highway" regarding pushing their safe alternatives.
When you consider how truly distant into the future -- in technological time frame -- 2100 is, you can wonder if Unix will even be around at that time. 2100 is double the lifetime of Unix from now.
Re: 22nd Century C
#37Earlier quoted context omitted.
I work with embedded systems daily, writing code that is expected to work on multiple different architectures (e.g. systems where char is 8-bit, 16-bit, 24-bit or 32-bit, systems without floating point units, systems with SIMD instructions, systems without, etc). In doing this, I have found that fixed width types make the job harder, and any code that uses fixed width types is generally more difficult to work with. Y…
> How do you port it to a machine without a 16-bit type? The problem is made more severe when you use "int" and let the compiler decide the size of the variable. I guess I don't know what you're advocating. > The stuff about communicating with the outside world is quite different. I meant communicating as a throwaway example. It's a valid example, but really, everything gets affected. For example, a CAN identifier is…
How does it make portability worse if you write your code in a way that doesn't assume anything about the size of your ints? If you don't know that your ints are 16 or 32 or 27 bits long you have to be more careful with checking for overflows, but if the code does that I don't see what problems you'll have when you port it to a platform with a different int size.
Re: 22nd Century C
#38Earlier quoted context omitted.
On UNIX yes, it will never change, C is married to UNIX and no alternative will ever change that. On other OSes, it really depends on how Apple, Google and Microsoft do their work of "our way or the highway" regarding pushing their safe alternatives.
When you consider how truly distant into the future -- in technological time frame -- 2100 is, you can wonder if Unix will even be around at that time. 2100 is double the lifetime of Unix from now.
C already survived 44 years, so only 84 to go :)
Re: 22nd Century C
#39I'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 and distributed 15 years ago.
Re: 22nd Century C
#40I'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…
I've heard Microsoft had a great story there, but I was drawing from experiences with the open source Unix-likes. Seems like it was across the board until you get too far into the weeds.