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.
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.)
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
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.
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.
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.
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.
Related
I have looked at some of the info on cross platform design. I can't find the answer to one question I have however.
What I would like to do is design my UI's in Delphi (Windows) and X-Code (Mac) with the underlying guts of the program being OS agnostic C++ code. Is this possible to achieve? I see lots of talk about Cross Platform Compilers, Frameworks and GUI tools but I really want to keep the interfaces 100% native.
Please forgive me if this an absurd question but I am relatively new to the world of programming and learning along the way. My company has an extensive catalog of Delphi applications for windows developed over the past 15 years and Delphi is where I have spent most of the last year.
If you are comfortable working with Object Pascal take a look to the FreePascal compiler and Lazarus which is a free cross-platform IDE (available for Windows, Linux, Mac OS X).
You should have a look at wxWidgets http://www.wxwidgets.org/ for programming 100%-native.
From my point of view I can't see the benefit of using two different and specific gui designers for two (or more) target platforms. It should be easy to share the code if the platform specific parts are clearly separated in your architecture. wxWidgets gives you the ability to use the same gui definition in both platforms without loosing the native character.
Personally, I wouldn't use C++ for UI design anymore. But why are you using two IDE's? I suggest to use a more abstract language (like Java with Netbeans/Eclipse or even better C#/.Net with VS/Blend) for this UI/event/interaction stuff keeping only some specific parts in an native optimized binary code.
.Net/Mono can use differnt toolkits for the ui style. Today, being "native" within the context of UX and look and feel does mean to follow system specific guidelines, I think.
This could be reached by views and adpaters (see google for some design pattern).
Look and feel is just a point of styling an app and it could be a native looking style, too. In the WPF-world handles are used only for the host window (and some legacy compatibility reasons using windows forms) but the user won't feel the differenc if you are styling your app like the former win-api-ones.
Qt has also an platform independent approach for the C++-world but is not really native. Qt draws its own controls with a native look and feel (if needed) and comes also with the option to use/share one definition of the UI between different platforms.
Your question is not absurd by any means - you're looking for the solution to a problem we've all been dealing with for many years - how to achieve cross platform compatibility and code reuse. But perhaps there are some points that you need clarification on:
As others have said, C++ is not the only 'OS agnostic' language - in fact most languages are 'OS agnostic' - what normally isn't (and cannot be) OS agnostic is the compiler, the GUI libraries etc. Pascal, C++, Python, C#, Java and many others have SDK's for various OS's, much of it open source.
If for some reason you are set on C++, check out Embarcedaro C++ - a Delphi clone using C++ instead of Object Pascal.
And IMO you should investigate Qt: http://doc.qt.nokia.com/latest/index.html - Qt is an excellent 'OS agnostic' framework that includes GUI widgets as well as many other powerful libraries that span pretty much the whole scope of modern PC computing.
Although c++ is the native language for Qt development, there are quite a few 'language bindings' available to make Qt programming possible with other languages. (varying degrees of functionality are supported depending on the binding implementation) I understand there is an Object Pascal language binding for Qt using Lazarus - I haven't tried it yet but it sounds very interesting.
Also, a word of caution: separating your GUI from the 'underlying guts' of your application such that it is OS agnostic can be quite challenging in complex applications - I think a good place to start is by reading up on the MVC paradigm.
HTH
I'm considering learning Objective-C and Cocoa, mostly in order to use Apple's tools and GUIs.
However, I'd also like to do some graphics programming; OpenFrameworks and Cinder are two libraries which catch my eye, but then we're in C++ land.
I come from a Java/Swing/Processing background... don't know much about the C family. How effectively can you call C and C++ libraries, like Cinder and OF, from native Cocoa?
And, bonus points: would a solution like this work on an iPhone or iPad?
In short, C++ is just fine for OS X and iOS programs, and plays with Objective-C quite nicely.
In more detail:
However, I'd also like to do some graphics programming; OpenFrameworks and Cinder are two libraries which catch my eye, but then we're in C++ land.
I won't speak for those libraries directly.
To answer your question in more general terms: C++ is just fine in your app, since C, C++, ObjC, and ObjC++ are first class development languages for iOS apps.
I come from a Java/Swing/Processing background... don't know much about the C family. How effectively can you call C and C++ libraries, like Cinder and OF, from native Cocoa?
Objective-C++ allows you to use C, C++, and Objective-C all in the same translation. Feel free to use/combine C++, C, or ObjC where needed. The compile times will increase, and there are some restrictions* if you take this route. Otherwise, support is very good. Even Apple uses a good amount of C++ in their apps/libs.
And, bonus points: would a solution like this work on an iPhone or iPad?
Definitely. c++11 support for iOS and OS X is currently a bit behind. However, the clang team's been adding support for it very very quickly. There will likely be some bumps if you want the latest features, so I'd say hold back on bleeding edge C++ and compiler features if your project depends on it. Of course, it does not hurt to sample your program using the latest clang features with each release in order to determine how well it works with your programs.
Update: At this point (Nov 8, 2011) clang can handle nearly all of the C++ 2003 code I throw at it. Code speed and size does vary compared to GCC+LLVM. I would not want to drop either at this point, but both compilers work well for me with C++ 2003, and Apple's GCC will not support c++11, so it's a good time to start testing clang if you want c++11 features in the near future.
C++ is ideal (IMO) for general performance critical development on iOS, as long as your team knows how to use it.
Mixing C, ObjC and C++ is very powerful if you use the right features of each language for the right reasons, and good compatibility exists. This reaches back years from OS X (although the compiler was GCC at the time).
*restrictions: these are reasonable restrictions - all the features you need exist, but there are some things that people may expect which are not possible. the most common is likely the inability to derive types of different object models. that is, you cannot reasonably not create a c++ type from an objc type, but you can freely declare ivars of multiple types in either object type.
It is possible to use both OpenFrameworks and Cinder in iOS applications (see this related SO question: OpenGL ES, OpenFrameworks, Cinder and IOS creative development), though Apple "prefers" developers to use OpenGL.
As of now you can use Cinder from within a typical Cocoa project via the new CocoaCinderGL wrapper. It lets you add several NSCustomView's to your application, each one running an independent "instance" of Cinder. And obviously you can connect as many NSButtons, NSSliders as you like to those instances. Hope that helps!
Considering Simon Mourier's answer to this question:
Processing Microsoft Office Outlook 2003/2007 email messages…
I plan to use the PST File Format SDK which is written in C++.
I would take this opportunity to learn more about C++ and to renew with it, since it's been quite 15 years since the last time I used it. I have already downloaded and configured Boost 1.45 which is required to work with pstsdk.
Now, I'm currently writing a Windows Forms application using CLR C++ and plan to use the pstsdk to read from PST files.
Does it matter in any way that I'm using both CLR C++ and pure C++ altogether?
Shall I consider using it a different way, or is this okay?
If you want to use a .NET (Windows Forms, or maybe even the newer WPF) user interface, the simplest approach is to build an object model in C++/CLI, implemented in terms of the native code but having a .NET interface.
Then write the UI in C# and call the C++/CLI object model (which differs from using the .NET base class library in only one way -- you have to add a reference to the C++/CLI assembly... but the C++/CLI compiler will create all the metadata that C# uses).
You can mix managed and unmanaged code, but it will be a pain to marshal everything except the built-in types across the boundaries. It's much easier to stay with more powerful unmanaged C++. You could use CodeGear C++ Builder for example (or QT). The problem with CodeGear is compiler isn't that great, so you won't be able to compile everything from Boost, but you might not need that.
C++/CLI is intended to interop with unmanaged C++- that's pretty much it's entire purpose. However, I feel that it's probably easier to write in C# if you need .NET for, say, WPF, which is an excellent technology, and just use C++/CLI for interop.
I'm just starting my first C++ project. I'm using Visual Studio 2008. It's a single-form Windows application that accesses a couple of databases and initiates a WebSphere MQ transaction. I basically understand the differences among ATL, MFC, Win32 (I'm a little hazy on that one actually) and CLR, but I'm at a loss as to how I should choose.
Is one or more of these just there for backward-compatibility?
Is CLR a bad idea?
Any suggestions appreciated.
Edit:
I've chosen C++ for this project for reasons I didn't go into in the post, which are not entirely technical. So, assuming C++ is the only/best option, which should I choose?
It depends on your needs.
Using the CLR will provide you with the most expressive set of libraries (the entire .NET framework), at the cost of restricting your executable to requiring the .NET framework to be installed at runtime, as well as limiting you to the Windows platform (however, all 4 listed technologies are windows only, so the platform limitation is probably the least troublesome).
However, CLR requires you to use the C++/CLI extensions to the C++ language, so you'll, in essense, need to learn some extra language features in order to use this. Doing so gives you many "extras," such as access to the .net libraries, full garbage collection, etc.
ATL & MFC are somewhat trickier to decide between. I'd refer you to MSDN's page for choosing in order to decide between them. The nice thing about ATL/MFC is that you don't need the .NET framework, only the VC/MFC runtimes to be installed for deployment.
Using Win32 directly provides the smallest executables, with the fewest dependencies, but is more work to write. You have the least amount of helper libraries, so you're writing more of the code.
Win32 is the raw, bare-metal way of doing it. It's tedious, difficult to use, and has a lot of small details you need to remember otherwise things will fail in relatively mysterious ways.
MFC builds upon Win32 to provide you an object-oriented way of building your application. It's not a replacement for Win32, but rather an enhancement - it does a lot of the hard work for you.
System.Windows.Forms (which is what I assume you meant by CLR) is completely different but has large similarities to MFC from its basic structure. It's by far the easiest to use but requires the .NET framework, which may or may not be a hindrance in your case.
My recommendation: If you need to avoid .NET, then use MFC, otherwise use .NET (in fact, in that case, I'd use C# as it's much easier to work with).
As far as C++ goes, I would use WTL. It's lightweght and you will have few (if any) dependencies, making it easy to ship and install. I find it very satisfying when my app consists of a single EXE that will run on most versions of Windows, but this may not be a concern to you.
If you choose to go .NET instead, then C# is almost certainly the way to go.
More in WTL here:
http://www.codeproject.com/KB/wtl/wtl4mfc1.aspx
I would be very curious as to why you would do this in C++ at all. Based on your brief description, C# sounds like a much more appropriate choice.
Just to elaborate a bit, look at the link you gave describing the C++ CLR. The top rated answer notes (accurately, in my opinion) that C++ is appropriate for "kernel, games, high-performance and server apps" - none of which seems to describe what you're doing.
MFC, ATL, etc are going to be supported in the sense that, yes you'll be able to compile your app on future versions of Visual Studio and run them on future versions of Windows. But they're not supported in the sense that there's not a lot of new development going on in the API or the language the same way there is in the CLR and C#.
There is nothing wrong with CLR. Like others here I'd suggest C# but as you have reasons for sticking with C++ then using the .NET framework is several thousand times easier than messing with ATL/MFC if you're not already familiar with them (IMO).
It may be worth mentioning that if you're using C++/CLR then you're not really using C++ at all. C++/CLR compiles to CIL just like C#. I've never used it myself but I believe its purpose is to allow you to compile legacy code and make it easily available to new .NET code rather than allow new code work with old C++ executables. There are other methods of calling native code from .NET which, perhaps, you should explore.
The modern (2021) answer to this question would appear to be to use C++/WinRT instead of C++/CLR (or C++/CLI or C++/CX... jeez Microsoft):
https://learn.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt
C++/WinRT is an entirely standard modern C++17 language projection for Windows Runtime (WinRT) APIs, implemented as a header-file-based library, and designed to provide you with first-class access to the modern Windows API. With C++/WinRT, you can author and consume Windows Runtime APIs using any standards-compliant C++17 compiler.
...
C++/WinRT is Microsoft's recommended replacement for the C++/CX language projection
It's basically standard C++ but the UI is defined with XAML.
Still though, as with the other answers, it would appear that using C# is really microsoft's favorite approach. C++/WinRT really looks like it's almost C# anyways.
Are their any libraries which provide functionality similar to mono but for the c++ language? I know boost exists, but I like mono much more than boost.
I'm looking to do more than what's available in the base library set, like play sound more easily (crossplatform), GUI, load images, time, etc. I guess I am looking for what people might consider an engine or a large library.
Mono is a .NET implementation. Mono is NOT a library.
There is NO Mono for C++. At least, not yet.
I think you want a multi-platform framework, such as Qt
If you're wanting to work with Managed C++ a la .Net, then you would just use Mono. They have a page describing how to go about it. The only catch is that you have to compile on Windows, as there is not yet any flavor of GCC that outputs .Net CLI for C++.
To be honest, though, if you're going to use Mono, you might as well move into C#. It's a much cleaner language, IMO.
CLI is only able to host C++ compiled code on all supported platforms as long as the compiled code only contains CIL not native code.
for more detail visit
http://www.mono-project.com/CPlusPlus
I'm not sure about your precise requirements, but in terms of large multi-purpose packages: Qt has been mentioned by a few folks. wxWidgets (formerly wxWindows) is another option. GTK is multiplatform.
As you use the word "engine" (often a game-related term), you might be interested in SDL, which has been used by numerous games, professional and amateur alike. SFML is an option. ClanLib is another long-lived library I've heard of, though I'll admit to knowing little about it.
Try the STL collections...Has nothing to do with .NET, but they are a nice collection of collections (lol) and make C++ life easier.
It sounds like what you are really looking for is a C++ framework that offers the kinds of functionality found in the .NET/Mono framework. Qt is a popular choice.
On the topic of C++ interoperability, Mono has recently made some pretty big strides with CXXI.
(From this posting): The short story is that the new CXXI technology allows C#/.NET developers to:
Easily consume existing C++ classes from C# or any other .NET
language
Instantiate C++ objects from C#
Invoke C++ methods in C++ classes from C# code
Invoke C++ inline methods from C# code (provided your library is compiled with -fkeep-inline-functions or that you provide a surrogate
library)
Subclass C++ classes from C#
Override C++ methods with C# methods
Expose instances of C++ classes or mixed C++/C# classes to both C# code and C++ as if they were native code.
CXXI is the result of two summers of work from Google's Summer of Code towards improving the interoperability of Mono with the C++ language.