Hi!

Let me show an other approach of programmig D.
How to make the D development faster, easier, better?

1. Unions and structs define data layouts, so they sizes MUST be easily
determined. There MUST be no difference whether variables of a special type or
the type definition itself takes place in an other type definition. The size
MUST be the same.
Class layouts are free to rearrange for compilers (as it is defined).

2. There SHOULD be clear and easy rules to determine what an assingment will DO. Or (maybe) the copy_on_write mechanism should be explained exactly. Or the referencing/array slicing mechanism should be reengineerd.

I know these things are discussed here and have _theoretical_explanations_. Be sure I'm here not just complaining but ... A good language needs people who use it in practice an not only in theory...


Let me tell why!

How does work a practical development in D?
Why D is a better language than other? Is D better than other?

I follow how D is evolve for years. Nowadays I started to write a simple text
editor for my own purposes in D to try the real usability of D.
(I know C and C++ pretty well and used to write short utilities in D as well.)

This 'project' was originally started (and abandoned) using C++.
The product was almost useable, but was full of typical C++ errors:
memory leaks, memory overwrites, crashes ... typical pointer related problems.

Now the D version is roughly in the same state, but the quality of the product and the way of the development differ slightly:

- the D version of source is the half of the C++ version (thanks to dynamic arrays, references and garbage collector)

- the D version of release executable is double in size
(not a big deal when the D version is 150Kb)

- the execution speed is a little bit lower in D, no surprise (D speed is good enough, C++ was too fast ;-)

- there are no crashes in the D version, simply no, at all ...

- there were a lot of "Access violation" and "Array copy" and other runtime errors while developing and it is GOOD, since these kind of errors ARE in the C++ version yet

- the coding of the C++ version needed 6 times more time (It's a toy for me not an important project. I have been playing with the C++ version one and two-three years and with the D version only 6 months)


These are the good things, the very-very good thing for a developer, but there
are few wrong ones too...
D is not predictable in special cases and these things slow down the
development.

- the struct and union size calculation is not predictable as it was in plain C or even in C++. For example try to embed two different structs in a union. The size of the union will be 0, 1 or 2 or ... In this news group I got help, thanks again, but it is a workaround only, not a straight way of development.

- references are often unpredictable. There are no easy way to determine whether an assignment DOES make content copy or NOT. It was a pain in my ass to debug buggy assignments where only references was counted and no content copy occured. The worst thing was to see a variable (array and class member) while it is just loosing it's value. It can't happen, but it does... Of course my code was buggy.

- memory leaks are almost undetectable in D (could cause problems which are extremly hard to debug). When I want to avoid the above "variable content disappearing" bug, I have to fill the code with ".dup" and it is a possible source of memory leak...

(I used Digital Mars compiler for C++ and I used Win32 platform. I do not use any tracing debugger, only printf.)

That's all from my (practical) point of view.

Tamas Nagy
Hungary