There are reasons why Delphi is not C++ (via: Entropy Overload: One-liner RAII in Delphi)
Posted by jpluimers on 2012/06/06
There was a nice short discussion on Entropy Overload where Ivan Levanshew seemed to want to be Delphi way more C++ and Barry Kelly explains why Delphi isn’t C++.
Both Delphi and C++ are great languages, but both have weaknesses too. It is good that their individual strengths complement each other, and their weaknesses don’t crossover too much.
Ivan Levashew said…
It’s XE2 now, and there is still no proper RAII despite Delphi runtime already having all the required functionality for years. Variants copying and destruction is an example.
It’s a pity.
I can’t understand why can’t I declare record destructors and copying constructors. Interfaces and variants have a drawback: they are not initialized at all. I mean, I’d like to write MyEntity.MyFunction without ensuring that MyEntity has been initialized properly.
I have to wrap interface into record and use record methods that forward my requests to the interface field. They also initiallize this field on first access and invoke EnsureUnique on every subsequent accesses.
For me this is in the category “Be careful what you wish for, you may receive it”, so I was glad that Barry answered this:
Barry Kelly said…
Ivan: I don’t think a free-for-all on copy constructors, assignment operators and friends like in C++ would be a positive development at all.
It opens up too much of the underlying mechanics of the compiler. Very low level semantics around when and where exactly copies get created and destroyed become exposed and get depended on. People get upset at lack of optimizations on one hand (e.g. redundant copies, long a problem in C++), and unpredictable user code execution on the other (C++ exception safety woes). It’s very difficult – far too difficult – to write correct semantics for making a value type work properly in all situations. So I’m reluctant to support anything much more complicated than compiler help for reference counting.
You complain about not being able to ensure MyEntity has been initialized properly; I presume you mean default constructors. I think they are a terrible idea, for any value of default construction other than zero initialization. The issues around creating arrays of the things (needing to keep track of how far construction got), how objects get initialized, handling exceptions in the default constructor, leads to horrific abominations like C++ constructor and function exception handlers.