visual Plattformübergreifenden C++-Code schreiben(Windows, Linux und Mac OSX)




vs code new class c++ (4)

Die Warnung liegt daran, dass Sie in Ihrer Testfunktion keine return haben, wenn keine der Definitionen tatsächlich definiert ist. Das Update dafür wird in eine Standardrendite gestellt.

Dies ist mein erster Versuch, etwas zu schreiben, das in C ++ etwas komplizierter ist. Ich versuche, eine gemeinsam genutzte Bibliothek zu erstellen, mit der ich über Objective-C und .NET-Apps kommunizieren kann (ok, dieser Teil kommt später ...).

Der Code, den ich habe, ist -

#ifdef TARGET_OS_MAC
  // Mac Includes Here
#endif

#ifdef __linux__
  // Linux Includes Here
  #error Can't be compiled on Linux yet
#endif

#ifdef _WIN32 || _WIN64
  // Windows Includes Here
  #error Can't be compiled on Windows yet
#endif

#include <iostream>

using namespace std;

bool probe(){
  #ifdef TARGET_OS_MAC
    return probe_macosx();
  #endif
  #ifdef __linux__
    return probe_linux();
  #endif
  #ifdef _WIN32 || _WIN64
    return probe_win();
  #endif
}

bool probe_win(){
  // Windows Probe Code Here
  return true;
}

int main(){

  return 1;
}

Ich habe eine Compiler-Warnung, die einfach untitled: In function 'bool probe()':untitled:29: warning: control reaches end of non-void function - aber ich wäre auch sehr dankbar für Informationen oder Ressourcen, die die Leute dazu vorschlagen könnten Schreiben Sie diese Art von Code besser ....


TARGET_OS_MAC , __linux__ , _WIN32 oder _WIN64 zum Zeitpunkt der _WIN32 noch _WIN64 definiert zu sein.

Ihr Code war also wie folgt:

bool probe(){
}

Deshalb beschwert sich der Compiler über das Erreichen des Endes einer Non-Void-Funktion. Es gibt keine return .

Für die allgemeinere Frage sind hier meine Richtlinien für die Entwicklung von Multiplattform- / Architektur-Software / Bibliotheken:

Vermeiden Sie Sonderfälle. Versuchen Sie, einen Code zu schreiben, der OS-unabhängig ist.

Versuchen Sie beim Umgang mit systemspezifischen Dingen, Dinge in "undurchsichtige" Klassen zu packen. Wenn Sie sich beispielsweise mit Dateien befassen (verschiedene APIs unter Linux und Windows), versuchen Sie, eine File Klasse zu erstellen, die die gesamte Logik einbettet und unabhängig vom Betriebssystem eine gemeinsame Schnittstelle bereitstellt. Wenn eine Funktion auf einem der Betriebssysteme nicht verfügbar ist, beheben Sie diese: Wenn die Funktion für ein bestimmtes Betriebssystem keinen Sinn ergibt, ist es häufig in Ordnung, überhaupt nichts zu tun.

Kurz gesagt: #ifdef weniger #ifdef besser. Und egal wie portabel Ihr Code ist, testen Sie ihn auf jeder Plattform, bevor Sie ihn veröffentlichen.

Viel Glück ;)


Anstatt sich zu wiederholen und immer wieder die gleichen #ifdef .... -Zeilen zu schreiben, ist es vielleicht besser, die probe () -Methode in einem Header zu deklarieren und drei verschiedene Quelldateien bereitzustellen, eine für jede Plattform. Dies hat auch den Vorteil, dass Sie beim Hinzufügen einer Plattform nicht alle vorhandenen Quellen ändern, sondern nur neue Dateien hinzufügen müssen. Verwenden Sie Ihr Build-System, um die entsprechende Quelldatei auszuwählen.

Beispielstruktur:

include/probe.h
src/arch/win32/probe.cpp
src/arch/linux/probe.cpp
src/arch/mac/probe.cpp

Die Warnung ist, weil probe () keinen Wert zurückgibt. Mit anderen Worten, keiner der drei #ifdefs stimmt überein.


Ich werde diese spezielle Funktion ansprechen:

bool probe() {
#ifdef TARGET_OS_MAC
  return probe_macosx();
#elif defined __linux__
  return probe_linux();
#elif defined _WIN32 || defined _WIN64
  return probe_win();
#else
#error "unknown platform"
#endif
}

Wenn Sie es auf diese Weise als Kette von if-elif-else schreiben, wird der Fehler beseitigt, da es unmöglich ist, es zu kompilieren, ohne eine gültige return-Anweisung oder den Fehler # zu treffen.

(Ich glaube, WIN32 ist sowohl für 32- als auch für 64-Bit-Windows definiert, aber ich kann es Ihnen nicht definitiv sagen, ohne es nachzuschlagen. Das würde den Code vereinfachen.)

#Ifdef _WIN32 || kann leider nicht verwendet werden _WIN64: Eine Beispielfehlermeldung finden Sie unter http://codepad.org/3PArXCxo . Sie können wie oben den speziellen, nur für die Vorverarbeitung definierten Operator verwenden.

In Bezug auf das Aufteilen von Plattformen nach Funktionen oder ganzen Dateien (wie suggested ) möchten Sie dies möglicherweise oder möchten dies möglicherweise nicht. Dies hängt unter anderem von den Details Ihres Codes ab, z. B. davon, wie viel zwischen den Plattformen geteilt wird und was Sie (oder Ihr Team) für am besten halten, um die Funktionalität synchron zu halten.

Darüber hinaus sollten Sie die Plattformauswahl in Ihrem Build-System handhaben. Dies bedeutet jedoch nicht, dass Sie den Präprozessor nicht verwenden können. Verwenden Sie Makros, die für jede Plattform (durch das Makefile oder das Build-System) bedingt definiert sind. Tatsächlich ist dies die häufig praktischste Lösung mit Vorlagen und Inline-Funktionen, die flexibler ist als der Versuch, den Präprozessor zu entfernen. Es lässt sich gut mit dem Gesamtdateiansatz kombinieren, sodass Sie diesen bei Bedarf immer noch verwenden.

Möglicherweise möchten Sie einen einzigen Konfigurationsheader haben, der alle verschiedenen compiler- und plattformspezifischen Makros in bekannte und verständliche Makros übersetzt, die Sie steuern. Sie können der Compiler-Befehlszeile auch -DBEAKS_PLAT_LINUX über Ihr Build-System hinzufügen, um dieses Makro zu definieren (denken Sie daran, ein Präfix für Makronamen zu verwenden).







cross-platform