The C versus C++ debate

[Owen]

C++ can be a good choice if you're comfortable with the language, but it is pretty complicated. I think there has been a lot of FUD about the quality of C++ compilers, but I can tell you from experience that it is hard to write C++ that is truly portable between compilers unless you stick to a very limited subset of the language (and defining that subset will require experimenting with all the compilers). It may not be an issue if you're just going to pick one compiler for OS dev and stick with it, but if you ever want to switch compilers this may be a concern.

This is also a lot of FUD. Lets face it, all the compilers you care about are really good at C++03 and working on C++0X; the common subset is the vast majority of the language

(Of course, for kernel dev you probably want to avoid RTTI and Exceptions)

[Combuster]

This is also a lot of FUD. Lets face it, all the compilers you care about are really good at C++03 and working on C++0X; the common subset is the vast majority of the language

(Of course, for kernel dev you probably want to avoid RTTI and Exceptions)

Opinionated, contradictory, and just as much fodder as what you accuse Colonel Kernel of. Seriously, let's not start this.

[Owen]

This is also a lot of FUD. Lets face it, all the compilers you care about are really good at C++03 and working on C++0X; the common subset is the vast majority of the language

(Of course, for kernel dev you probably want to avoid RTTI and Exceptions)

Opinionated, contradictory, and just as much fodder as what you accuse Colonel Kernel of. Seriously, let's not start this.

Opinionated? Only if you believe ancient things like 1998's Visual C++ 6 are worth supporting.

Contradictory? Only if ignoring the portions of the language that require runtime support (and, in the exceptions case, don't play nicely with interrupts) somehow contradicts that the language is well supported by compilers.

I won't say that C++ support is perfect, or that it is bug free, or that you should use C++ above all else; but most of the pitfalls, these days, fall down to being the same issues as those for C.

Oh, and

• You will have to self-host your language of choice for OS dev. If you want to spend as little time as possible working on a run-time library to support your language, use C, and do not use Objective-C. Objective-C is a neat language for application development, but its runtime library is pretty big and its method dispatching mechanism is too slow for really latency-sensitive code like in the kernel.

I'm a C++ lover, and even I'll admit that these days Objective-C method dispatch is faster than a virtual call; of course, C++ non-virtual calls are still faster (but ObjC is very respectably fast)

[Colonel Kernel]

This is also a lot of FUD. Lets face it, all the compilers you care about are really good at C++03 and working on C++0X

Maybe so. My bad porting experiences are with compilers that I really, really didn't want to use (but had to because the customer required it). No, VC++ 6.0 wasn't one of them.

I'm a C++ lover, and even I'll admit that these days Objective-C method dispatch is faster than a virtual call; of course, C++ non-virtual calls are still faster (but ObjC is very respectably fast)

I would be surprised if an ObjC message send is faster than a C++ virtual call, even on a hot method cache... That said, I should have been more specific. My concern would be with the worst-case time, not the average time. In the worst case, a linear search is required to find the right method to call. I wouldn't want that anywhere in the hot spots of a kernel. If you're building a monolithic kernel, then sure, there are lots of places you could use it without a problem. Just don't do it in an interrupt or exception handler.

This is, of course, bullshit.

Take it easy. You can disagree, but do it politely or you ruin the quality of discussion for everyone.

objc runtime is more complex than that of C, but it is not slow and not too complicated to be able to implement it in the kernel.

Maybe not too slow (see above), but in terms of complexity, that's up to the individual. For some people (like me, and probably the OP), it wouldn't be worth the effort to implement when simpler alternatives are available.

The point I was trying to address was this one:

If I follow that reasoning, would it be worthwhile to program an OS in Objective-C which could be a mid-point considering it is smaller than C++ but still get the advantage of OO programming?

Objective-C may be smaller than C++ in terms of syntax and features, but not in terms of the size of the run-time library.

[Candy]

C++ is a slightly problematic beast, because you will need to know very well what you are abstracting and what interfaces are exposed and do a lot of damage control just to write your basic stuff.

Somehow I haven't done that at all, and I still have a C++ kernel (with use of virtual methods, pure virtuals, singletons, factories and the lot) that runs on x86 with a fair set of features.

[Combuster]

This is also a lot of FUD. Lets face it, all the compilers you care about are really good at C++03 and working on C++0X; the common subset is the vast majority of the language

(Of course, for kernel dev you probably want to avoid RTTI and Exceptions)

Opinionated, contradictory, and just as much fodder as what you accuse Colonel Kernel of. Seriously, let's not start this.

Opinionated? Only if you believe ancient things like 1998's Visual C++ 6 are worth supporting.

Contradictory? Only if ignoring the portions of the language that require runtime support (and, in the exceptions case, don't play nicely with interrupts) somehow contradicts that the language is well supported by compilers.

I was just syntactical here. I actually do use VC6 since it doesn't blow up 30% of my harddrive on which I didn't install it, like the all the later VSes do.

Also the bits of C++ that "reliably" work across "the real" compilers, minus RTTI, minus Exceptions = vast majority of C++ features, or even, all of C++ minus RTTI and exceptions = vast majority? What makes C++ over "C with classes"?

If you don't mind, I'd like to be short and blunt when someone starts a language war in an thread where its offtopic, especially when he/she can't stick to facts.

[bewing]

As far as the language war goes:

If you ignore all the airy hypothesizing that goes on, and simply attempt the following in reality --

if you have an app to design (such as a kernel), and you have some decent programmer code it up in pure ASM, perhaps you will find that the final size of the executable is 4K, and it runs in 1 second.

If you take precisely that same app design, and you have some decent programmer code it up in pure C, you will almost certainly find that the final executable size is 40K, and it runs in 2 seconds.

If you take precisely that same app design, and you have some decent programmer code it up in C++, you will almost certainly find that the final executable size is 400K, and it runs in 4 seconds.

And spare me the "but C++ is just a superset of C, so they are always theoretically identical" BS. Not in reality, they aren't.

The standard OO programming practices (code reuse, designing new code blobs to be reusable, dynamic memory allocation and fragmentation, etc.) cannot help but lead to code bloat.

[skyking]

And spare me the "but C++ is just a superset of C, so they are always theoretically identical" BS. Not in reality, they aren't.

If that's what happens in reality then the decent programmer should not be doing kernel programming, at least not in C++. If you're going to write in C++ you should be good enough to understand and anticipate what the compiler does to your source code and in that case you should not get this performance/bloat problem.

[gravaera]

if you have an app to design (such as a kernel), and you have some decent programmer code it up in pure ASM, perhaps you will find that the final size of the executable is 4K, and it runs in 1 second.

If you take precisely that same app design, and you have some decent programmer code it up in pure C, you will almost certainly find that the final executable size is 40K, and it runs in 2 seconds.

If you take precisely that same app design, and you have some decent programmer code it up in C++, you will almost certainly find that the final executable size is 400K, and it runs in 4 seconds.

And spare me the "but C++ is just a superset of C, so they are always theoretically identical" BS. Not in reality, they aren't.

Bewing, this is wrong on so many levels...

Suffice it to say that hand-coded ASM vs optimizing compiler generated code tend to be comparatively the same in performance, or at least where handcoded code does offer better performance, the HLL code is more portable, and easier to maintain, as well as much more extensible. More importantly, since when does the number of machine instructions needed to complete a sequence diminish due to the HLL language you use?

Give a C and a C++ programmer the same program to code and given that they both come up with the same design and algorithm, and their understanding of their respective languages is optimal and they write condensed well thought out code, and the compilers used are equivalent in their optimizing powers, the executable will be about the same size in both cases, and certainly not double the size, or even 1.5x.

And give the ASM programmer the same thing to do with the same assumptions of skill and understanding and you get a bunch of shaved cycles due the fastest opcode possible for every sequence, the same functionality, and some hard-to-understand nonsense that nobody is ever going to maintain, and should it ever need to be ported would be completely useless, and given the assumption that the HLL programmers' compilers were very good at optimizing, the ASM coder's executable isn't going to be much smaller at all. I wasn't aware that using ASM somehow inherently compressed the opcodes and cut corners such that you could miss out instructions in a necessary sequence and still get the same sequence.

And also, the "C++ is a superset/derivative of C" thing is only ever used by bad C++ coders. From the time you hear people saying that, you can assume that they *think* they know C++, but have no idea what they're doing at all.

And,

The standard OO programming practices (code reuse, designing new code blobs to be reusable, dynamic memory allocation and fragmentation, etc.) cannot help but lead to code bloat.

I never thought I would hear someone tell me that dynamic memory allocation was a principle of object oriented programming.

C++ is an excellent tool in the right hands. End of story.

--Pointless ignorant argument is pointless and ignorant.
gravaera

[Candy]

If you take precisely that same app design, and you have some decent programmer code it up in C++, you will almost certainly find that the final executable size is 400K, and it runs in 4 seconds.

Decent programmers aren't good at c++. Get a decent C++ programmer - no, they're not easy to find.

And spare me the "but C++ is just a superset of C, so they are always theoretically identical" BS. Not in reality, they aren't.

Show me a non-pathological case where any given C construct can't be compiled in c++ mode.

Pathological cases are things like

Code: Select all

 int class; 

Code: Select all

for (int i = 0; i < 3; i++) {} for (i = 0; i < 3; i++) {}

The standard OO programming practices (code reuse, designing new code blobs to be reusable, dynamic memory allocation and fragmentation, etc.) cannot help but lead to code bloat.

"cannot help but"... sounds like a load of crap. They're tools. Use the wrong tool at the wrong place and you'll mess up. C++ just gives you more tools; there's more ways to abuse it but also better solutions to be gotten.

And also, the "C++ is a superset/derivative of C" thing is only ever used by bad C++ coders. From the time you hear people saying that, you can assume that they *think* they know C++, but have no idea what they're doing at all.

Wow. Thanks!

I'll let my intermediate project speak for itself. It's called Hippomocks & lets you do with C and C++ what you considered illegal and impossible. Now call me a bad C++ coder again.

[MDM]

In my own limited experience with C++, its much slower than C, and at least 100X uglier. If you can write a fast kernel in C++ kudos to you, but I'd really much rather just stick with C/asm.

I love Obj-C, but I'd never consider it for kernel development, its runtime is rather large, and I think it'd be a pain to get up and running.

[Combuster]

You assembly programmers have proven to be immature en masse, You C programmers have proven to be immature just as well, and you who call themselves C++ programmers are no different. Haskell is the only good language because it needs no comparison.

Amazing how Language A > Language B can turn this place into a dysfunctional nursery.

[fronty]

Haskell is the only good language because it needs no comparison.

I just found this new language called "LISP". Could you provide comparison between these two? :p

[tharkun]

Haskell is the only good language because it needs no comparison.

I just found this new language called "LISP". Could you provide comparison between these two? :p

Which lisp? Scheme, Common lisp, Clojure or Emacs lisp?

Lisp is a variety of languages all based on S-Expressions, Haskell on the other hand is a single purely functional programming language with significant whitespace. Most lisp dialects have advanced macro capabilities, common lisp has a feature called reader macros, these allow you to change the parsing rules for specific constructs in a language allowing conversion from other languages to lisp at read time.

Haskell is a purely functional programming language, input and output is done through monads. It's pattern matching for functions rivals lisps macro capabilities. Lazy evaluation and type inference are major features of the language, for example this codes creates and infinite list of all the fibonacci numbers (taken from wikipedia because I'm too lazy to write my own)

Code: Select all

fibs = 0 : 1 : zipWith (+) fibs (tail fibs)

Lisp and Haskell are two very different languages, both are functional programming languages, but suited for different tasks.

[fronty]

@JoeDavis: I am very familiar with different types of LISPs from both user's and implementor's view (which aren't very far from each other in LISP world) and quite familiar Haskell. You should be careful when answering to a tongue-in-cheek message which itself was a response to such message.