Warum kein JAVA

[Yamagi]

Wie machst du Refactorings? s/foo/bar/g?

Ja, tatsächlich so in etwa. Nein, im Ernst. Wie oben schon angemerkt wurde, gibt es für C++ schlicht kaum gute Tools. Da tun es für fast alle Zwecke auch sed, awk und wenn die nicht reichen kann man immer noch auf Perl und ein kleines Wegwirfscript zurückgreifen. Zudem hält sich die Anzahl der Refactorings in meinem Projekten eh stark in Grenzen

 

[lme]

Halb OT: gibt es eigentlich eine IDE, die vim als Editor einbinden kann? Codeforge hat nen vi Modus, aber da gehen etliche vim Erweiterungen latürnich nicht...

 

[s-tlk]

Es gibt sogar erstaunlicherweise einen vi Modus in VS 2010. Darueberhinaus kann man noch extern sowas erweitern: http://www.viemu.com/
Ueber Sinn oder Unsinn laesst sich natuerlich streiten. Ich benutze da lieber direkt das original und mit vim 7.x sind sogar Tabs eingeflossen. Frueher musste man da immer mit screen herumhantieren. Das geht jetzt so wesentlich bequemer. ^^

Ja, tatsächlich so in etwa. Nein, im Ernst. Wie oben schon angemerkt wurde, gibt es für C++ schlicht kaum gute Tools. Da tun es für fast alle Zwecke auch sed, awk und wenn die nicht reichen kann man immer noch auf Perl und ein kleines Wegwirfscript zurückgreifen. Zudem hält sich die Anzahl der Refactorings in meinem Projekten eh stark in Grenzen

Das Refactoring machen Perl Scripts direkt fuer mich mit in dem beschraenkten Masse (das mit Eszett, nicht die Masse) wie ich das brauche.

 

[MuffiXXL]

Halb OT: gibt es eigentlich eine IDE, die vim als Editor einbinden kann? Codeforge hat nen vi Modus, aber da gehen etliche vim Erweiterungen latürnich nicht...

Da gibts natürlich auch was für die Eclipse.... Eclim nennt sich das ganze.

 

[lme]

@Muffi & s-tlk: danke für die Hinweise!

 

[-Nuke-]

Also JAVA ist überhaupt nicht Cross-Platform, das ist eine dreiste Lüge. Java-Programme funktionieren tadellos nur mit der VM eines Herstellers. Da ist es irrelevant ob es die auch für dreieinhalb Telefone gibt. Das ist immernoch Multi-Platform Vendor-Lockin und bei Programmiersprachen glaube ich einzigartig.

Seitdem Java OpenSource ist und unter GPL steht stimmt das Argument nicht mehr.

Vendor-Lockin hat .NET von Microsoft, da es dort keine vollständige zweite Implementierung gibt. Bei Java gibt's und gab es auch schon vorher 3 oder 4 Implementierungen und alle bestehen das Java TCK.

Und ob man nun C++ mit einem Compiler und einer speziellen Multiplattform-Lib nimmt oder Java ist im Prinzip von deinem Argument her das gleiche. Ein Wechsel auf einen anderen Compiler und eine andere Lib grenzt an unmöglich (siehe Umstieg auf clang bei FreeBSD).

 

[Vincent Vega]

Das stimmt so nicht. Grade im Java EE bereich hast du eigentlich die große Qual der JVM-Wahl, denn dort gibt es eine Gruppe an JVM Anbietern die sich zusammensetzt und den Funktionsumfang von Java EE standardisieren damit jeder von ihnen eine JVM anbieten kann die mit derjenigen der Konkurrenz kompatibel ist, siehe http://java.sun.com/javaee/overview/compatibility-javaee5.jsp

Aber ist das wirkliche der spannende Bereich, wenn's um Portabilität geht? Vielleicht lieg ich falsch, aber ich bin bisher immer davon ausgegangen, dass Java EE Anwendungen ohne (Window-)GUI in einem Servlet Container laufen. Die Schnittstellen des Betriebssystems, die in so einem Szenario benutzt werden sollten doch eigentlich überschaubar sein: Network-, File I/O- und vielleicht noch Threading-API. Der Rest sind Bibliotheken.

