In wie fern lohnt sich C++ für einen Javaentwickler

[Travel]

Ja... und?

Der Link sollte dem Verständnis helfen wenn man sich schon über Generics ausläßt...

 

[Travel]

@ Topic

Jede Programmiersprache hat ihre Stärken und Schwächen und somit läßt sich für bestimmte Aufgaben bzw. Anwendungsgebiete eine geeignete Programmiersprache finden. Ein Vergleich zwischen verschiedenen Aufgaben halte ich persönlich für nicht sinnvoll, da unter Umständen Programmiersprachen für einen ganz bestimmten Zweck/Aufgabengebiet entwickelt worden sind.

Einige Programmiersprachen decken sicherlich einen größen Teil ab als andere (z.B. C, C++, C# und Java). Als Javaprogrammierer können Einflüße und Konzepte aus anderen Sprachen sicherlich hilfreich sein. Insbesondere kann hier C empfohlen werden, alleine schon zwecks JNI.

 

[KuhTee]

Der Link sollte dem Verständnis helfen wenn man sich schon über Generics ausläßt...

Nun, im Gegensatz zu dir kenne ich mich offenbar mit Java Generics UND C++ Templates aus
Im Bytecode bleibt von den Generics letztendlich nix übrig, und schon regt man sich als C++ Entwickler auf, beispielsweise über fehlende Spezialisierung oder die Unmöglichkeit neue Instanzen eines Types anzulegen. Die Workarounds für diese Probleme sind einfach nur abgrundtief hässlich.

 

[Travel]

Nun, im Gegensatz zu dir kenne ich mich offenbar mit Java Generics UND C++ Templates aus
Im Bytecode bleibt von den Generics letztendlich nix übrig, und schon regt man sich als C++ Entwickler auf, beispielsweise über fehlende Spezialisierung oder die Unmöglichkeit neue Instanzen eines Types anzulegen. Die Workarounds für diese Probleme sind einfach nur abgrundtief hässlich.

Das war/ist auch nicht das Ziel der Generics in Java ;-)

 

[KuhTee]

Na, das Thema war doch, was C++ einem Java Entwickler bieten kann. Templates wären dann etwas

 

[Spacerat]

Na, das Thema war doch, was C++ einem Java Entwickler bieten kann. Templates wären dann etwas

Nein, das Thema war, ob es sich lohnt, C++ zu lernen, insbesondere für einen Javaentwickler, die Antwort darauf lautet immer noch definitiv

NEIN, C wäre angebrachter. Wenn's dich dennoch interessiert, dann tu dir keinen Zwang an, aber bring' nichts durcheinander.

Diese Antwort impliziert, dass es durchaus Leute gibt, die sogar in einigen Sprachen mehr als nur zwei fit sind aber die, die sich hier so hervorheben, gehören mit Sicherheit nicht dazu, zumindest nicht so lange, wie sie Java-Generics mit C++-Templates vergleichen, sie sind nicht das selbe und funktionieren anders. Was man dabei als gut oder weniger gut empfindet, ist Gewohnheitssache.
Mit den Dingen was C++ einem Javaentwickler bieten kann, haltet ihr, die ihr euch ja so mit C++ auskennt, immer noch pedantisch hinterm Berg, von daher kann das nicht das Thema sein. Ihr sagt immer nur, welche Java-Macken es in C++ nicht gibt (Obwohl, mir werden entsprechende Vorteile ehrlich gesagt zunehmend Gleichgültiger).

@Travel: Es ist wohl keine so tolle Idee, da weiter zu machen, wo ich aufgehört habe. Lass sie doch einfach oben auf ihrem besonders hohem Niveau verhungern.
[EDIT]So wie ich das sehe, wurden hier bereits zwei vermeintliche Vorteile von C++ genannt, aber:
1. Destruktoren: Wären ein Anzeichen dafür, dass man sich um die Speicherverwaltung selber kümmern muss. Das ist in Java nicht nötig.
2. Generics->Templates: Beide Hilfsmittel haben in ihren jeweiligen Sprachen ihre eigenen Tücken.[/EDIT]

 

[KSG9|sebastian]

C und Java zu vergleichen endet doch immer im gleichen Flamewar. Beide Sprachen haben ihre Daseinsberechtigung. Den Tiobe-Index kannn man da aber getrost vergessen, da spielen zu viele Hypes mit rein.
C hat mit Sicherheit seine Vorteile, Java ebenso, aber die Sprachen zu vergleichen geht doch nur anhand von gleich funktionierenden Konzepten...und Generics vs Templates sind nicht dieselben Konzepte. Das Templates fehlen in Java würde ich ja unterstützen, allerdings waren die einfach nicht gewollt. Gut oder schlecht? Keine Ahnung...

