The C versus C++ debate

[tharkun]

@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.

Apologies, I'll admit I had only skimmed through the thread, only noticing the tounge in cheek after I'd posted.

[tharkun]

Straight from the OSDev wiki: Kinetic and Lighthouse

[Ready4Dis]

Well, from someone who wrote a 32-bit multitasking virtual memory, OS with hd, fd, fs, vesa, mouse and keyboard drivers. Then re-wrote it in C for portability reasons, while adding a bit of functionality, and currently helping work on an OS with (very limited so we don't get to much bloat) C++, I can break it down like this:

ASM - Was much smaller, the entire kernel + driver set was 8kb.
C - Much more portable, and easier to write in, kernel size grew pretty quickly (but, also has a lot more features and is more easily extended). For example, my C kernel has a linker built in, and dynamically links drivers against the kernel in kernel space (monolithic). Every driver is a loadable module at runtime. ASM, I had a function call list rather than dynamic linking, so it wasn't as nice of a solution and required even more work on the developers end.
C++ - We aren't useing a lot of advanced stuff, but it does make the project cleaner (we're using namespaces, etc to keep things seperate), our second stage loader is larger than my first ASM kernel, and almost as large as my C kernel, athough it does a ton of setup code, so the kernel can just do what it should do, and that's pass messages and give out time slices for the most part.

Which one is best? I don't know, depends on your goals really. ASM is not as bad to work with, and not as horrible to maintain as people wish you to beleive. If you know how to code and indent, and comment, it's really not hard to follow unless of course, you don't know the langauage. So, those of you saying ASM is hard to read/write simply talk from inexperience. It's not portable, and it does take longer to write code. C is easier to write code, easily extendable, and portable. It's not as fast as GOOD assembly (and there is a difference between someone that 'knows' assembly, and someont that's good at assembly), but the benefits you gain from code readability, speed of using structs, etc and the portability make up for it in some cases. If you're OS desig is one of those cases, then there you go. C++ - Similar to ASM, there are people that 'know' C++ and those that are good at C++. Being good means knowing what the compiler is actually doing, thereby being able to avoid specific downfalls. It is VERY easy to get bloat with C++, much easier than any of the other 2 mentioned langauges, however that doesn't make the langauge itself bad, just the people who abuse it. It's by far the fastest to develop in, very portable (i haven't had any issues between any of the C++ compilers, although I tend to avoid very high level constructs to avoid that afformentioned bloat).

Anyways, this is my take, I've worked with all 3, however like I said, we're only using a very small subset of the C++ langauge, so we don't really see the downsides that have been mentioned earlier.

[Solar]

IMHO the main problem with C++ is that it's much more similar to languages like Java. There are many very, very mediocre programmers working in Java (or other "RAD"-hyped languages, simply because the demand of the industry far exceeds the supply of skilled individuals), and when one of those switches to C++, it results in some of the most awful, bloated, ugly, and ineffective C++ code you could imagine. Simply because C++, while looking similar at first glance, works so much differently.

Such a RAD-type coder would never touch C or ASM with a ten-foot pole, but he jumps at C++ and (falsely) feels confident.

It is my belief that much of the "bad press" that C++ got and still is getting is coming from such people who thought that C++ is, or should be, another RAD-type language, and got bitten in the backside. C++ adds many features to C, features aimed at large projects and complex frameworks. Features that are easily abused.

As such, C++ sits squat in the middle between C and Java. Both these languages are comparatively easy to learn. You can get away with mediocre people on the team, because they can't really screw up that bad. C allows you to build effectively and bites you early when you screw up, Java allows you to build big and is easy to refactor when you got it wrong. C++ allows you to do big things effectively, i.e. best of both worlds, but you need quality people on your team, and it's damn easy to screw up - which usually includes bridges burned and things being FUBAR by the time you realize what you did.

[Thomas]

Hi folks ,
Everything is a matter of style, let's not waste time on pointless battles. A C programmer is not better than a Java programmer or a C# programmer. It takes years of practice to master any language. I am still a student .

--Thomas

[OSwhatever]

I'm currently writing a kernel in C++ and everything works quite well as long as you have an idea what kind of assembly code it produces.

In my opinion C++ got out of hand a while ago and sometime it really feels like that syntax is hacked to oblivion. Take a look at the STL implementation for example, very hard to follow and it looks like programming the programming language.

Anyway, if you stick to the basics like "C with classes" and with a few template classes I think you're pretty safe. For me C++ has the advantage it encourage you to do more structured programming and easier to maintain when your project is getting bigger and bigger. You can do the same thing with ordinary C, but that takes more discipline, at least for me. I have worked at companies where they really liked global variables, for example for hardware drivers. What happens when the company adds a few more blocks of that same hardware, the driver can of course not be reused and must be rewritten. So you can basically abuse ordinary C as well, when in this example C++ would discourage you from doing that.

Things you should avoid having in the kernel are:

C++ exceptions. Not really easy to extract from the compiler libraries. When you have done it, it might change when you change version. If you change compiler brand it will not work at all since it's not portable.
Avoid STL. STL libraries are very keen on copying and allocating, something you want to avoid in a kernel where speed and memory fragmentation is important. Do your own brand of libraries that are more efficient. You can have a look at Boost intrusive libraries, which might be more suitable. Ordinary STL is more suitable for upper layers.

C++ is far from perfect but you get a few advantages over C that makes me want to use it.

