Thread: Is Visual Studio C or C++

Originally Posted by laserlight

The canonical case of what Elysia is talking about is the passing of a function object as a predicate to std::sort, as opposed to passing a function pointer as a predicate for qsort. The function object is cheap to copy since it usually does not even have any member variables, thus there is no penalty in doing a deep copy. However, apparently the compiler is able to perform optimisations with the function object that it cannot do with a function pointer.

I see. I wasn't aware of that.

I too think an operating system should be written in a procedural language like C. Writing an OS in assembly would be quite fast, but it would be nearly impossible to maintain; and writing an OS in an object-oriented language is likely going to result in abstractions which are appropriate in other types of software but in an operating system just slow everything down unacceptably.

Originally Posted by sean

I'm a big fan of a recent Linus Torvalds quote, which I'll have to paraphrase until I can find the real quote: "C isn't a good programming language - it's just a way to write portable assembly"

I don't know how to program in assembly, but I often come to similar conclusions (i.e. dealing with the actual RAM addresses instead of an abstract string object) and that is one of the reasons I like it.

Originally Posted by sean

edit: Found the quote, it's on the most recent update to Linus's blog: "Some people seem to think that C is a real programming language, but they are sadly mistaken. It really is about writing almost-portable assembly language,"

Linus has a BLOG !??! OMG where?!!

I don't know ASM either but this makes tremendous sense to me. AFAICT C is the "lowest level" language in widespread use, and that's probably why it's in widespread use. Logically, I think it must occupy a privileged position in the sense that there is not a viable alternative*: like translating a spoken language, there is some ambiguity, but generally speaking, dealing with the level of the phrase, there are not that many ways to skin a cat.

Since C has remained fairly minimal, where you go from there is completely up to you and probably a lot of work. Again, it seems logical to me that if you take away someone's generisized String method or whatever, they will have to write custom handlers at a byte level, and the payoff is that this will be (logically) the most optimal way to approach a particular task, altho it may or may not help with other similar and dissimilar tasks.

* except something that is exactly the same, which my sense is doing low level work in C++ is more or less (or exactly) the same as doing it in C.

Originally Posted by MK27

Linus has a BLOG !??! OMG where?!!

I'll give you a hint. If you do a google search for "Linus Blog", it is the first search result.

Originally Posted by MK27

I don't know ASM either but this makes tremendous sense to me. AFAICT C is the "lowest level" language in widespread use, and that's probably why it's in widespread use. Logically, I think it must occupy a privileged position in the sense that there is not a viable alternative*: like translating a spoken language, there is some ambiguity, but generally speaking, dealing with the level of the phrase, there are not that many ways to skin a cat.

Since C has remained fairly minimal, where you go from there is completely up to you and probably a lot of work. Again, it seems logical to me that if you take away someone's generisized String method or whatever, they will have to write custom handlers at a byte level, and the payoff is that this will be (logically) the most optimal way to approach a particular task, altho it may or may not help with other similar and dissimilar tasks.

* except something that is exactly the same, which my sense is doing low level work in C++ is more or less (or exactly) the same as doing it in C.

Exactly what I'm thinking.

Originally Posted by MK27

You are probably right, but the fact that Symbian is written in C++ is not "evidence" one way or the other; the context is not related.

People have written operating systems in perl, .NET, and python, but for obvious reasons, it would ridiculous to write a kernel that way. Or maybe not, since AFAICT those OS's used a custom kernel with interpreters built into them.

Anyway, I would guess for certain a kernel could be written in any compiled language. Why not? Of course, some person(s) would have to actually do it, and that person would have to choose a language, and the "logical" choice would probably be whatever that person prefers.

I agree. The fact that it has been written in C++ only indicates that it may be possible, but is in no way a proof by itself. Kernels are so complex by nature that proof would require extensive tests and analysis.

Originally Posted by abachler

I agree it can be done (I've done it). I guess I should have said, the Linux kernel does nto lend itself to being well written in C++. Mostly because of the portability issue but also because of the design choices made during its development. Could you write the thread scheduler as a class, sure, but why would you rewrite a piece of code that is already optimized and functional unless you could squeeze extra performance out of it. If you make each thread an object then the assumption is you will dynamically allocate the objects rather than simply have a predefined array for thread entries. Which entails an extra pointer calculation as you index into the array of thread objects, and then have to index into the object to retrieve the actual information. I think its instances like this that the C programmers are talking about. Is an extra index that computationally expensive? Not really. Can it be done, yes, does it reduce performance at all, yes it does. Does the fact that it reduces performance, however minuscule the amount, conflict with their policy of absolute speed above all other considerations, definitely. You are talking about an area of the system that can bog down everything. If a solution in C++ was somehow faster than the best possible solution in C, then I'm sure they would (grudgingly) accept and use it. The primary reason for the stonewalling of C++ on items where it is just as fast, but no faster is the correct assertion that once they let C++ programmers in it creates design requirements that are not easy to remove. C is also much closer to the hardware than C++. Most language features in C translate directly into a single assembly instruction, while C++ features do not.

You do seem to point out the fact why the kernel isn't (re)-written in C++. Indeed, it provides little or no performance benefit to the current code, so there's usually no need.
However, I don't think they would accept C++ code even if it was was faster. I haven't looked at the kernel source, but I assume they would use function pointers somewhere. C++ functors, for example, are faster, but I don't think we'll see them in the kernel anywhere.