Any particular point that you can refute? I thought not. Responding to you is like talking to a wall. And just as much of a waste of time. Go examine the machine code generated from a C and a C++ compiler for the same program. (You can read assembler, can't you? ;-)

BTW, I attended a talk given by Brian Kernighan in which he compared popular programming languages for clarity of expression. It was his opinion that C++ was the clear winner. (You do know who BK is, don't you? ;-)

I've gone back over your posts and have confirmed that they are totally information-free. Case closed.

Was it a talk on kernel programming?
ta0kira

I am not a C++ fan, but I agree with you.

Furthermore, C++ can automatically be translated into "C" - see, for example, llvm.org - also supported by Apple.

And, anyway, whenever possible, write a user-space driver.

Another thing on C++ - if classes with data members are used instead of plain variables, access to the said data members is through 'this', i.e. through yet another pointer - some performance degradation.

But that would be true for "C" too whenever a struct is allocated and access is through pointer.

I agree. In fact in C++ a struct is a simple kind of class and access to a data member in C++ class results in the same sequence of machine instructions as access to a data member in a C struct (as compiled by a C compiler.) Just as access to a member of a C struct will (often) require access through a pointer, access to a member of a C++ class will(often) require access through a pointer. (If the class is a stack variable, access will be through an offset just as for a struct.)

When programming in any language, one must be aware of the cost/complexity of the expressions, data structures, and algorithms one uses. I haven't met any kernel developer, programming in C or C++, who is unaware of issues of efficiency.

Thanks for the contributions, Sergei!

^ i read your arguements; it contradicts my own limited study (posts # 12 13 22 24).

another argument that was made is like comparing a ferrari to a moving truck. both have a purpose that is far better than the other one.

Regarding post #13 - wrong example.

If you are serious about embedded/kernel programming, first learn how to use compiler in a manner it does _not_ link standard runtime.

Your example in post #13 does not satisfy the above requirement because the example is a typical C/C++ main program _with_ standard runtime.

Benchmark a function without standard runtime and see its assembly code - that would be the correct study.

1 members found this post helpful.

I totally agree. 12 is an unsubstantiated remark, and 13, 22, and 24 are based on a bogus example and have been already well rebutted. As Sergei says, the generated assembler/machine code is a more objective way to compare the languages for efficiency.

Only if such code is intended to run a CPU directly, i.e. maintain an idle loop, manage processes, handle interrupts, control hardware, map memory, etc. You can't make a user-space comparison valid for kernel-space no matter how you spin it, even if you write a mock kernel for a virtual machine to be run in user-space.
ta0kira

Once the C++ code is compiled it is essentially indistinguishable from the equivalent code compiled from C. Except that the C++ code will take better advantage of inline optimizations and elimination of redundant pointer validation and so will be faster than the C version.

What I was really commenting on was the intention of the code. Both languages are better in some areas, so comparing code intended for user-space might be a disproportionate comparison. A better comparison would be a basic kernel written in C++ (C++ style) vs. one written in C. If you can't write a functioning kernel that's mostly C-less C++ then you'll just have a C++-enhanced C kernel.
ta0kira

I am not 100% sure, but I think that support of "inline" in a sense of really transforming the code tagged "inline" into inline code, is not mandatory.

I think it is not mandatory for both "C" and C++.

gcc/g++ in reality support "inline".

You've entered a very grey area, since it's difficult to well define "style".

Typical C++ programs create class instances through "new" which is very similar to "malloc".

Neither "new" nor "malloc" memory allocation mechanism is suitable for kernel.

I think the point of using C++ in kernel is its template programming features, for example. I mean, C++ has both CPP and templates while "C" has only CPP.

But, as a Perl guy, I'd say C++ templates are far behind Perl in their features :-).

When programming in the kernel one overrides the new operator to use kmalloc, kfree, or whatever the particular OS provides in the kernel environment. This is all done inline with no additional overhead.

Templates are a nice option but strong type checking, inheritance, polymorphism, references, and other fundamental features of C++ provide great advantages in creating highly reliable software.

There are a number of excellent features coming up supporting such concepts as generic programming. These won't appear in the GNU compilers until they have been adopted as part of the next C++ standard.

Perl has the advantages that the creators can play fast-and loose with the language definition and that the language is interpreted. Great for user-space, but not safe (in most current OS implementations) for kernel space.

My point about inlining is this: In C++ the language expresses modularity well and provides features (private, protected) in the language to express and enforce access restrictions. This is highly desirable in a very large, single address-space monolithic kernel like the Linux kernel. These language features work very well with inlining in supporting information hiding/protection without any loss of efficiency in the code.

For example, the only way to prevent access to private functions and data structures in C is to declare them (or pointers to them) "static" requiring that any functions needing to access these static functions or variables be present in the same C file. This foils modularity and adds the cost of a function call for access.

In contrast, C++ allows the developer to limit visibility/access while still providing total efficiency for access to the protected functions and data structures. Where C requires a function call for access to a protected data structure, C++ does not and is, consequently, very much much faster.

I think you missed my point regarding Perl.

I meant I use Perl to generate C/C++ code, i.e. I use it as a better than CPP/C++ templates engine.

And, FWIW, Perl is compiled into bytecode (as Java, Python, Ruby, but _not_ as sh, tcl), so it's not an interpreted language.