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.
