Cross-Plattform Objective-C/C++ Entwicklung

Question

Ich arbeite in einem Team von Entwicklern, einer von uns arbeitet speziell unter Windows, und ich arbeite hauptsächlich in Mac OS X. Wir wollen C-basierte Anwendungen entweder in C++ entwickeln oder Objective-C, aber ich weiß nicht genau, wie man mit einem plattformübergreifenden Entwicklungsprojekt vorgeht.

Kann ich in C++ mit Mac OS X arbeiten? Offensichtlich sind sie auf Objective-C ausgerichtet, unterstützen C++ aber genauso gut. Wie sieht es mit der plattformübergreifenden Entwicklung in diesen Sprachen aus? Ich würde etwas wie Boost und eine Art UI-Bibliothek verwenden.

Hat jemand Erfahrung in der Entwicklung für mehrere Plattformen und kann Anwendungen dennoch nativ ausführen, ohne dass eine VM erforderlich ist?

BEARBEITEN: Es gibt viele Antworten, die ich jetzt als richtig markieren möchte. Es scheint, als ob Qt der Weg ist, um es in C++ zu entwickeln. Die Wahrscheinlichkeit ist groß, dass dies für * nix, OS X und Windows der Fall sein wird, was für uns persönlich die beste Option wäre. Wenn ich es vermeiden kann, Objective-C zu schreiben, dann bleibt das Team bei C++, umso besser. Wenn ich die GUI in Objective-C schreiben und mischen und abgleichen muss, dann ist das auch nicht zu viel Mühe.

Answer 1

You could look at Qt. Ich habe es erfolgreich in Windows, Linux und Mac OSX Projekten verwendet.

Answer 2

Ist es möglich, in C++ mit Mac OS X zu arbeiten? Offensichtlich sind sie auf Objective-C ausgerichtet, unterstützen C++ aber genauso gut.

Ja, gibt es.

Mit C++ in OS X können Sie so gut wie alles machen, was Sie wollen - alles, was Sie mit C++ unter Linux machen können. Es gibt Unterstützung für den C++ - Compiler, C++ - Bibliotheken und alle anderen. Xcode bietet Unterstützung für die Arbeit mit C++.

Sie können sogar C++ mit Objective-C mit Objective-C++ mischen (Beachten Sie jedoch, dass dies für GUI-Arbeit nicht portierbar ist).

Wie sieht die plattformübergreifende Entwicklung in diesen Sprachen aus? Ich würde etwas wie Boost und eine Art UI-Bibliothek verwenden.

Ich glaube, dass Ihre beste Wette QT ist.

Es ist eine stabile C++ - Bibliothek, die plattformübergreifend ist (Windows, OSX, Linux und mehr), gibt es seit über einem Jahrzehnt, ist gut unterstützt, mit vielen kommerziellen Anwendungen geschrieben (Skype, Adobe Photoshop Album) und eine Tonne Open-Source-Material, das damit geschrieben wurde (der KDE-Desktop für Anfänger). Neben GUI-Sachen bietet es eine ganze Menge mehr (Container-Klassen, XML, Datenbank-Konnektivität, etc.).

Sie können sowohl Open Source als auch proprietäre (Closed Source) Apps kostenlos mit dem neuesten QT entwickeln, und die Bibliothek wurde kürzlich von NOKIA, einem großen multinationalen Unternehmen, gekauft, so dass es in absehbarer Zeit nicht verschwinden wird.

Neben der Bibliothek enthält QT auch eine IDE und einen Visual Forms Designer (alles kostenlos).

Andere plattformübergreifende GUI-Bibliotheken für C++ gibt es auch für OS X (wxWidgets, gtkmm, et al).

Answer 3

Ich arbeite für ein Softwareunternehmen, das Software für Mac OS X und Windows mit C++, MFC und Objective-C erstellt.

Ja, es ist definitiv möglich.

Sie werden wahrscheinlich am besten bedient, wenn Sie den "Kern" der Anwendung in C++ entwickeln. In einer MVC-Anwendung wäre der C++ - Teil das Modell und möglicherweise die Controller. Für den Code, der mit der GUI und anderen Betriebssystem-spezifischen Schnittstellen verbunden ist, sollten Sie die nativen APIs verwenden: Objective-C unter Mac OS X und C# unter Windows XP.

Das Gute am Mac ist, dass Sie C++ und Objective-C zusammen kompilieren können. Sie können sogar Objective-C++ verwenden, wobei C++ und Objective-C in derselben Kompilierungseinheit kompiliert werden. Leider kann man das nicht mit C# machen (es gibt etwas namens Managed C++, das ein anderes Biest ist).

Ich würde Cross-Plattform-Frameworks wie Qt und WxWidgets vermeiden. Mit ihnen können Sie plattformübergreifende Anwendungen entwickeln, aber das Erscheinungsbild solcher Anwendungen ist unterdurchschnittlich. Ich bin mit wxWidgets vertrauter, sein Design ist jedoch stark auf das Windows MFC-Paradigma des Anwendungsdesigns ausgerichtet.

bearbeiten 14. Mai 2009, 09.44 Uhr EST: Wenn jetzt Qt wahr Look and Feel der nativen Plattform ermöglicht es, könnte es eine gute Option sein. Ich habe mir das neueste Angebot noch nicht angesehen, daher sollten Sie sich dieses Framework ansehen, bevor Sie Ihr eigenes entwerfen. Diese Entscheidung sollte getroffen werden, nachdem die Ergebnisse der Anwendungen untersucht wurden und wie komfortabel Sie mit den von Qt benötigten Design-Paradigmen sind.

Answer 4

was ich benutze, ist eine gemeinsame Bibliothek in C oder C++ mit allen Kernfunktionen Ihrer Anwendung geschrieben.

Angenommen, Sie bauen ein Solitaire-Spiel. Sie werden Kernklassen in einer reinen C++ - Bibliothek (meist plattformunabhängig) haben.

• CoreSolitaire

Dann werden Sie separate UI-Projekte haben, eine für jede Plattform, die Sie auf Ihrem Solitär bereitstellen möchten:

• iSolitaire (Objective-C, Multitouch Cocoa Basierend für iPhoneOS)
• MacSolitaire (Objective-C, Cocoa Basierend für Mac OS X)
• WinSolitaire (C++, Win32 oder C# Basierend für Windows PLAF orms)
• GSolitaire (C++, Gnom/GTK basiert für Linux/Unix)

Es ist mehr Arbeit, aber meiner Meinung nach ist das resultierende Produkt ist auf jeden Fall besser als eine Sie unabhängig durch die Verwendung einer Plattform bekommen könnte Widget-Set wie QT oder wxWidgets.

Wenn Sie das Produkt intern in einem Unternehmen bereitstellen, in dem Sie die vollständige Kontrolle über die Implementierungsumgebung haben, ist es Ihnen egal, wie sich das resultierende Produkt auf verschiedenen Plattformen verhält könnte definitiv eine gemeinsame API für alles verwenden (QT, wxWidgets oder andere, die Sie möglicherweise treffen).

Answer 5

Hat jemand Erfahrung in bekam noch für mehrere Plattformen entwickeln Anwendungen ermöglichen eine VM nativ ohne die Notwendigkeit zu laufen?

Etwas. Stellen Sie sicher, dass Sie den gesamten plattformspezifischen Code umschließen. Auf diese Weise müssen Sie als Hauptanwendung oder Bibliothek den plattformspezifischen Code nicht referenzieren. Das sollte es beim Portieren auf eine andere Plattform viel einfacher machen.