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.

C++ ist ja nicht platformunabhängig

Doch. Standard-C++ jedenfalls.

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

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

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.

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

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

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.

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.

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?

#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.

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

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?

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.