| C++ | Doch multiple platform fähig?
- Themenstarter Ingolo
- Beginndatum
bk75
Mitglied
Wenn eine Firma meint sie entwickelt plattformunabhängigen C++ Code dann bedeutet das folgendes:
a) Man hält sich an einen strengen aber problemlosen C/C++ Sprachstandard, der sich überall compilieren lässt.
b) Systemspezifische Aufrufe werden funktional in Klassen unterteilt und müssen pro Betriebssystem einfach nur passend entwickelt werden. Für GUIs könnte man zB WXWidgets nehmen. Systemaufrufe werden komplett in eigene Klassen gepackt und deren Verhalten per Spezifikation für ein Projekt vorher festgelegt.
Noch ein Wort zu Assembler. Die meisten Compiler übersetzen den Programmcode in Befehle für den Prozessor. In der Praxis benutzt man meistens eine normale Programmiersprache und ruft ASM-Routinen von dort auf. Als Entwickler muss man dafür sorgen, äquivalenten C Code zu generieren um für diverse Architekturen Alternativen zu haben. Auch das lässt sich alles über Compileroptions und Regeln klären. Wenn man direkt in ASM programmiert, ist man der Sprache C obwohl sie sehr hardwarenah ist von der Performance her weit überlegen - dazu muss man aber die CPU Befehle gut kennen. Wenn man sich in ASM auf eine Architektur einigt, zB 32-Bit (=IA32) kann man dort ebenfalls plattformunabhängig arbeiten, indem man statt INT-Calls auch hier wieder eine eigene Funktionssammlung aufruft die passend eingelinkt wird.
a) Man hält sich an einen strengen aber problemlosen C/C++ Sprachstandard, der sich überall compilieren lässt.
b) Systemspezifische Aufrufe werden funktional in Klassen unterteilt und müssen pro Betriebssystem einfach nur passend entwickelt werden. Für GUIs könnte man zB WXWidgets nehmen. Systemaufrufe werden komplett in eigene Klassen gepackt und deren Verhalten per Spezifikation für ein Projekt vorher festgelegt.
Noch ein Wort zu Assembler. Die meisten Compiler übersetzen den Programmcode in Befehle für den Prozessor. In der Praxis benutzt man meistens eine normale Programmiersprache und ruft ASM-Routinen von dort auf. Als Entwickler muss man dafür sorgen, äquivalenten C Code zu generieren um für diverse Architekturen Alternativen zu haben. Auch das lässt sich alles über Compileroptions und Regeln klären. Wenn man direkt in ASM programmiert, ist man der Sprache C obwohl sie sehr hardwarenah ist von der Performance her weit überlegen - dazu muss man aber die CPU Befehle gut kennen. Wenn man sich in ASM auf eine Architektur einigt, zB 32-Bit (=IA32) kann man dort ebenfalls plattformunabhängig arbeiten, indem man statt INT-Calls auch hier wieder eine eigene Funktionssammlung aufruft die passend eingelinkt wird.
Zuletzt bearbeitet:
Matthias Reitinger
ɐɯıǝɹ
Das stimmt inzwischen nicht mehr uneingeschränkt. In den Anfangszeiten von C wurde noch sehr viel in Assembler implementiert, weil die Compiler damals noch nicht dazu in der Lage waren, gut optimierten Maschinencode zu erzeugen. Inzwischen sieht das anders aus, und man bekommt in den meisten Fällen ein bestenfalls gleich schnell laufendes Programm, wenn man in Assembler anstatt C programmiert. Wenn es darum geht, spezielle Erweiterungen auszunutzen (wie 3DNow!, SSE, SSE2), kann es aber dennoch nachwievor sinnvoll sein, auf Inline-Assembler zurückzugreifen.bk75 hat gesagt.:
