Portabilität == Zeitverschwendung?

Enumerator

Mitglied Kamel
Moin!

Was bedeutet für euch Portabilität? Soll heißen: macht Ihr Euch die Mühe, euren Quellcode kompatibel zu den Besonderheiten einzelner Betriebssysteme zu schreiben? Oder genügt es Euch zu wissen, dass das Ergebnis z.B. nur auf POSIX-konformen Systemen, nur auf Linux, BSD, Solaris (...) oder gar nur der von Euch genutzten Distribution läuft? Wer beachtet auch MS? Und warum?
Hintergrund des Ganzen ist die Frage die mir ständig gestellt wird: Warum kann ich die Software die Du geschrieben hast nicht auf meinem Rechner benutzen? Wieso schreibst Du das nicht für [xxx] um? Dann haben viel mehr Leute was davon!
Ich selbst verwende v. A. Linux (privat) und BSD (im Beruf) und finde, die Zeit die es benötigt, meinen Output portabel zu machen, kann ich wirklich sinnvoller nutzen... zumal mich die kleinen aber feinen Unterschiede zwischen dem Pinguin und dem Kugelfisch schon gehörig nerven.
Doch vielleicht hat irgendwer ja ein schlagendes Argument?

Gruß
Enum
 
Mmh..

Ich arbeite auch privat hauptsächlich auf Linux und in der Schule auf Windows.
Da ich die meisten Programme, nur für private Zwecke programmiere, finde ich es auch eine echte Zeitverschwendung, sie kompatibel zu anderen Systemen zu machen..

Nun gut.. Wenn ich ein Programm schreibe, welches ich veröffentliche, werde ich sie früher oder später portabler machen..

MfG
Philipp
 
In meinem Arbeitsumfeld gibt es immer häufiger die Anforderung nach plattformübergreifender Verwendbarkeit der Software, so dass wir uns bei Neuentwicklungen darauf einstellen. Deshalb beginnen wir jetzt, durchgängig die Boost-Library einzusetzen, die z.B. auch solche Themen wie das Multithreading einheitlich und plattformübergreifend behandeln kann.

Schwierig ist auf jeden Fall das Thema GUI. Allerdings gibt es da aber inzwischen auch schon brauchbare plattformübergreifende Klassenbibliotheken, wie etwa Qt.

Ich denke, mit Auswahl der richtigen Werkzeuge bedeutet plattformübergreifende Programmierung heutzutage nicht mehr allzugroßen Mehraufwand.

Gruß
MCoder
 
Hi.
In meinem Arbeitsumfeld gibt es immer häufiger die Anforderung nach plattformübergreifender Verwendbarkeit der Software, so dass wir uns bei Neuentwicklungen darauf einstellen. Deshalb beginnen wir jetzt, durchgängig die Boost-Library einzusetzen, die z.B. auch solche Themen wie das Multithreading einheitlich und plattformübergreifend behandeln kann.

Schwierig ist auf jeden Fall das Thema GUI. Allerdings gibt es da aber inzwischen auch schon brauchbare plattformübergreifende Klassenbibliotheken, wie etwa Qt.

Ich denke, mit Auswahl der richtigen Werkzeuge bedeutet plattformübergreifende Programmierung heutzutage nicht mehr allzugroßen Mehraufwand.
Genauso sehe ich das auch.

Es gibt genügend plattformübergreifende Bibliotheken (z.T. auch für GUI) wie eben Boost, dlib, poco, Apache Portable Runtime usw.

Wer da noch für Applikationen plattformübergreifenden Code schreibt ist selbst schuld.

Gruß
 
Also generell kann man natürlich beim Programmieren bzw. schon beim Design etwas allgemeiner denken um weniger Aufwand für Plattformübergreifende Software zu haben.
Was man allerdings bedenken muss ist der Mehraufwand an "Build-Logik" und Tests bzw. Qualitätssicherung. Da kommt pro zusätzlich unterstützter Plattform noch einiges an Arbeit hinzu.

Gruß Daniel
 
Hi @all!

Erstmal vielen Dank für Eure Antworten.

Nun gut.. Wenn ich ein Programm schreibe, welches ich veröffentliche, werde ich sie früher oder später portabler machen..
Also von vornherein stur ego und erst Gedanken machen wenn's soweit ist?
Gefällt mir! :D Auch wenn ich selbst wohl den Mehraufwand nicht in Kauf nehmen würde.

Es gibt genügend plattformübergreifende Bibliotheken (z.T. auch für GUI) wie eben Boost, dlib, poco, Apache Portable Runtime usw.
Schwierig ist auf jeden Fall das Thema GUI. Allerdings gibt es da aber inzwischen auch schon brauchbare plattformübergreifende Klassenbibliotheken, wie etwa Qt.
Klar gibt es diese Bibliotheken und man wäre - nicht nur wegen der Portabilität - schön blöd das Pferd neu zu erfinden.
Ich selbst benutze fast immer Teile der APR, und Boost ist ja ein Quasi-Standard - aber leider ist es damit nicht ganz getan:

Was man allerdings bedenken muss ist der Mehraufwand an "Build-Logik" und Tests bzw. Qualitätssicherung. Da kommt pro zusätzlich unterstützter Plattform noch einiges an Arbeit hinzu.
Das ist der Hauptgrund für meinen Standpunkt; Ich verwende meist GNU Autotools, doch in Sachen Windows ist das nicht immer ausreichend.
Zumal die Endnutzer da immer einen Installer erwarten - und nicht einsehen sich selbst um benötigte Bibliotheken, Konfiguration und dergleichen kümmern zu müssen...

Naja, damit kann ich den Thread wohl schließen.

Gruß
Enum
 
Das ist der Hauptgrund für meinen Standpunkt; Ich verwende meist GNU Autotools
Welche ja nicht unbedingt portabel sind -- zumindest nicht unter Windows.

Aber auch da gibt es genug Alternativen, z.B. SCons, WAF, premake, bjam (*grusel* :)) oder CMake (welches ich momentan einsetze).

Jedenfalls gab es bestimmt gute Gründe warum KDE von den autotools auf CMake gewechselt ist... ;)

Gruß
 
Moin,

ich denke mal, dass die grundlegende Frage der notwendigen Portabilität immer von den einzelnen Gegebenheiten und Anforderungen abhängt!

Programmiere ich ein System, das für möglichst viele verschiedene Kunden mit unterschiedlicher Hardware/Plattform infrage kommen soll, ist die Portabilität sicher von vorne herein zwingend notwendig!

Ich habe derzeit in meiner Firma ausschließlich an hausinternen SW-Produkten, die somit ausschließlich nur auf WIN-Rechnern (2k oder XP) zu Einsatz kommen. Somit ist hier bei uns die Entwicklung einer bspw. Linux-Version totaler Quatsch und völlige Zeitverschwendung :eek::p

Gruß
Klaus
 

Neue Beiträge

Zurück