The C versus C++ debate

[Candy]

C++ has ground-up designed constexpr's to handle those with just a bit more elegance.

[tharkun]

C++ has ground-up designed constexpr's to handle those with just a bit more elegance.

I'm not sure about the rules for recursion with constexprs, though IIRC there was a defect report about it.

[fronty]

Ada's generic system has some nice things, including eg. nice way for limiting what kind of type can be used and how it can be used in the generic.

[skyking]

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.

It's amazing how people get the post wrong. The suggestion was that one would be safe if you used C++ as "C with classes", and not that C++ in fact was that, and it's pretty much true. The reasons you would end up with larger or slower executable with C++ than C is that you're using features of C++ that is not in C - otherwise you should end up with the same result (at least if you turn of exception handling and RTTI in the compiler). Templates for example can easily lead to code bloat if you don't take care to avoid code duplication (which can mean that you're using memory less effectively)...

[Owen]

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.

It's amazing how people get the post wrong. The suggestion was that one would be safe if you used C++ as "C with classes", and not that C++ in fact was that, and it's pretty much true. The reasons you would end up with larger or slower executable with C++ than C is that you're using features of C++ that is not in C - otherwise you should end up with the same result (at least if you turn of exception handling and RTTI in the compiler). Templates for example can easily lead to code bloat if you don't take care to avoid code duplication (which can mean that you're using memory less effectively)...

If you just use C++ as C with classes, and throw out templates and exceptions, then you throw out much of what makes C++ nice to work with.

Such as the STL. Thats right: Even if you permit use of external templates, you threw it out with exceptions.

And I find it crazy that people suggest that templates - one of the most benign C++ features - should be ignored.

[tharkun]

Now, "Generics" may indeed be simpler - and they definitely produce much better error messages.

IMO, Error messages about C++'s templates are very meaningful. It's just that 6 pages of pure meaning are a bit much for some people.

[OSwhatever]

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.

It's amazing how people get the post wrong. The suggestion was that one would be safe if you used C++ as "C with classes", and not that C++ in fact was that, and it's pretty much true. The reasons you would end up with larger or slower executable with C++ than C is that you're using features of C++ that is not in C - otherwise you should end up with the same result (at least if you turn of exception handling and RTTI in the compiler). Templates for example can easily lead to code bloat if you don't take care to avoid code duplication (which can mean that you're using memory less effectively)...

If you just use C++ as C with classes, and throw out templates and exceptions, then you throw out much of what makes C++ nice to work with.

Such as the STL. Thats right: Even if you permit use of external templates, you threw it out with exceptions.

And I find it crazy that people suggest that templates - one of the most benign C++ features - should be ignored.

No one said anything about throwing out templates. Templates is a good feature but when you use them you have to look out a bit. There are things like code duplication, unnecessary copying and other things that you might want to look into. There are critical places in kernels where you might have the extra control over produced code.

As for exceptions, I don't know any who use C++ exceptions in kernel for obvious reasons I mentioned earlier. If you know any kernel that does, I would be happy to hear about it since that would be interesting how they solved it. Exceptions is not necessarily a bad thing, it's just that the run time support can be tricky solve.

System programming in C++ is a little bit different from normal user space programming but as long as you understand what final code it produces you are usually alright as you then also understand the drawbacks and the benefits of your design decisions.

[pcmattman]

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.

It's amazing how people get the post wrong. The suggestion was that one would be safe if you used C++ as "C with classes"

And I can drive very safe if I only use my car in first gear (I won't get anywhere fast, and there's still a risk - but significantly less than if I pushed the car to its limit!).

In my opinion, you should still be using C if all you see C++ as is C with classes. Like I said - calling C++ "C with classes" is a cop-out, nothing more, nothing less, and calling it "safe" is merely an attempt to justify that statement.

[skyking]

And I can drive very safe if I only use my car in first gear (I won't get anywhere fast, and there's still a risk - but significantly less than if I pushed the car to its limit!).

In my opinion, you should still be using C if all you see C++ as is C with classes. Like I said - calling C++ "C with classes" is a cop-out, nothing more, nothing less, and calling it "safe" is merely an attempt to justify that statement.

I noted you say that, but I've not seen anyone stating otherwise. Just because C++ has all kind of features does not mean that you have to use all those features in every situation, some features also require some care if you're to avoid code bloat.

Or for your analogy with the car: If your car can do 200mph does not mean that's a good idea to run in 200mph all the time (and when you do you should better be careful)...

[TylerH]

Why is it that you assume you must choose between them? I have all my kernel in C so far, except for main, which is in C++(It's really just C, with .cpp extension.) I use C for things that don't need the features of C++ to avoid bloat. I compile main as .cpp to leave the option later to add in whatever OOP feature I want(I really want to use C++ for implementing my driver interface; That is, when I get there.)).

The only downside to this is having to include

Code: Select all

#ifdef __cplusplus
extern "C"{
#endif

/* Normal C header stuff */

#ifdef __cplusplus
}
#endif

in all my C headers.

Is there some reason, that I'm missing, why this isn't widely done?

> Or for your analogy with the car: If your car can do 200mph does not mean that's a good idea to run in 200mph all the time (and when you do you should better be careful)...
Sounds like a good way to burn a lot of gas.

[inx]

Is there some reason, that I'm missing, why this isn't widely done?

I wouldn't know about the reason that isn't done, but it does dilute the air of minimalism. Although that wouldn't actually add any overhead to the binary, it would add unneeded overhead in the human sense.

[rJah]

I'm writing my kernel in C++, for x86 and PowerPC simultaneously, and C++ makes it really easy to structure code. Platform independent stuff goes in abstract classes, which HAL classes then inherit and implement platform specific stuff. For example, here is my output stream interface, which implements printf and print, relying on a platform specific putChar function.

Code: Select all

class IOutputStream
{
	public:
		static const uint8_t tabWidth;
	
	public:
		IOutputStream();
		virtual ~IOutputStream();
		
		virtual IOutputStream& putChar(char ch) = 0;
		
		virtual uint32_t getPosition() = 0;
		virtual uint32_t setPosition(uint32_t pos) = 0;
		
		virtual IOutputStream& print(const char* str);
		virtual IOutputStream& printf(const char* fmt, ...);
};

For me, the kernel doesn't need to be super small, or super fast, I much prefer code readability over the smallest, fastest kernel binary. And C can make things a nightmare in this department (at least for me).

Edit: Also, as Bjarne Stroustrup once said, the good programmers know which features to use for the job at hand, the bad ones just go using everything, like implementing custom operators for every class they have. (or something like that, cant find the source)

[Solar]

For example, here is my output stream interface, which implements printf and print, relying on a platform specific putChar function.

Nice... but... printf()? Eeeewwwww....

Edit: Also, as Bjarne Stroustrup once said, the good programmers know which features to use for the job at hand, the bad ones just go using everything...

...or putting a dent in their designing by limiting themselves to a subset and not using the tool that's best for the job.

Basically it's the same for every language. C++ compounds the issue though because there are so many features to the language.

...like implementing custom operators for every class they have. (or something like that, cant find the source)

Different subject: Overload operators only where it would feel natural and unambiguous to do so, and nowhere else. Oh, and don't overload || and &&. (Because you cannot emulate the "short circuit" semantics of the originals.)

[rJah]

Overload operators only where it would feel natural and unambiguous to do so, and nowhere else,

Which is why I don't overload << in my output stream, I always found the "shift stream left" kind of strange.

[Kevin]

Platform independent stuff goes in abstract classes, which HAL classes then inherit and implement platform specific stuff. For example, here is my output stream interface, which implements printf and print, relying on a platform specific putChar function.

Not sure if this is the best example for the usefulness of inheritance. You have one derived class per architecture in the source code, so what ends up in the binary (which is architecture specific) is exactly one implementation. You can certainly handle this without inheritance or any C++ - just link the the right putchar.o for the architecture. And you even save the overhead of virtual functions if you do without inheritance.