@Olli_M: Entweder ihr habt mit Java einfach die falsche Sprache genutzt (50% nativer Code?) oder es fehlt schlicht und einfach das KnowHow.
Wir haben ne Anwendung bei 120.000 Kunden-PCs im Banking-Bereich und mit Java an Sich da gar keine Probleme...

 

[maki]

Demnächst wird also .NET/C# angesagt sein bei uns, auf diese Umstellung bin ich optimistisch gespannt. Zum Ausgangsthema: eine andere Progr.Sprache zu lernen, kann meines Erachtens nur Vorteile haben. Das Zeitaufwand/Nützlichkeit-Verhältnis muss jeder für seinen Bereich selber bestimmen.

Hmmm... schon mal nachgesehen welchen Stellenwert .NET ab Windows 8 hat?

 

[Olli_M]

Hmmm... schon mal nachgesehen welchen Stellenwert .NET ab Windows 8 hat?

Ja, gerade eben . So wie ich das nun verstanden habe, gibt es dann .NET, Silverlight und eine dritte Sache namens WindowsRT (runtime), was zwar gewissermassen ähnlich zu .NET ist, aber doch nicht wirklich kompatibel ist. Wieso gibt es denn nun eine dritte Sache, anstatt .NET einfach Metro-tauglich zu machen?

Olli

 

[Empire Phoenix]

Hmmm... schon mal nachgesehen welchen Stellenwert .NET ab Windows 8 hat?

Hm? gibts da etwas was man wissen sollte?

 

[maki]

.NET und die CLR wird in Windows 8 wieder weniger "wichtig", da COM (C/C++) wiederbelebt wurde, ausserdem wird JavaScript/HTML/CSS gepusht.

Natürlich wird die neue RT API für .NET verfügbar sein, aber der Focus ist dann eben wieder auf COM.

Microsoft macht solche Kursänderungen gerne, und schon immer.
Mal sehen wie lange es dieses mal dauert bevor wieder alles geändert wird...

 

[Helgon]

Ja, gerade eben . So wie ich das nun verstanden habe, gibt es dann .NET, Silverlight und eine dritte Sache namens WindowsRT (runtime), was zwar gewissermassen ähnlich zu .NET ist, aber doch nicht wirklich kompatibel ist. Wieso gibt es denn nun eine dritte Sache, anstatt .NET einfach Metro-tauglich zu machen?

Olli

Also was ich mitbekommen hab, ist das Microsoft mit Windows 8 C++ wieder etwas Zeit gewidmet hat (siehe Visual Studio 2012, find den super gelungen), dann eben was du sagtest das WindowsRT wo jetzt schon leute am meckern waren, das wohl irgendwelche Berechtigungen fehlen würden

und was maki mim Stellenwert meint würd mich auch interessieren? Sind sie mehr in die Richtung gegangen oder eher davon weg? ???:L

Edit: Ah hat schon geantwortet

 

[KuhTee]

...die Antwort darauf lautet immer noch definitiv...

Extrem einseitige "Antwort", die davon ausgeht, dass man nur noch das in C macht, was in Java absolut nicht geht. Java ist aber OOP, da ist es ganz angenehm, auf "der anderen Seite" ebenfalls eine OOP Sprache zu haben. Und ich habe schon _etliche_ Java zu C bzw C++ Brücken bauen müssen.

Diese Antwort impliziert, dass es durchaus Leute gibt, die sogar in einigen Sprachen mehr als nur zwei fit sind aber die, die sich hier so hervorheben, gehören mit Sicherheit nicht dazu, zumindest nicht so lange, wie sie Java-Generics mit C++-Templates vergleichen, sie sind nicht das selbe und funktionieren anders.

Natürlich sind sie nicht das selbe. Sonst wären ja Java Generics so gut wie C++ Templates. Die grundsätzliche Intention ist aber in beiden Fällen die gleiche, und da stinken die Java Generics eben gegen C++ Templates ab.

Was man dabei als gut oder weniger gut empfindet, ist Gewohnheitssache.

Was ist daran "Gewohnheitssache", wenn das hier:

T t = new T();

unmöglich ist? Was ist am hin- und herreichen von Class Objekten "Gewohnheitssache". Natürlich kann ich mich auch an Metallspäne unter meinen Fingernägeln gewöhnen, aber will ich das wirklich?
Wer hierbei von "Gewohnheitssache" redet, hat C++ Templates noch nie wirklich genutzt und sollte sich bei dem Thema am besten raushalten.

(Obwohl, mir werden entsprechende Vorteile ehrlich gesagt zunehmend Gleichgültiger)..

Yeah, Flamewar. Was sind denn die entsprechenden Vorteile?

1. Destruktoren: Wären ein Anzeichen dafür, dass man sich um die Speicherverwaltung selber kümmern muss. Das ist in Java nicht nötig.

