The Wiert Corner – irregular stream of stuff

Jeroen W. Pluimers on .NET, C#, Delphi, databases, and personal interests

  • My work

  • My badges

  • Twitter Updates

  • My Flickr Stream

    20140508-Delphi-2007--Project-Options--Cannot-Edit-Application-Title-HelpFile-Icon-Theming

    20140430-Fiddler-Filter-Actions-Button-Run-Filterset-now

    20140424-Windows-7-free-disk-space

    More Photos
  • Pages

  • All categories

  • Enter your email address to subscribe to this blog and receive notifications of new posts by email.

    Join 1,349 other followers

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.
2:48 AM

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.
3:09 AM

–jeroen

via: Entropy Overload: One-liner RAII in Delphi.

One Response to “There are reasons why Delphi is not C++ (via: Entropy Overload: One-liner RAII in Delphi)”

  1. WarrenP said

    And that’s why I’d turn down a job doing C++ for twice as much money as my Delphi job. Because C++ makes me scream.

    Warren

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

Join 1,349 other followers

%d bloggers like this: