Portierung Code



  • Hallo,

    welche Änderungen müßte ich an einem C++ Code z.b. machen wenn ich ihn von Windows nach Linux portiere ? C++ ist ja nicht platformunabhängig da muss bestimmt was geändert werden ? Nur mal einige Beispiele.



  • blurry333 schrieb:

    C++ ist ja nicht platformunabhängig

    Doch. Standard-C++ jedenfalls.

    Spezielle Bibliotheken sind möglicherweise nur eingeschränkt nutzbar.



  • Doch, C++ ist plattformunabhaengig. Der Code, den Du damit schreibst ist - oft - plattformabhaengig. Zumindest, wenn Du nicht eine die Plattform abstrahierende Bibliothek, wie z.B. Qt nutzt.

    Um Deine Frage zu beantworten: Du muss GUI Code und plattformspezifische Klassen/Funktionen portieren.



  • blurry333 schrieb:

    welche Änderungen müßte ich an einem C++ Code z.b. machen wenn ich ihn von Windows nach Linux portiere ?

    Das hängt vom Code ab.

    blurry333 schrieb:

    C++ ist ja nicht platformunabhängig

    Doch, bis auf ein paar Libraries (vielleicht) schon.



  • In der Theorie nichts. Core-language, standard-library und boost sollten plattformunabhängig sein. Auf 3rd party libraries, z.B. windows.h musst du aber natürlich verzichten. Ein einfaches Konsolenprogramm, dass nur einen Algorithmus nutzt, sollte aber eigentlich plattformunabhängig sein.

    Praktisch musst du aber auf jede Menge aufpassen, hauptsächlich weil die Compiler jede Menge zusätzliche "Features" haben, die man beim programmieren unbewusst nutzt und die erst bei einem neuen Compiler auffallen. Die besten Fehlermeldungen und striktestens Sicherheitsvorkehrungen hat Clang, also es lohnt sich plattformunabhängigen Code mit Clang zu testen.

    Gerade bei casts musst du vorsichtig sein, aber nicht unbedingt wegen der "windows-linux" Kompatibilität, sondern wegen 32 und 64 bit.

    Strenggenommen gibt es noch jede Menge Sonderfälle, die man beachten muss, aber üblicherweise kann man davon ausgehen, dass man z.B. Zahlendarstellung im Zweierkomplement hat und

    auto a = static_cast<std::uint16_t>(-1)
    

    das Gleiche ist wie

    std::uint16_t a = 0xffff
    

    .

    EDIT: Schreibfehler korrigiert


  • Mod

    Marthog schrieb:

    Strenggenommen gibt es noch jede Menge Sonderfälle, die man beachten muss, aber üblicherweise kann man davon ausgehen, dass man z.B. Zahlendarstellung im Zweierkomplement hat und

    auto a = static_cast<std::uint16_t>(-1)
    

    das Gleiche ist wie

    std::uint64_t a = 0xffff
    

    .

    uint16_t != uint64_t
    Ansonsten schlechtes Beispiel weil nicht von der Zahlendarstellung abhängig. Diese Identität ist garantiert - mal abgesehen davon, dass die bloße Existenz der intNN_t Typen Zweikomplement impliziert 😉 C11 7.18.1.1



  • camper schrieb:

    mal abgesehen davon, dass die bloße Existenz der intNN_t Typen Zweikomplement impliziert 😉 C11 7.18.1.1

    Cool, das wusste ich gar nicht.


  • Mod

    dass die bloße Existenz der intNN_t Typen Zweikomplement impliziert

    Der Standard legt sich schon ganz allgemein auf Darstellungen fest

    this International Standard permits 2’s complement, 1’s complement and signed magnitude representations for integral types.


  • Mod

    Moment camper, dein Zitat stimmt doch gar nicht - es ist Paragraph 7.20.1.1.



  • Arcoth schrieb:

    dass die bloße Existenz der intNN_t Typen Zweikomplement impliziert

    Der Standard legt sich schon ganz allgemein auf Darstellungen fest

    this International Standard permits 2’s complement, 1’s complement and signed magnitude representations for integral types.

    Arcoth.
    Plural != Singular.
    Ja, der Standard legt sich ganz allgemein auf Darstellungen fest. Was bringt mir das wenn ich nicht dreifach Code schreiben will?



  • Hm, das ist mir noch nicht ganz klar.
    Wenn ein int32_t also ein 32 bit integer mit two's complement ist, ist dann auch das Verhalten bei overflow und underflow definiert?

    #include <cstdio>
    #include <cstdint>
    
    void func(std::int32_t i)
    {
    	if(i > i+1)
    		std::fputs("overflow\n", stdout);
    	else
    		std::fputs("no overflow\n", stdout);
    }
    

    compiler output:

    main.cpp: In function 'void func(int32_t)':
    main.cpp:6:11: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false [-Wstrict-overflow]
      if(i > i+1)
               ^
    

    Ist die Warnung richtig oder falsch?
    Laut assembler-output wird overflow hier wegoptimiert.



  • Der C++ Standard garantiert Overflow-Verhalten nur für unsigned Typen.
    Ob es da für die intXX_t ne Spezialregelung gibt, weiss ich nicht. camper wird's wissen 😉


  • Mod

    Arcoth schrieb:

    Moment camper, dein Zitat stimmt doch gar nicht - es ist Paragraph 7.20.1.1.

    naja fasst, wollte C99 schreiben, und hatte schon C11 aufgeschlagen


  • Mod

    hustbaer schrieb:

    Der C++ Standard garantiert Overflow-Verhalten nur für unsigned Typen.
    Ob es da für die intXX_t ne Spezialregelung gibt, weiss ich nicht. camper wird's wissen 😉

    Eine Spezialregelung wäre seltsam - zumal ja viele Rechnungen sowieso erst eine Promotion erfordern, bei denen dann eine solche Regelung ins Leere laufen würde. also: gibt's nicht



  • Ist dann nicht die two's complement Bedingung relativ sinnlos?


  • Mod

    Flashput schrieb:

    Ist dann nicht die two's complement Bedingung relativ sinnlos?

    wieso? Zweikomplement sagt etwas aus über die Darstellung (Repräsentation) negativer Zahlen und entsprechend den Wertebereich des Typs. Die Repräsentation ist nat. nur relevant, wenn der Typ mal byteweise gelesen wird oder durch den zugehörigen vorzeichenlosen Typen. Zweikomplement hat den Vorteil das Letzteres tatsächlich zum gleichen Ergebnis führt wie eine normale Konvertierung.

    Also

    int32_t x = -42; // irgendwas negatives
    uint32_t y = x;
    auto z = reinterpret_cast<uint32_t&>(x);
    assert(y==z); // nur bei Zweierkomplement
    

    in der umgekehrten Richtung steht wieder im Weg, dass die Konvertierung von vorzeichenlos in vorzeichenbehaftet implementation-defined ist, könnte also schiefgehen, praktisch wird es das nicht.



  • @camper
    Wenn dann würde es natürlich nur Sinn machen, wenn von Plattformen die intXX_t Typen anbieten verlangt wird, dass alle Integer-Typen das gewohnte Two's-Complement Überlaufverhalten zeigen.
    Und auch alle Konvertierungen.


Log in to reply