Ich behaupte jetzt mal ganz frech, dass ich auf diesem Level Portabilität auch recht einfach mit C oder C++ bewerkstelligen lässt. Der Code an dem ich gerade arbeite läuft ohne Probleme unter Windows, Linux/x86 und Linux/ppc. Um das Argument zu unterstreichen: Es handelt sich dabei um eine Embedded Anwendung, wo man ja allgemein annimmt, dass das mit der Portabilität nicht so leicht machbar ist.

 

[-Nuke-]

Ich behaupte jetzt mal ganz frech, dass ich auf diesem Level Portabilität auch recht einfach mit C oder C++ bewerkstelligen lässt.

Sicher. Mit Boost und/oder Qt mit hast du auch so ziemlich alles was Java bietet auch mit C++ portabel, ohne großartig selbst define und ifdef zu schreiben.

Aber du hast dann auch keinen wirklichen Vorteil mehr

Und eine Webanwendung würde ich nicht unbedingt mit C++ schreiben. Mangels Speicherschutz musst du einen extremen Aufwand betreiben, um das Teil Sicherheitslückenfrei zu halten.

Produzierst du in Java/.NET/etc. einen Bufferoverflow rotzt dir nur die Anwendung weg, mit einer Exception. Machst du das gleiche in C++ hast du u.U. gleich ne Root-Shell offen

 

[Kamikaze]

Der Aufwand ist nicht wirklich groß. Einfach keine Funktionen verwenden, die Puffer ohne Größenschranken aufnehmen oder manuell fest eine 0 auf das letzte Byte des Puffers schreiben bevor man davon liest.

Dann wäre da übrigens noch GTK, das ich eigentlich ganz angenehm finde. Ich habe da in der Regel alle GUI-Elemente bereits von Anfang an im Speicher und schalte sie bloß nach bedarf sichtbar/unsichtbar. So kommt man mit dem Speichermanagement nicht durcheinander.

Natürlich gibt es dynamisch generierte GUI-Teile, aber in der Regel ist es nicht schwer da die Übersicht zu behalten.

 

[Azazyel]

Der Aufwand ist nicht wirklich groß. Einfach keine Funktionen verwenden, die Puffer ohne Größenschranken aufnehmen oder manuell fest eine 0 auf das letzte Byte des Puffers schreiben bevor man davon liest.

Richtig; und weil das so trivial ist, sind Buffer Overflows in der C++-Welt ja völlig unbekannt. Erfreulicherweise enthalten ja ausnahmslos alle Buffer null-terminierte C-Strings und Programmierer machen niemals Fehler!

Warum sollte man sich händisch darum kümmern, wenn der Rechner das viel besser kann?

Dann wäre da übrigens noch GTK, das ich eigentlich ganz angenehm finde. Ich habe da in der Regel alle GUI-Elemente bereits von Anfang an im Speicher und schalte sie bloß nach bedarf sichtbar/unsichtbar. So kommt man mit dem Speichermanagement nicht durcheinander.

Das funktioniert nur bei äußerst statischen GUIs.

Natürlich gibt es dynamisch generierte GUI-Teile, aber in der Regel ist es nicht schwer da die Übersicht zu behalten.

Bei trivialen Hobbyprojekten auf dem heimischen Rechner mag das noch zutreffen, bei komplexeren GUIs erreicht man irgendwann den Punkt, bei dem durch die schiere Anzahl möglicher Variationen niemand mehr den Überblick behalten kann.

 

[-Nuke-]

Der Aufwand ist nicht wirklich groß. Einfach keine Funktionen verwenden, die Puffer ohne Größenschranken aufnehmen oder manuell fest eine 0 auf das letzte Byte des Puffers schreiben bevor man davon liest.

ca. 90% aller Sicherheitslücken sind Buffer-Overflows. Der Aufwand IST ziemlich groß.

Und das findest du nicht nur in Projekten von vor 20 Jahren, sondern auch in brandneuen Projekten / Bibliotheken. Der Mensch macht Fehler und ist unaufmerksam. Und wenn einem das verwendete Programmiersystem einem da nicht hilft, dann sollte man dessen Einsatz überdenken.

Nicht umsonst sperrt Google den Browser Chrome in eine Sandbox, trotz überaus hoher Sicherheitskontrollen. Projekte wie WebKit sind zu groß und es arbeiten zu viele Leute daran, als das man da 100%ige Sicherheit gewährleisten kann. Alles nur um Sachen zu erreichen, die Systeme wie Java und .NET gar nicht kennen.

Auch Sicherheitslücken in Java betreffen meist ausschließlich den C++-Anteil in der Java-VM.