Any good object pascal coder can do anything that a good C++ coder can do. Yes there are minor differences with various C++ compilers producing more optimized code but as Dan said, the difference is so negligible that the only time you'd make a choice based upon that metric alone is on a super computing cluster where such negligible differences can add up across many thousands of instances.

And that said, the 32bit Delphi compiler has been known to beat out MSVC in various cases (thanks FastMM)

I think the only arguments that should be made are for learning the language, what tools are available for constructing your patterns and how that effects time to market (how long it takes to finish the project, including in that sense how many people you need and the availability of those skills)

Everybody knows pascal is easier to learn and it's for a pretty basic reason really : English words used instead of symbols, which were only chosen in C back in the early days to save memory, not keystrokes. Back then they also limited var names to 8 chars giving rise to retarded practices in code where all the vars are called things like Agr, syHbal, A, B, C etc

It's also a strongly typed language which by design gives rise to far fewer bugs than C/C++. A good C/C++ programmer won't hit those bugs because they'll have a coding style that provides the same error reduction but that basically means they're manually following a process which pascal by it's very nature, enforces. A waste of effort for a new coder.

C is also case sensitive, again an archaic throwback to the low memory days where they wanted to make better use of each byte hence making the distinction between lower and upper case so I can call one var c and the other C and they're two distinct vars.

How on earth, in any sence, does case sensitivity help programmers? it simply does not, it makes code harder to read and introduces another avenue for mistakes and can lead to some really nasty bugs where you actually do have two vars of the same name but with different cases. In that instance you don't even get a warning, a simple typo causes a really hard to find bug. An experienced C coder would now argue that you avoid having the same words for vars so you don't run the risk of that happening - the response to that of course is obvious.

And then there's C/C++ string handling which is NONE. C/C++ doesn't support stings, that's left to the libs instead, string classes and so on. But there's so many different ways of handling strings in C, so many different 'standard' libs, that it's always a problem when introducing large sections of code to one another. Pascal has native strings, even native unicode support on the later compilers. All the memory handling is done for you, scope etc.

And the nice thing is that if I really wanted to, I could do strings just like any C/C++ lib does, all I have to do is process the data manually just like a C string class would do anyway.

Oh and finally, C++ was C with ++ added as it was a kind of joke that C++ is an increment of C. (++ being the increment operator) but look at this example :

int C = 5;
int D = C++;

What's now stored in D? 6? you'd think so wouldn't you? no, in fact it's 5, and C is now 6. C++ increments AFTER the var has been used, if you wanted 6 stored in D then you'd write :

int C = 5;
int D = ++C;

What I demonstrate here is that C++, the supposed evolution of C is in fact no better than C, as what's displayed in the statement is still equal to C and the incremented value has yet to be used. Not to mention that C hasn't been declared or set yet.