why c++ is not often used

[DevL]

Bear in mind that using programming language X doesn't imply that you use every single feature of X. As solar has pointed out elsewhere you could e.g. define a subset of C++, omitting the most memory and CPU intensive parts while still retaining niceties such as namespaces. furthermore if you want to make your OS C++ enabled for developers you'll have to deal with the issue of supporting the extra functionality.

[nullify]

If you use one of the features that implies such overhead, yes. Those are features that C doesn't have. The question is, would you be able to create the same semantics, in C, without using up at least as much space?

Here I was thinking more along the lines of objects, rather than "peripheral" semantics such as exceptions. Constructors/destructors, accessors/mutators, multiple inheritance, and virtual base classes to name a few. This kind of functionality is more central to C++ design and can be done without in C.

BCPL is the ancestor of C. It was superseded because C was considered more practical. Now, I don't say that C++ could or should supersede C, but it is an advancement.

It is an advancement both in terms of features and complexity. I feel that the added complexity is inherently counter productive to kernel development. This is subjective, but its my opinion on the matter.

What was said about the C++ committee... Yes, they extended the standard over time, as new issues arose. At times, that required adding another keyword, making some identifiers illegal. So what? We are talking about one global search & replace here! BTW, C99 isn't fully compatible to K&R C, either...

The concern here is that the C++ committee does not feel as strong of a need to maintain backwards compatibility with existing C code than the C99 standards people do. Extensions and modifications to the C standard are more likely to be less obtrusive of existing C code.

Then, the fragile base class problem... that is an issue for C++ interfaces, i.e. when you export a C++ API through syscalls. That's a whole different decision from writing a kernel in C++. I'm not even sure if that problem still persists now that the standard C++ ABI is around. (Hadn't had the time to check this yet.)

I think the C++ kernel interface _does_ play a critical role in choosing to write a kernel in C++, and should be part of the same decision. The kernel interface to device drivers and user applications is very important.

The new standard C++ ABI will resolve binary-incompatibilities among different versions of g++, although I didn't read anything about ameliorating FBC. Even if it were done, another overhead would be created. Every FBC solution I've read about in other programming languages have the offset tables generated at run-time, which places a speed overhead on it.

Then, the aesthetics... well, that's personal preference, and certainly not a technical reason one way or another.

Agreed.

Portability... well, really fine C++ code is more portable than C code, in the sense of modularity. But that would be going too far. But one other reason to use C over Assembler is readability, maintainability, abstraction. And especially on the abstraction level C++ beats C hands-down.

Modularity encourages code reuse and interchangability, but not really code portability (in the sense of platform-independent). C++ does have more abstraction than C (due to its object oriented nature), but I'd argue that at times OO's abstraction is too much and causes a burden. Too much data hiding, complex class hierarchies, and in general so much abstraction that at times its hard to tell exactly what's going on when you need to. But I digress; this is heading off into personal software design preferences again.

But this is, basically, bickering. You say that, if someone can't live without C++, he should go for it. I say that, if some can do C++, he should go for it. That's probably because I can do, and you can do without, but in the end, we basically agree.

I'll agree with you on that.

[Pype.Clicker]

'Wat mij betreft', i feel C++ is too complicated to address the programming of a kernel ... But that's probably because i'm not fluent in C++. Things like members protection, friend classes, inheritence hierarchies, etc. require a lot of design attention, which means before finding a good design for a component, you'll have to choose the right "way" to tell C++ what is allowed in addition to have to choose the right structures & functions (or classes/methods) and selecting the right algorithms.

For my own work, i prefer sticking with C even when i actually have an object-oriented design. In the rare cases where i actually need things like inheritance and polymorphisms, function pointers are enough.

I'm used to design OO stuff using the concept of packages and interfaces rather than friends and multiple inheritance.

[Solar]

Things like members protection, friend classes, inheritence hierarchies, etc. require a lot of design attention, which means before finding a good design for a component, you'll have to choose the right "way" to tell C++ what is allowed in addition to have to choose the right structures & functions (or classes/methods) and selecting the right algorithms.

(...)

I'm used to design OO stuff using the concept of packages and interfaces rather than friends and multiple inheritance.

I've never used a multiple inheritance in the three years of professional C++ coding, and before that only for trying this strange stuff. Currently I doubt I will use inheritance at all to any significant degree, and except for operator<<() and operator>>() I never felt the need for a "friend" function either.

Just to show that "using C++" doesn't equate "using all of C++".

I'll drop the subject for now, and return when I have some "real" code to put up as an example how "neat" C++ can be.