[quote name='Calmatory' timestamp='1311047148' post='4837187']
So what would your conclusion be for both C and C++? A right tool for the right task? What tasks are right for C but not C++? What tasks are right for C++ and not C?

IMHO, C is the right choice if:
* you've got a team who are good C programmers but bad at C++, and you don't trust them to not write bad C++ code (pitfalls of OOP is a good example of the performance disaster that bad C++ can lead to).
* you're on a platform with a good C compiler but a bad C++ compiler.
* you really want to use some C99 feature that isn't supported in your C++ compiler for some reason.

Instead of ranting, teach me. Show me. I'm asking for fourth time for someone to show how things are done correctly, and I'd appreciate it if it actually showed that C++ would be more ideal for low-level development than C. Especially for embedded systems in which resources are scarce. I'm waiting for code.

I'm not going to fix your hello-world [font="Courier New"]printf[/font] vs [font="Courier New"]cout[/font] loop, because it's just a hello-world problem and has no relation to any real problems. Does anyone even use [font="Courier New"]cout[/font], in anything but "hello world"?

I'm too busy writing high-performance C++ for embedded devices to tutor you right now, but the folks at Dice have some presentations on how to not write bad C++ that you should absolutely read: http://publications....ory=Engineering. The 'Scope Stack Allocation' presentation is a particularly good gem.
You'll be happy to see that the result is very "C style"
[/quote]

Ironically, their latest presentation is essentially "don't use C++ features"
http://www.slideshare.net/DICEStudio/executable-bloat-how-it-happens-and-how-we-can-ght-it

I guess it's needless to say at this point that to make the most out of C++, it has to be very C-like, perhaps even relying on the C library rather than the C++ one?

Sure. All the hundreds of thousands of dollars spent funding research and development, ratifying standards and building compilers was just to be awkward. Obviously none of it was ever intended to be used in production code. [/sarcasm]

The facts are these: the domain we are discussing in this thread, very low level code written to execute with a very small memory footprint and realistically valid concerns about micro-optimisation, is highly specialised and represents a tiny, tiny subset of programming domains in general.

The point, as it seems to me, is that C++ is suitable for both this domain, and a variety of other domains including complex application development where the additional features of C++ come into their own. C is suitable for a far lesser variety of domains.

You seem to have a skewed idea of what C++ is to be honest. print() is a C++ standard library function. Function pointers are a C++ language feature. The fact that C++ happens to have these in common with C does not make using them in C++ writing a "C-like" program, any more than using a regular expression library makes my C++ "grep-like".

C++ provides the efficiency of C when required and a host of useful features on top that are normally implemented by the compiler far more cheaply than paying a C programmer to write the equivalent functionality manually. The fact that there are fewer programmers expert enough to use these features effectively, as per Mr T's spurious and silly arguments, is cultural, historical and has nothing whatsoever to do with the language.

You are not advocating against using a sledgehammer to crack a walnut. You are advocating against owning a toolbox with a variety of tools, including a walnut cracker, over simply owning a walnut cracker. (Sits in corner and waits for analogy police to arrive).

Sigh.. ...but what if this topic explicitly covers just that tiny subset of programming domains in general?

Then I refer to the point that C++ is suitable for these subsets while providing improved type-safety and generics at no extra cost, except for programmer training.

I have no interest in arguing that X is better than Y. I am, however, happy to argue that a box of tools is better than a tool on its own. If I want my lawn cut, I'd rather employ a gardener who also owns a chainsaw just in case I suddenly decide a tree needs pruning while he is there. If not, his chainsaw can stay in the van.

Plus, to stretch the analogy to beyond breaking point, his lawnmower is less likely to electrocute my cat.

1) C is more compact in terms of resource usage.

Disagree, as stated.

2) C is more portable, so there are more mature compilers for wider variety of platforms

Agree, as stated, with reservations. Age and ease of implementation are the reasons, not portability. C++ has a perfectly well-defined standard.

3) C is simpler, easier to learn and use properly and there exists lots of good enough programmers for the job.

Agree, as stated, with reservations. "Properly" is a dangerous term. Your own example with the potentially breaking limitation of a 32 character name well demonstrates this point.

In C++ I am writing a bubble-sorting algorithm to sort a list of strings alphabetically ... If each string is 10,000 characters in size, and there are 40,000 strings your looking at a huge overhead implementing it this way.
[/quote]
If there are 40,000 strings, why have you decided to bubble sort them? This is under a bullet point talking about efficiency.

But if C++ is suitable, and better by providing improved type-safety and generics at no extra cost, why isn't C++ used instead of C? That's the fundamental question behind this whole topic.

It is...
C++ is used instead of C, commonly, in low-level code.

The question behind the topic is based on a false assumption.