Diese Aussage beweist abermals, dass du von C++ leider keine Ahnung hast und daher nix weiter schreiben solltest. Das schöne an C++ ist doch, dass ich NICHT gezwungen bin, mich um die Speicherverwaltung selbst zu kümmern (dank Smartpointer, RAII oder wenn ich will auch ein GC), ich in Java aber dazu GEZWUNGEN bin darauf zu verzichten, mit all den unangenehmen Nachteilen. Nicht missverstehen, ein GC ist eine feine Sache und in 98% aller Fälle ein super Werkzeug. Nimmt den Leuten das Denken ab

2. Generics->Templates: Beide Hilfsmittel haben in ihren jeweiligen Sprachen ihre eigenen Tücken.

Zum Beispiel? Sicher, alles hat Tücken, aber nenn mir doch mal ein paar für die Templates. Würde mich jetzt (ganz ehrlich) interessieren, welche konkret dir in den Sinn kommen. Abgesehen davon würde ich Templates nicht als "Hilfsmittel", sondern als elementaren Bestandteil von C++ bezeichnen. Während es bei Java eher etwas Wischiwaschi ist, zur Laufzeit sowieso. Und wieder nicht missverstehen: Ich nutze ja ebenfalls viel Java und auch viel die Generics. Aber wie unbrauchbar die Java Generics für anspruchsvollere Aufgaben zu sein scheinen sieht man ja schon Java-eigenen APIs. JavaFX beispielsweise... Ich habe eine BooleanProperty, eine IntegerProperty, eine StringProperty ... WTF? Mit echten Templates, Templatespezialisierung (und vielleicht auch der viel gescholtenen Mehrfachvererbung) ließe sich das wesentlich eleganter umsetzen.

Und das ist schade. Denn ob du's jetzt glaubst oder nicht: Ich arbeite viel und durchaus auch gern in Java. Aber es ist eben häufig auch zum Haare ausraufen, wenn man gewisse Dinge einfach unglaublich umständlich angehen muss.

Ich weiss übrigens nicht, ob ich einen "Softwareentwickler" noch ernst nehmen kann, der sich so gegen eine Sprache sträubt. Scheint mir extrem dogmatisch und unprofessionell.

Hier, noch für dich:
Programmieren lernen von Anfang an: start:cppjava - proggen.org
Obwohl ich, zugegeben, auch nicht jedem Punkt dort zustimmen würde.

 

[Empire Phoenix]

Um nochmal auf die frage zurückzukommen miene Antwort ist:
C++ und C lohnen sich eigentlich immer für Java programmierer, zum einenen erhöt es das Verständniss was die JVM lowlevel alles intern macht, und das einige Sachen auch anders möglich sind. Zum anderen hilft es enorm wenn man mit JNI zu tun hat, was normalerweise nur eine Frage der Zeit ist.

Was ich finde was noch nicht aufgezählt wurde als argument. Die auswirkung von programmierfehlern. Bei java enden pointer/referenzen fehler mit einem Absturz im normalfall. Bei C++ kann ein pointerfehler alles verursachen, je nachdem wo er gerade hinzeigt, gerade bei sehr großen business projekten die mit 6 Manjahren oder mehr sind wird das ganze problematisch wenn irgetein flüchtigkeitsfehler in einer utility methode Fehler hervorruft die ganz woanders sich manifestieren. In dem Sinne Java is deterministischer bei fehlern.

 

[Olli_M]

Und das ist schade. Denn ob du's jetzt glaubst oder nicht: Ich arbeite viel und durchaus auch gern in Java. Aber es ist eben häufig auch zum Haare ausraufen, wenn man gewisse Dinge einfach unglaublich umständlich angehen muss.

Eben. Genau das denke ich auch. Meine Kritik an Swing war übrigens keineswegs gegen Java als solches gerichtet. Im Gegenteil, Java hat m.E. sehr viele Vorteile als Sprache, und viele Entwickler haben ja mit GUI Design gar nichts zu tun, zudem kann man auch mit Java schöne GUIs entwickeln, nur ist mein Punkt dabei, dass man überproportional viel Zeit darin investieren muss, die dann ggf.
für die Business Logic fehlt.

Ich würde halt oft ganz gerne meine Zeit fürs GUI reduzieren, damit ich mich mehr auf die Programmlogik konzentrieren kann (und dort hat Java m.E. durchaus seine Stärken). Durch eine Art "wiederverwendbare Oberfläche" kann man sich aber auch dann die Arbeit etwas erleichtern.

