Why not use C and C++ for a parallel experiment and make your own determination?

In the end it's all about the code and how the compiler interprets it.

And that's actually the first thing I learned about C. Bunch of engineers, we were using C long before our employer decided we all needed to take an advanced class in it.

Funnily enough the instructor was a (pardon the phrase) cocky Engineer just like all of us. He challenged us minute number one to expel our prowess, and explain to him all we knew about the C language and tell him all we knew about how good versus bad it was compared to assembly.

Well, he may as well have either worked directly with Kernighan and Ritchie, or literally been those guy. He was the equivalent of a compiler designer. And his first and recurrent point was that the most important thing for us to work at understanding was:He hammered that the whole week. And to me, it doesn't matter how good versus bad C and C++ compare, even C# or also Objective C. If you're concerned about efficiency, speed, and memory footprint, then what you need to understand is the code which is generated based on what you wrote and how you wrote it. There are tons of prama, or preprocessor directives as well as compiler switches, and then there are tons of systems which these compilers are built for. If you wish to tune your code to be highly efficient for a particular case, then you need to get under the hood of what code is being generated by the compiler and also where it is being located in your system.

Use C for systems programming. Use C++ for application programming. It's that simple. Anyone who says otherwise has probably never done systems programming.

you did not read what was written, otherwise you would meanwhile know that there is more than 1 OS where also kernel / driver , or what you called system programming, is done in C++.
but thanks for your expert opinion, especially those who say to have done system programming an know therefore all about it

Fair enough. I'll qualify the statement by saying that in Linux, C is much more efficient as a systems programming language. C++ contains layers of abstraction that make it a better choice for application programming.

I've always said that you can write very much C-like C++ code. That is because C++ is a C extension language. I've seen lots of drivers written in C++.

We get a lot of embedded toolkits based on C++.

Tons of arguments one way versus another as to whether or not using libraries in embedded systems are things people do.

Some say it depends if the library was well tested, if they have accessibility to source, and if it's a commercial library. Others say "no way" write it your self so you know what the code is doing.

Same for systems code.

Encapsulation, inheritance and polymorphism would seem like very good reasons for using C++ in a large project (which I would classify a Linux kernel as).

However, these are about the only features of C++ that you would be able to take advantage of if you wish to maintain absolute control over the code that is produced. Even the exception handling provisions of C++ might seem off-limits. (Where are the exception variables stored? What sort of error trapping code is produced?)

interesting how different opinions can be

I would say that inheritance and polymorphism are less important than RAII + destructor guarantee for resource management, and of course the possibility of templates, which, used correct and with caution, add extra type security instread of some macro void* constructs.

inheritance and polymorphism is 90 % used wrong or in a overdose, and that's the point where people care more about solving their inheritance diagram than solving the real problems.
not mentioning that real 'is a' relations are less likely than the java 'A implements B' relation which is mostly nonsense in C++ to implemnent via Interfaces but used everywhere.

exceptions are optional. the advantage is they can not be ignored and help to have a useful interface that does not disable things like for example copy elision.

is simply a better interface, it runs faster since return value optimization and more secure than

I hear you. Too many people think that just because it is possible to do "clever" things in C++ that they have to - even when done in a stupid way. Maybe that's why Linus wants to boil C++ programmers in oil.

I am aware of the usefulness of exception handling. I'm just not convinced that their use would still allow a programmer to retain absolute control over all memory use/allocation. (I could be wrong about that though).

for the system programming has to happen in C folks,
https://sourceware.org/ml/libc-alpha.../msg00416.html
enjoy!

I rarely use void actually. So no, I haven't given up type safety. Whatever you think that may be.
I don't copy code snippets, that's hard work, I generally create shared libraries and use a lot of dynamically loadable plugins for your information.
(If I did though I would call them "design patterns" :-)

Granulation? Don't get that bit. I didn't copy from the internet I made it up as a half joke actually.
A bit like "Java.lang.out.of.bloody.memory.again "

You C++ programmers take your language far too seriously.

edit: oh yes, I never use macros either. It's not 1995 you know.

please show me you dynamic array implementation that works for which type/struct ever.
without, what you say do , macros, void* , repeat yourself ( = copy past)

I'm not sure what your point is. Is it that there is a bug in some software that was written in C or that had the language of choice been C++ then this bug could not have happened?

1 members found this post helpful.

edit: nvm, i don't care