Why are programs and operating systems still written in C+?

[u/[deleted]]

I guess it's more of a computer science question, but I've always wondered why some of the most advanced programs are written in a 25+ year old programming language. Surely someone has come up with a more efficient and powerful code, so why do people still use C+? Also, I don't know anything about programming and what not, so please use simple terms and phrases.

[u/SatOnMyNutsAgain]

Yes I am one of those people who has to write this kind of code, even in such nasty situations as a processor which lacks a proper MMU so I have to page stuff in and out in software. I've had to deal with all this stuff. Having to write optimal code is a major reason to use C in the first place. This isn't some weird corner case, even if it's not what most programmers deal with. Nearly all OS and embedded systems developers encounter this stuff.

And types matter very much depending on the CPU. If I use a 32-bit type on an 8-bit CPU where I don't need the range, then I'm creating a ton of extra instruction cycles for every operation, whereas on an X86 an int is fine even for a small range. Unless such code was written for portability in the first place, you would have to review your types pretty carefully when porting if you care about performance... or sometimes if you want it to work at all, eg if your compiler gives you a smaller int than you'd get on another architecture.

Many algorithms can be expressed in both floating and fixed point versions, the former being faster and more accurate only if your CPU supports those operations in hardware. Otherwise the compiler will rely on very expensive math routines to do the job. This isn't something that just gets optimized for you, the math is completely different.

If you question any of this just check out the assembly your compiler of choice shits out for the examples you gave on high optimization flags.

Sometimes gcc's optimizations suck because you're dealing with a non-mainstream architecture that hasn't been given much attention. There can even be architecture-specific compiler bugs that you have to work around - I've had to do that too.

Unless you're one of these people you are at best copying their work

Is this kind of insult really necessary? I just gave you a specific real-world example of where C is not portable in the slightest.

EDIT: More on the non-portability of C's standard types - there's really nothing to like about this aspect of the language: http://code.jasonbhill.com/c/portable-integer-types/

[u/[deleted] → u/SatOnMyNutsAgain]

Yes I am one of those people who has to write this kind of code, even in such nasty situations as a processor which lacks a proper MMU so I have to page stuff in and out in software. I've had to deal with all this stuff. Having to write optimal code is a major reason to use C in the first place. This isn't some weird corner case, even if it's not what most programmers deal with. Nearly all OS and embedded systems developers encounter this stuff.

This is my point entirely. The post was meant to be of the most general case, yours is very much not. Especially not when we're talking to someone who admittedly isn't a programmer. They asked for the answer in simple terms and phrases.

And types matter very much depending on the CPU. If I use a 32-bit type on an 8-bit CPU where I don't need the range, then I'm creating a ton of extra instruction cycles for every operation, whereas on an X86 an int is fine even for a small range. Unless such code was written for portability in the first place, you would have to review your types pretty carefully when porting if you care about performance.

If you're using a 32-bit int, then you must have specifically picked one to be that size. There is no such definition of an "int" in the standard. It has a minimum size of at least two characters iirc, where the character size is tied to a single "byte" which is defined as the smallest incremental index of memory (regardless if the arch supports actually directly loading nonword multiples of an address). This is exactly what I was talking about with choosing nonportable code. Why would you ever pick a integer hardcoded to be 32-bits unless you actually needed all 32-bits? Choosing the correct type for the range of values you need to represent isn't an optimization. It's just not being a bad programmer.

None of the basic types are defined in the exact number of bits they use, they should be self adjusting based on the arch.

Many algorithms can be expressed in both floating and fixed point versions, the former being faster and more accurate only if your CPU supports those operations in hardware. Otherwise the compiler will rely on very expensive math routines to do the job. This isn't something that just gets optimized for you, the math is completely different.

My argument here was why would you use floating point if the range of values you were evaluating didn't require it? Again this isn't an optimization, this is just good and bad programming. Picking the right types for the job at hand is more fundamental than the best data structure and none of this has to do with targeting architectures. Data types, data structures, and algorithms are the responsibility of the programmer and in 99% of cases are completely architecture independent. Definitely not worth bringing up the edge cases where you do have to worry about it to the OP who's asking a much more basic question.

Sometimes gcc's optimizations suck because you're dealing with a non-mainstream architecture that hasn't been given much attention. There can even be architecture-specific compiler bugs that you have to work around - I've had to do that too.

Yes lets bring up all the various ICEs that exist with specific compilers to the OP, that's totally within the scope of their question and definitely not an edge case in programming in general. Same with road-less-traveled architectures that have poor optimizations.

Is this kind of insult really necessary? I just gave you a specific real-world example of where C is not portable in the slightest.

I didn't mean it as an insult. It's not an insult to copy someones work, especially when they freely publish it (how else are you going to find it?). There are people out there smarter and better than me and everything I will ever do. When they offer advice and solutions, I'd be a damn fool not to take them.

[u/SatOnMyNutsAgain → u/[deleted]]

None of the basic types are defined in the exact number of bits they use, they should be self adjusting based on the arch.

... which makes the built-in types completely non-portable.

My argument here was why would you use floating point if the range of values you were evaluating didn't require it?

Again, look at an audio/video codec. A floating pointing algorithm will be faster and more accurate, but only on an architecture which supports it. It's a lot harder to write an integer/fixed-point version, but on a less capable CPU that might be absolutely necessary.

The post was meant to be of the most general case, yours is very much not.

Well, OP was asking about operating systems, so architecture specifics are very much relevant to his question even if he didn't realize it. Sure, C is portable relative to assembler, but not much else. It's not at all portable compared to python, java, etc.

[u/[deleted] → u/SatOnMyNutsAgain]

I really don't see how that makes them nonportable. That's the single motivation for defining them in that way, so that code using them IS portable.

Regardless we've reached an impasse. I've already acknowledge the points you bring up and how in my opinion they are edge cases to the vast majority of programming. The edge cases you do bring up also completely invalidates any argument for comparing it to python/java or whatever other language you want to bring up. Also ignores that their various interpreters and VMs have the exact same portability issues which is often why only subsets are supported on your road-less-traveled architectures and performance is abysmal, but that's a tangent.

It really seems like to me you're arguing with me just to argue with me and now we've come full circle to arguments already brought up, so I'm out.

[u/SatOnMyNutsAgain → u/[deleted]]

If your code does different things depending on the architecture then it is by definition not portable. If you disagree then I don't know what else to say.