Mal sehen, wie das mit C# wird, ich hab da ja die Hoffnung, dass man dort einfaches Design zusammen mit den Vorteilen der OOP kriegt. Als dritten Punkt erhoffe ich eine bessere Verzahnung mit Windows, das war oft auch ein kleines Manko bei Java (zudem machen wir es tatsächlich so, dass wir uns einen exe Launcher basteln, der dann die Starterklasse in einem anderen Verzeichnis startet; obwohl das funktioniert, fand ich das schon immer komisch). Oder das mit den Updates: wenn ich mal einem PC-kundigen Kunden ein jar File schicke (ja, ich mach schon auch setups, aber wenn es mal schnell gehen soll, ist das durchaus mitunter sinnvoll), muss ich immer dazuschreiben, "bitte das alte jar löschen und nicht umbenennen". Java sucht sich ja die Klasse, der jar Filename ist ihm ja wurscht. Eine "all-in-one" exe wäre schon manchmal nett.

Mit Windows 8 + dem ominösen WindowsRT Zeug hab ich aber noch keine Erfahrung (abgesehen von einigen Lese-Einheiten).

freundliche Grüße

Olli

 

[maki]

Meine Erfahrungen in C++ sind schon über 10 Jahre alt, aber die Templates(erzeugt da der Compiler nicht Klassen?) waren schon eine ganz andere Nummer als Generics, aber letztere wurden aus Sun/Oracle typischen Gründen genau so gebaut wie sie sind:
Rückwärtskompatibilität

.. und genau aus diesem Grunde wurden schon ganz andere Sünden in Java begangen.. naja, manche Firmen ändern zu oft, manche zu selten.

Frage aus Neugier an die C++ kundigen:
Wie handhabe ich den Zuweisungsoperator & Copy Constructor, wenn ich Immutables haben will?
Ich meine nicht const wenn ich immutable sage, sondern eben die Unveränderlichkeit der Objekte auf Klassenebene festzulegen.

 

[KuhTee]

Wie handhabe ich den Zuweisungsoperator & Copy Constructor, wenn ich Immutables haben will?
Ich meine nicht const wenn ich immutable sage, sondern eben die Unveränderlichkeit der Objekte auf Klassenebene festzulegen.

Für den Copyconstructor ist eigentlich keine besondere Vorgehensweise nötig, da das zu kopierende Objekt ja sowieso const übergeben wird, also nicht veränderbar ist. Ob es Sinn macht ist eine andere Frage, da du ja sowieso nur eine identische nicht veränderbare Kopie bekommst. Der Zuweisungsoperator muss aber natürlich private sein oder aber in C++11 einfach gelöscht werden. Ansonsten gelten natürlich noch die gleichen Regeln wie auch in Java.
Aber ehrlich... hätte das eine kurze Google Suche nicht auch zu Tage gebracht?

 

[maki]

Aber ehrlich... hätte das eine kurze Google Suche nicht auch zu Tage gebracht?

Gilt das nicht für das meiste hier diskutierte?

 

[KuhTee]

Never
Wir erschließen neue Kenntnisse hier...

 

[Gast2]

Moin,

Als dritten Punkt erhoffe ich eine bessere Verzahnung mit Windows,[...]

Falls Du auf P/Invoke anspielst - das genau so ein Aufwand wie JNI. Du hast zumindest noch den Vorteil das VS automatisch Assemblys erstellt um ggf. externe COM/Ax zu verwenden. Wenn Du aber direkt Windows-API Aufrufe machen willst, dann ist eine entsprechen Wrapper-Library mit C++/CLI einfacher. Wobei Du hier richtig aufpassen musst. Der GC verschiebt und die API hat noch den alten Pointer. Wie schön das Knallt und beim Debuggen funktioniert es komischer weise - weil der GC gerade mal nicht verschiebt :toll:

aber die Templates(erzeugt da der Compiler nicht Klassen?)

jain - bei Klassen ja, einzelnen Methoden nein. Vorallem erzeugt er von jedem Typ entsprechend Code. Wenn Du also auf eine Template Methode 200 Typen anwendest, dann hast Du den (fast) identischen Code 200x da -.-

hand, mogel

 

[KuhTee]

Wenn Du also auf eine Template Methode 200 Typen anwendest, dann hast Du den (fast) identischen Code 200x da -.-

Nun, das stimmt so nicht wirklich. Moderne C++ Compiler optimieren bei Templates ja deutlich besser als noch vor 12 Jahren. In den allermeisten Fällen ist es ja so, dass ein Template nicht unerheblichen Code enthält, der bei jeder Instanz gleich sein würde. Je größer das Template, desto mehr in der Regel. Und da kann ein Compiler gut ansetzen und muss diesen Code nicht 200x erzeugen. Die "Angst" vor dem Code bloat ist im praktischen Umfeld absolut unerheblich. Und mal ehrlich, auf wieviele verschiedene Typen wendest du in einer durchschnittlichen Software ein Template an? 200 sinds ja eher selten. Und selbst wenn, das Binary wird dadurch nicht dutzende MB größer.