![]() |
![]() |
|
![]() |
![]() |
|
Registrieren | Hilfe/Forumregeln | Benutzerliste | Kalender | Suchen | Heutige Beiträge | Alle Foren als gelesen markieren |
Programmierung Rat & Tat für Programmierer |
|
Themen-Optionen | Ansicht |
![]() |
#7 |
Inventar
![]() Registriert seit: 24.01.2001
Beiträge: 5.631
|
![]() Plattformunabhängig zu programmieren ist eine Sache des Wissens, der Erfahrung und der Disziplin. Die Erfahrung wie was wo wann muß man machen, dann kommt eben dadurch DAS WISSEN (um die Umstände) und dann erst die Disziplin (das Wissen JEDESMAL korrekt umzusetzen).
Es gibt Maschinen (gemeint ist CPUs), die sogenannte Big-Endian Prozessoren sind, oder Little-Endian Systeme (CPUs also). Big-Endian bedeutet das bei einem Wort (16bit Wert) das niederwertige Byte zuvorderst und hintan das höherwertige Byte im Speicher abgelegt wird. Bei einer Little-Endian CPU passiert das genau umgekehrt. Falls man binäre Datendateien zwischen den Systemen austauscht und nicht mittels Makros die Bytefolge in der Datei innerhalb des Wortes (16bit Wert) anpaßt, kommt es zu Bytedrehern und insofern zu Inkompatibilitäten auf Datenebene und nicht nur auf prozeduraler Ebene, daß nämlich Funktionen anders heißen auf einem anderen System, beispielsweise. Gemeint sind Systeme: PowerPC, x86 code Kompatible, HP PA RISC, DEC Alpha etc. Die wirklich professionelle Entwicklungsumgebung heißt Daten- und Procedure- Repository, das ist nicht anderes als das Speichern der Ausprägung von Datenvariablen wie auch Datenfeldern, die auch als Keyfelder daherkommen können, wie auch das Wiederverwenden von Codeteilen sowie den automatischen Einsteuerungsmechanismus von Datentypen beim Codieren, sodaß es garnicht zu inkompatiblen Datentypen beim Aufruf wie dem Ausführen der eigentlichen jeweiligen Funktion kommt. Gespeichert wird so ein Repository - das ein Nachschlagewerk darstellt - in indexsequentiellen Dateien wie auch in SQL-Tabellen gegebenenfalls. Der Weg zu portablen Programmen führt über Bibliotheken, die eine technische Umsetzung der systemeigenen Befehle und Verfahren auf prozeduraler Ebene bieten außen aber eine einheitliche Schnittstelle anbieten. Das ganze stellt eine Prozedur dar, ist abgekapselt und wird somit als Modul oder Kapsel bezeichnet (Black Box sozusagen). Umsetzung einer Routine zum Öffnen eines grafischen Fensters auf den einzelnen Systemen auf unterschiedliche Art und Weise. Beispiel: Öffnen eines Fensters (Funktion, die Schnittstelle ist allgemein"gültig") z.B: Öffnen eines Fensters in Windows Öffnen eines Fensters unter X(-Windows). Die zweite Notwendigkeit ist es, daß allgemeingültige Routinen, die nur in ganz engen Punkten systemindividuelle Anpassungen fahren müssen, die Entscheidung aus einem jedem System beigegebenen (selbst programmierten) Modul in Erfahrung bringen können, welche Systemanpassungen auf System xy notwendig sind. sys = InquireSystem(); // InquireSystem enthält Code, der einen Wert je System zurückliefert, z.B. WINNT 1, Linux 2 usw. (das ganze ist sehr allegemein gehalten, in die Lösung eines solchen Problems fließt in der Regel das Gehirnschmalz, Unterversionen von Linux, Windows NT etc. ... wie zu implementieren ?) deswegen hier nur sehr global ausführend ... : Abfrage des "System-Code(werte)s" in einer an und für sich schon allgemeinen (portablen) Funktion (bzw. Funktionenlandschaft also Ansammlung von Funktionen (printf,sprintf,fprintf)). if( sys == SYS_LINUX ) { do_something_linux_specific(); } else if( sys == SYS_WINNT ) { do_something_winnt_specific(); } .... usw. Ich schreibe eine Ausgabefunktion printf oder mehrere, die sich ähneln printf,sprintf,fprintf, und baue Abfragen auf den Systemcode, der von InquireSystem zurückgeliefert wird, ein. C++ hat den Nachteil größeren Code zu liefern und wirklich extrem down-top Programmieren vorauszusetzen, eine Scheiße für sich. Java ist Schwabbel-Code, d.h. in der Regel - zumindest noch - langsam. Das beste ist - meiner Meinung nach - C mit Repository RAD Umgebung, das ganze ist codekompakt, schnell, professionell genug und durchdacht einfach und auch genial lösungsorientiert (erfolgreich). C++ ist was für große Teams, die unter Zwängen stehen (Termindruck, Kapselautomatik durch Memberzugriffsrechte, Methoden und Vererbung, Überladen von Funktionen), aufgeblähter Code und Abstürze in Grenzsituationen, die jedes C programmierte System locker wegsteckt, sind die Folge. Schon mal Visual C++ programmiert, noch dazu mit MFC, da kommt einem das Grauen, ebenso bei Microsoft Java Umsetzungen, wo eigene Extensions "angeboten" werden ... , ... - so - wie die Hexe ihren Gifttrunk 'einem' anbietet. Finger weg ! Profis coden nach wie vor in Cobol, plattformunabhängig ! und eben mehr und mehr in C mit eben solchen Hilfsmitteln oder gedrungenermaßen eben in C++ oder Sun Java. Microsoft oder auch Borland C++ und Kollegen ist Kindergarten-Mühsal mit 'an die Wand-fahr Garantie'. Der gcc ist einzig, das Wahre, um Codebibliotheken für mehrere zigtausend Mark/Dollar angereichert oder eben SELBST programmiert, das ist Sache. Visual C++ usw. ist etwas für Einsteiger, sicher nicht für ernsthafte plattformübergreifende Programmierer(teams). mfg Kikakater |
![]() |
![]() |
Aktive Benutzer in diesem Thema: 1 (Registrierte Benutzer: 0, Gäste: 1) | |
Themen-Optionen | |
Ansicht | |
|
|