C++ is getting more and more common in kernels. I think eCos is partly written in C++ and Choices is almost entirely made in it. Bascially in newer OSes tend to choose C++ more often.

[Solar]

Anyway, if you stick to the basics like "C with classes" and with a few template classes I think you're pretty safe.

Oh please, dear gods, no.

C++ is not "C with classes". Redicing it to that leads exactly to the kind of bad Java-style design I've been talking about. If anything, templates are the central "thing" of C++. But that language doesn't really fly until you combine the various paradigms in a "whatever-fits-best" way.

Avoid STL. STL libraries are very keen on copying and allocating, something you want to avoid in a kernel where speed and memory fragmentation is important. Do your own brand of libraries that are more efficient.

If you can't use STL effectively, don't bother trying to come up with something "more efficient". If you don't want the allocation / relocation, there are constructors that pre-allocate enough memory for a given size. If you feel you want a different allocation scheme, write your own allocator class.

That is exactly what I meant: To use C++ effectively, you need to have a quality team. Mediocre approaches to C++ bad code, reimplementation of existing functionality, and inefficiency.

You can have a look at Boost intrusive libraries, which might be more suitable.

That's where I agree with you: Boost is a very natural extension to the C++ standard library, and always worth to look into.

[Thomas]

Hi Solar,

Code: Select all

C++ is not "C with classes"

It is not now.But it was.Remember C++ was initially implemented as a set of macro's that expand classes ultimately into c code .

--Thomas

[pcmattman]

Hi Solar,

Code: Select all

C++ is not "C with classes"

It is not now.But it was.Remember C++ was initially implemented as a set of macro's that expand classes ultimately into c code .

--Thomas

Well, unless you just stepped out a Delorean, C++ is definitely not C with classes. Who really cares what it was when it's definitely not that right here in 2010?

Calling C++ "C with classes" is a really easy way to get out of writing decent C++, or even to fight against the language. You can tear the language to pieces if all it is to you is "C with classes". When you consider the other features (in my opinion the main feature of interest is templates) you start entering territory you can't come close to handling in C. Sure, you can make a "generic" linked list implementation in C that works off void pointers... but in C++ that can be fully type-checked at compile time, and use memory more effectively, with a template.

[Thomas]

Hi,

C++ is definitely not C with classes

agreed .

Who really cares what it was when it's definitely not that right here in 2010?

I do not care .C++ is the first real language I learned and I am not a C++ hater .I do not know about others .

Calling C++ "C with classes" is a really easy way to get out of writing decent C++, or even to fight against the language. You can tear the language to pieces if all it is to you is "C with classes". When you consider the other features (in my opinion the main feature of interest is templates) you start entering territory you can't come close to handling in C. Sure, you can make a "generic" linked list implementation in C that works off void pointers... but in C++ that can be fully type-checked at compile time, and use memory more effectively, with a template.

I agree with that too .Generics / Templates whatever are supported by other languages too .Eg , In C# you can make a generic linked list with data pointer is just an object class.But by using generics or templates, you write better type safe code. Point is that you can screw up things in other languages too . I agree that C++ is a powerful language. I was just bringing a historic fact, that's all. C++ however is not viewed with favor by many language experts.

--Thomas

[Owen]

I agree with that too .Generics / Templates whatever are supported by other languages too .Eg , In C# you can make a generic linked list with data pointer is just an object class.But by using generics or templates, you write better type safe code. Point is that you can screw up things in other languages too . I agree that C++ is a powerful language. I was just bringing a historic fact, that's all. C++ however is not viewed with favor by many language experts.

--Thomas

No language besides C++ to my knowledge has the same kind of template flexibility as C++. Now, "Generics" may indeed be simpler - and they definitely produce much better error messages - but the aren't templates. As much as using them so is quite silly - C++ templates are turing complete, and that has an awful lot of good implications.

[Thomas]

Hi,

C++ templates are turing complete, and that has an awful lot of good implications.

I however do not really see the need .Honestly, I was not aware that C++ templates are turing complete.

--Thomas

[tharkun]

Hi,

C++ templates are turing complete, and that has an awful lot of good implications.

I however do not really see the need .Honestly, I was not aware that C++ templates are turing complete.

--Thomas

It means you can do calculations at compile time (and other things, this is just a simple example):

Code: Select all

template <int N>
struct factorial
{
  enum { value = (N == 0) ? 1 : (N * factorial<N -1>::value) };
};

Or you can do it like this:

Code: Select all

template <int N>
struct factorial
{
  enum { value = N * factorial<N - 1>::value };
};

template <>
struct factorial<0>
{
  enum { value = 1 };
};

[Solar]

...and Bjarne Strostrup himself was quite surprised, and a little bit annoyed, when he saw those compiler messages crawling across his screen thanks to an example program someone had given him. That wasn't the intention of templates, and he realized what a can of worms they'd opened, but there you are.

[tharkun]

...and Bjarne Strostrup himself was quite surprised, and a little bit annoyed, when he saw those compiler messages crawling across his screen thanks to an example program someone had given him. That wasn't the intention of templates, and he realized what a can of worms they'd opened, but there you are.

The templates in D however, were designed from the ground up to support this metaprogramming, resulting in a much neater version of my factorial snippet found above:

Code: Select all

template factorial (uint n)
{
    static if (n == 0)
        const factorial = 1;
    else
        const factorial = n * factorial!(n - 1);
}

const n = factorial!(5); // n = 120 at compile time