C faults, etc

[Daniel Keep]

bearophile wrote:
> There's a long thread on reddit about the faults of C language:
> http://www.reddit.com/r/programming/comments/92l8w/in_your_opinions_what_is_wrong_with_the_c/
> 
> Some comments derived from it:
> 
> D already fixes/pathes several problems of C, but not all of them. One of the problems is the pointer syntax and the problem coming from its operator precedence. Pascal pointer syntax is a bit better. The famous "C++ resyntaxed" shows a quite better pointer syntax. I'd like to see a better and less bug-prone pointer syntax in D, but it's hard to change it and keep almost-source-compatibility with C at the same time.

What are you talking about?  There are numerous people complaining that
defining pointer types is painful, but D fixes that.

There's one person who complained about parsing ambiguities; was that
what you were referring to?

It doesn't help that you don't specify what the problem is.

> ------------
> 
> Lint-like programs like Splint (http://www.splint.org ) help avoid some of the problems of C, but from experience I can see people don't use such programs. So D has to contain some of the things done by a lint. One of the important things is a way to add some more semantics to programs, for example to say if two pointers/slices/arrays are surely distinct, and many other things. (So far I have not understood the D stance regarding pointer aliasing).

Neither Lint or Splint was mentioned ONCE in that thread.

> ------------
> 
> D has now two switch, both of them faulty. This looks worse than the C situation. I can't appreciate this situation.

Switch was brought up exactly once, but that was a comment regarding
enums.  You also haven't specified what the problem is.

> ------------
> 
> C comma operator is bad. Python shows a WAY better way to use commas, but if D wants to keep its almost-source-compatibility with C then Python syntax may be hard to be added. A partial solution I see is just to turn some usages of the comma operator into a compilation error, just like in D it's an error legal C syntax like:
> int *i, j;

Comma operator was never brought up.

> ------------
> 
> Java shows that undefined behaviour can be avoided with an acceptable cost in performance. So D eventually has to remove all situations where it acts in an undefined way.

While I think it should, I hardly see why the first demands the second.

> Where it's really needed some non-standard way to do things can be added. Better to have nonportable things than undefiend things.

I'm fairly certain Walter has stated numerous times that one of the
goals of D is to remove undefined behaviour.  Why are you arguing for
something which Walter already agrees with you on?

One quick query with Google later:

"One of the goals of D is to eliminate undefined behavior wherever
possible. In C++, the undefined order of static construction was a
source of many porting problems. I think it's better in the long run to
have a defined order, even if it means having to reorganize the code a bit."

http://www.digitalmars.com/d/archives/digitalmars/D/announce/Re_QtD_0.1_is_out_14928.html

> ------------
> 
> writefln, writeln and the things of Tango are nice and cute and safe, but if I have to save 250 MB of numbers (or 1 GB of them, or even more) then performance is important, and those cute functions are 2-3-5 times slower than printf. This means printf can save me minutes of running time. So I use printf. But if I use printf in C and I write:

Firstly, if they're slower than printf, I imagine something is wrong.
In Tango's case, I know it directly calls into the Win32 API.  If it's 5
times slower than printf, something is horribly wrong, either with
something along the way, or with your code.  Did you file a ticket?

Actually, let's check...

(Goes off to test.)

If you naively use tango.io.device.File and, say, to!(char[])(int), then
D will take twice as long as C.  That's because File is unbuffered and
to!(char[])(int) uses a heap allocation.

If you use a Buffered stream and use ...convert.Integer.format with a
scratch buffer, D ends up being about 10% faster than C.

This could be better documented, but Tango is *not* slow when used
correctly.

> int main() {
>     float f = 1.2345;
>     printf("%d\n", f);
>     return 0;
> }
> 
> The compiler says me:
> warning: format '%d' expects type 'int', but argument 2 has type 'double'
> While DMD compiles it silently. Better to quickly add such warning/error to D compilers too.

Why on earth should the D compiler special-case a function that's not
even supposed to be used?!  D has typesafe variadics and variadic templates.

> Bye,
> bearophile

None of these, with the possible exception of the pointer syntax one,
had anything to do with that thread, so far as I can see.