views:

2685

answers:

7

I have an application written in Delphi that compiles in Delphi 2007. I think it was originally written in Delphi 7.

Anyway, I need to convert all the core non-GUI code into C++ because I want to release a Mac version of the software.

What is the best way to do this? Any shortcuts I can take to speed up the process?

EDIT: The code compiles to native code, not .NET.

A: 

If your code compiles in Delphi 2007 into .NET assemblies, you may have a much easier option than trying to port from Delphi's object pascal to C++.

You could potentially compile your logic into .NET assemblies (and maybe even portions of the UI), and use Mono to run it on Mac. You could write a custom GUI around Mono, or even potentially make a single, platform independent application.

Reed Copsey
The project compiles to native code. I don't want to use .NET for this. The core code is fairly simple. It processes large amounts of binary data.
Dana Holt
If that's the case, you're probably in for a hand-written port to C++. Neil's post regarding things to watch for in the port is probably very relevant, then.
Reed Copsey
+3  A: 

I think this would be difficult to do mechanically, so you are probably looking at a complete re-write. One thing to bear in mind is that typically Delphi uses try...finally structures for resource management, whereas C++ uses a technique known as RAII (resource acquisition is initialisation). You should read up on this and other C++ idioms before you attempt the conversion.

anon
+9  A: 

Why not just use an OS X Delphi compiler? Free Pascal claims to support Delphi on OS X (though not being a Pascal coder I haven't tried it).

Chris Lutz
I did not know about the Free Pascal compiler. I will check it out. Thanks.
Dana Holt
I didn't either until I checked with our Father who art in Heaven, Wikipedia.
Chris Lutz
Although not without it's differences this is great advice. I've successfully used lots of non-gui "delphi" code on windows, os x and linux with only trivial changes.
RobS
Lazarus also supports OS X, but still uses Carbon.
Marco van de Voort
A: 

The "correct" way to do this is to rewrite it in Objective C. I find Objective C a little weird, but there are a lot of similarities with Delphi in the way objects connect and delegate.

You may be able to use Free Pascal to do it more quickly, but you should seriously consider a rewrite.

I would be in love with Embarcadero if they could release a Mac OS X version of Delphi that didn't, you know, suck like Kylix did. One can dream.

Edit: There is a great benefit to staying in Delphi, and having a separate version for the Mac in Objective C. First, it means you don't need to rewrite the version on Windows, losing the (presumably) years of investment in Delphi code. Second, Mac software operates differently than Windows, from a UI perspective. A simple port of the product is inappropriate, and hobbles the developer from using the great native features of Windows and Mac. See: older versions of MS Word for Mac, or iTunes for Windows. They look and feel wrong.

Tim Sullivan
Presumably, he or she wants to convert to C++ so the core code will be usable on Windows AND Macintosh. Rewriting in Objective C doesn't really help with that goal, does it? It would just be trading one platform-specialized language (Delphi, Windows) for another (Objective C, Mac).
Rob Kennedy
@Rob K: Correct, I want to use the same C++ code in the PC and Mac versions.
Dana Holt
@Rob K - Objective C is compiled via an open-source front-end GCC, which runs on Windows. You can write Objective C programs that work on Windows. You just can't use all of Apple's nice interface stuff.
Chris Lutz
Yes, and to fund this, the Mac product will become several times more expensive, in line with general Mac pricing.Seriously, unless you exclusively target the Mac market, a totaly rewrite Objective C is usually way to expensive.
Marco van de Voort
+6  A: 

Simple answer: You simply can't port non-trivial Delphi code to C++ without a complete rewrite. C++'s object model is very different from Delphi's. It doesn't have a base class like TObject from which all other objects are derived, and it lacks support for a lot of the RTTI stuff that Delphi code often takes for granted. And there's no simple way to reimplement Delphi RTTI in C++, since a lot of it's done at the compiler level, and a lot of it's based on the fact that all Delphi classes descend from TObject.

C++ also lacks support for the concept of unit initialization and finalization sections that are so common in Delphi, and what it has instead is badly broken. (Look up the "static order initialization fiasco" for all the gory details.)

Delphi's exception handling is also much more advanced than C++'s. Part of this is the object model and part of it's compiler magic. Plus, C++ has no support for the try-finally construct.

If you want to port a Delphi project to the Mac, Free Pascal is your best solution. It's not 100% compatible with Delphi, but it's good enough for a lot of things, and you specifically mentioned that you don't need to port the Delphi GUI stuff. AFAIK the GUI area is the source of most of FPC's compatibility weaknesses, so if that's not necessary, FPC is probably pretty close to ideal for your needs, at least until CodeGear gets an OSX compiler out. (Which hasn't been officially announced, but based on various things that have been said it's not unreasonable to suppose that one will be available sometime next year.)

Mason Wheeler
Questions/comments from a C++ developer - 1. "Badly broken" isn't really accurate, lazy loading singletons take care of static order initialization with just a bit of attention. 2. In what way is Delphi's exception handling more advanced than C++?
Josh Kelley
1. Lazy loading works until you have to dispose of non-memory resources when closing the singletons. The destructor never gets called, and handles get leaked. The workarounds for this problem are non-trivial and tend to create other, even worse problems.
Mason Wheeler
2. Where do I even start? Catching exceptions always works on the true type of the exception that was raised; you don't have to jump through hoops to "throw polymorphically" and "catch polymorphically." Raising an exception while there's another one active doesn't call Terminate().
Mason Wheeler
Exception objects always contain RTTI that can be easily examined when you catch them, making it trivial to retrieve information about the nature of the exception. Exceptions raised in constructors work much better because objects are initialized to a known state before calling the constructor.
Mason Wheeler
I could go on, but those are the main points. To put it bluntly, C++ exception handling just sucks in general, and Delphi gets it right.
Mason Wheeler
Thanks for the info. Although singletons' destructors should still get called in C++ as long as you code them properly, so I don't see the problem there...
Josh Kelley
A: 

You can use also Delphi Prism. It's for .NET, but it's the last expression in Delphi language spec. It supports also Mac OSX (see the link). Also the guys from CodeGear/EMBT are in the works for a new compiler as well as for a new version of Delphi which is expected to enter in beta in April and narrow the gap between Prism and RAD studio. See their 'Beta Programs' page.

Prism is a totally different dialect. There is some pedigree, but it is quite different. I don't see how you can narrow the gap without breaking compatibility and lose a lot of users.
Marco van de Voort
+1  A: 

For converting your code from Delphi to Cpp, have a look at

http://ivan.vecerina.com/code/delphi2cpp/.

I used this to convert some of the classes and functions in SysUtils, DateUtils and StrUtils using wxWidgets functions. If you are planning to use wxWidgets for C++ have a look at http://twinforms.com/products/wxwidgets/wxvcl.php which has all the converted source.

If you want directly develop Mac OSX applications using then have a look at wxForms for Delphi - http://twinforms.com/products/wxformsdelphi/index.php