Inherent code performance advantages of D over C?

[Walter Bright]

On 12/7/2013 12:13 AM, qznc wrote:
> However, I think the original statement is also true in the technical sense. The
> same argument can be made with assembly. It is impossible to beat "proper"
> hand-written asm, where proper means "only theoretically possible". In practice
> I agree with you that optimizing a D program should be easier than optimizing a
> C program.

"there is no way proper C code can be slower than those languages."

It's the qualifier "proper". You say that means theoretically possible, I 
disagree. I suggest that proper C code means code that is presentable, 
maintainable and professionally written using commonly accepted best practices.

For example, I've seen metaprogramming done in C using the preprocessor. It 
works, but I consider the result to be not presentable, not maintainable, and 
unprofessional and not a best practice.

For another, Maxim suggested that it was easy in C to use D style 
length-delimited strings instead of 0 terminated ones. It's certainly 
theoretically possible to write such a string type in C, but it ain't easy and 
your result will be completely out of step with anyone else's C code and C 
libraries, which is why people don't do it.

For another, how many times have you seen bubble sort reimplemented in C code? 
How about the obvious implementation of string searching? etc.? I've seen that 
stuff a lot. But in D, using a best-of-breed implementation of quicksort is easy 
as pie, same with searching, etc. These kinds of things also make D faster. I've 
translated C code into D before and gotten it to run faster by doing these sorts 
of plug-in algorithm replacements.