Inherent code performance advantages of D over C?

[Walter Bright]

On 12/13/2013 6:52 AM, Dicebot wrote:
>> 1. compile speed
>
> Only partially true. Large projects need separate compilation and D does not
> behave that good in such scenario. Still better than C, but not good enough to
> make a difference.

Doesn't behave that good how?


>> 2. dependable sizes of basic types
> Not a real issue as your platform SDK always includes some kind of "stdint.h"

I've been around C code long enough to know it is a real issue. (Few programmers 
ever use stdint.h, and usually use it incorrectly when they do. Furthermore, 
those types aren't used by the C standard library, and are only very rarely used 
by 3rd party C libs. You cannot get away from this problem. It's made even worse 
because C will silently truncate integers to fit.)

>> 3. unicode
>
> Number one my list of advantages. Does not apply to plenty of projects though.

It applies more than you might think. Most D apps will be inherently unicode 
correct. Very, very few C programs are unless the programmer went to some effort 
to make it so. And, take a look at all those miserable UNICODE macros in windows.h.


>> 4. wchar_t that is actually usable
>
> Same as (3)

Almost nobody uses wchar_t in C code because it is unusable. Windows uses it for 
the "W" api functions, but surrogate pairs are broken in just about every C 
program, because C has no idea what a surrogate pair is. Furthermore, you're 
just fscked if you try to port wchar_t code from Windows to Linux, you're 
looking at line-by-line rewrite of all of that code.


>> 5. thread local storage
> It is lot of pain and source of problems, not advantage. Extra work to hack the
> druntime to get stuff working on barebone.

Making druntime work properly is not a problem for user programming. Most C 
programs care naught for global shared data, that is, until they try to 
multithread it. Then it's disasterville.


>> 6. no global errno being set by the math library functions
> This has made me smile :) It shows how different applications we have in mind
> speaking about "C domain".

Do you mean people don't do math in C apps?

>> 7. proper IEEE 754 floating point
> Potentially useful but largely mitigated by platform-specific development.

I suspect you haven't written serious FP apps. I have, and C's erratic and 
crappy support for FP is a serious problem. It's so bad that D's math libraries 
have gradually transitioned towards having our own implementation rather than 
rely on C's standard library.


>> 8. no preprocessor madness
> Would have called this a feature if one could actually use something instead out
> of the box. But there is no way to control symbol visibility right now so
> templates / CTFE are often out of the toolset. And what to do without those?

I have no idea what your issue is here.


>> 9. modules
> Other than (1) it is also more a problem than help in current implementation -
> you need to care also about emitted ModuleInfo.

Why do you need to care about it?


>> 11. inline assembler being a part of the language rather than an extension
>> that is in a markedly different format for every compiler
> Not an issue. You almost always stick to specific compiler in barebone world
> (one adapted for your platform).

I've had to port C code from one platform to another and had to do complete 
rewrites of the inline asm, even though they were for the exact same CPU. This 
is not convenient.


>> 12. forward referencing (no need to declare everything twice)
> Not an issue. C programmers are not tired from typing.

C programs tend to be written "bottom up" to avoid forward references. This is 
not convenient.


>> 14. no ridonculous struct tag name space with all those silly
>>
>>     typedef struct S { ... } S;
>>
>> declarations.
>
> Nice but just a syntax sugar yet again.

The tag name space is not convenient.


>> 15. no need for precompiled headers
> Same as (9)

Do you seriously believe C precompiled headers are convenient? Have you ever 
used them?


>> 16. struct alignment as a language feature rather than an ugly extension kludge
> Same as (11)

Have you ever tried to port C code that uses alignment?


>> 17. no #include guard kludges
> OH MY GOD EXTRA <10 LINE OVERHEAD PER HEADER

Not convenient. It also tends to be sensitive to typos that won't be detected by 
the compiler, and the usual non-hygienic macro problem. I see those typos now 
and then in C code I run across.


>> 19. no need for global variables when qsorting
> Doesn't matter

Have you ever used qsort much? It is hardly convenient - you have to write a 
bunch of boilerplate to use it using global variables, and none of that will 
work if you've got multiple threads.


>> 20. no global locale madness
> (no idea what this means)

strtod's behavior (for example) is dependent on the current locale. The fact 
that you didn't know this is indicative of its problems. This is not the only 
locale-dependent behavior. C has a number of issues with global state.


>> And if you use D features even modestly, such as auto, purity, out variables,
>> @safe, const, etc., you can get a large improvement in clarity in function APIs.
> `auto` has no real value in C world

Going back to the integer type size issue and C's propensity to silently 
truncate integers makes it a very real issue.

---

Yes, you can work around all these issues, but they aren't convenient, which is 
what this thread is about. But much worse are the increased propensity for 
silent bugs identified here.