• MicroWizard (60/60) Feb 12 2005 Hi!

MicroWizard <MicroWizard_member pathlink.com> writes:

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