✔ Portabilität == Zeitverschwendung?

[Enumerator]

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

 

[Philipp9494]

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

 

[MCoder]

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

 

[deepthroat]

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ß

 

[Daniel Toplak]

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

 

[Enumerator]

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! 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

 

[deepthroat]

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ß

 

[Avorin]

Ich nehme einfach das .NET

 

[deepthroat]

Ich nehme einfach das .NET

Du hast wirklich keine Ahnung, oder?!

 

[vfl_freak]

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

Gruß
Klaus