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.
