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



## Rudolf (18. Okt 2012)

Hi,

ich finde im Internet viel geteilte Meinung. 

Auf der einen Seite gibt es, besonders auf der Linuxseite, unheimlich viele interessante Projekte in C++. Auf der anderen Seite ist Java konzeptionell weiter als C++ und bringt bei Performance und Programmiereleganz einiges mehr als C++, wohingegen C++ bei der Paradigmavielfalt wohl Java noch einiges voraus ist.

Glaubt ihr, dass die gängigen Programme wie Desktop Environments oder oft genutzte Programme wie Webbrowser irgendwann in Java entwickelt werden? Oder hat Java gegenüber C++ entschiedene Nachteile. 

Wem gehört die Zukunft? Lohnt sich das Lernen von C++ überhaupt noch für einen Javaentwickler? Für welche Bereiche ist C++ geeigneter als Java?


----------



## Spacerat (19. Okt 2012)

Sicher, dass du C++ meinst?
Schau mal hier. -> TIOBE Software: The Coding Standards Company
Also die Zukunft gehört wohl dem portablen Bytecode (C# und Java), den Rest (JNI, bei C#... k.P. lässt sich afaik auch direkt native kompilieren) bekommt man gut mit C hin. Was will man mehr?
Hatte vor einigen Jahren mal nach Performanceunterschieden zwischen LWJGL, JOGL und nativen OpenGL gesucht, daraus ging hervor, dass diese damals schon kaum messbar waren.


----------



## Gast2 (19. Okt 2012)

Moin,



Spacerat hat gesagt.:


> Schau mal hier. -> TIOBE Software: The Coding Standards Company


schöne Grafik - zeigt nur den Hype um Phone & Co.



> Also die Zukunft gehört wohl dem portablen Bytecode (C# und Java), den Rest (JNI, bei C#... k.P. lässt sich afaik auch direkt native kompilieren) bekommt man gut mit C hin.


Vieleicht auf dem PC aber nicht Embedded - da ist es (dummerweise) eher C oder sehr C lastiges C++. Unter Embedded ist es sinnlos erst eine VM zu starten und anschließend das eigentliche Programm.



> Was will man mehr?


(persönlich) C++ hat einige Vorteile gegenüber C, Polymorphie ist ein absoluter Segen in der Programmierung.



> Hatte vor einigen Jahren mal nach Performanceunterschieden zwischen LWJGL, JOGL und nativen OpenGL gesucht, daraus ging hervor, dass diese damals schon kaum messbar waren.


wieso reiten eigentlich immer alle auf der Performance rum?

hand, mogel


----------



## Spacerat (19. Okt 2012)

mogel hat gesagt.:


> schöne Grafik - zeigt nur den Hype um Phone & Co.


Welcher Gedanke fördert diese Annahme? Vllt. zeigts ja auch nur den Hype um die Portabilität, die Bytecode liefert.


mogel hat gesagt.:


> (persönlich) C++ hat einige Vorteile gegenüber C, Polymorphie ist ein absoluter Segen in der Programmierung.


Natürlich, sonst hätte man diese Sprache nicht entwickelt. Bytecode-Sprachen wie C# und Java bieten aber nicht blos Polymorphie. Ausserdem könnte man auch sagen, dass Java gegenüber C++ weitere Vorteile hat und C# evtl. sogar noch viel mehr. Vllt. gibt es ja bald CPP2Bytecode- oder C#2Embedded-Compiler. Faktisch ist Bytecode nichts anderes als nativer Code für virtuelle Maschinen bzw. virtuelle Prozessoren.


mogel hat gesagt.:


> wieso reiten eigentlich immer alle auf der Performance rum?


Weil's der einzig  verbleibende Grund ist, wo man sich für nativen Code entscheiden würde, solange man die Wahl hat und penibel Taktzyklen zählt. Ansonsten kann man sich nur noch an guten Sprachkonzepten und deren Erlernbarkeit orientieren.

Also um die Frage mal klar zu beantworten: Wenn man nicht gerade irgendwelche Microcontroller programmiert, wo ohnehin C vorherrscht, lohnt sich für einen "bereits" Java-Entwickler die zusätzliche Erlernung von C++ kaum.


----------



## Helgon (19. Okt 2012)

Spacerat hat gesagt.:


> Hatte vor einigen Jahren mal nach Performanceunterschieden zwischen LWJGL, JOGL und nativen OpenGL gesucht, daraus ging hervor, dass diese damals schon kaum messbar waren.



Es ist aber nun mal so, dass alle guten Engines/Frameworks (für Spiele/3D) eben für C++ geschrieben sind.

Glaub nicht, weil du es angesprochen hast, Browser in Zukunft in java geschrieben werden.. ich bin jetzt keine java guru, aber wenn ich nur mal überlege was mit c++ geht, da wüsst ich nichtmal wo ich in java ansetzen soll (aber auch vllt nur weil mir die kentnisse fehlen), beispielsweise irgend ein programm hooken, und dann im speicher rumfummeln, auf hinstances zugreifen etc.. hat auch irgendwie was schönes die sprache mit den operatoren überladen und den ganzen möglichkeiten die man hat, aber vom schreibaufwand ist das ja auch wieder ein gutes stück mehr als in Java.

Ich find, was spricht dagegen beides zu können. Syntax beim programmieren ist eh immer das selbe und dann muss man eben die sprachspezifischen feinheiten lernen, aber das sollte wohl auch kein all zu großes problem darstellen, wenn man sich wirklich für interessiert

grüße


----------



## Spacerat (19. Okt 2012)

Helgon hat gesagt.:


> Es ist aber nun mal so, dass alle guten Engines/Frameworks (für Spiele/3D) eben für C++ geschrieben sind.
> 
> Glaub nicht, weil du es angesprochen hast, Browser in Zukunft in java geschrieben werden.. ich bin jetzt keine java guru, aber wenn ich nur mal überlege was mit c++ geht, da wüsst ich nichtmal wo ich in java ansetzen soll (aber auch vllt nur weil mir die kentnisse fehlen), beispielsweise irgend ein programm hooken, und dann im speicher rumfummeln, auf hinstances zugreifen etc.. hat auch irgendwie was schönes die sprache mit den operatoren überladen und den ganzen möglichkeiten die man hat, aber vom schreibaufwand ist das ja auch wieder ein gutes stück mehr als in Java.
> 
> ...


Das ist vollkommen korrekt, mit c++ kann man mehr machen. Dafür hätte man in Java allerdings noch JNI, was dann allerdings auch dort die Portabilität einschränkt. Es spricht nur wenig dagegen mehrere Sprachen zu können. Ich würde aber eher noch C anstatt C++ lernen, von wegen JNI, der Programmierung von Microcontollern usw (Java und C streiten sich deswegen seit geraumer Zeit auch um die ersten beiden Plätze auf dem TIOBE-Index). Die Syntax ist immer... sagen wir ähnlich. Weil das so ist, kann das Erlernen von zwei oder mehr Programmierspachen zu ungewollten Verwechslungen führen und das nicht nur bei der Syntax. Wenn einem solche Verwechslungen beim Erlernen einer neuen Sprache auffallen und man das nicht in den Griff bekommt, sollte man es lieber aufgeben oder auf Eis legen und irgendwann einen neuen Versuch starten. Je mehr Sprachen man sich aneignet, desto häufiger verhaspelt man sich.


----------



## Crian (19. Okt 2012)

Schwer zu sagen. Ich habe zuerst C gelernt, dann C++ und zuletzt Java und auch mit allen dreien Geld verdient. Andere Sprachen noch davor / dazwischen und zusätzlich.

Es ist ja lange nicht nur die Syntax, die es zu erlernen gilt. Die ist meist schnell erledigt. Als nächstes kommen dann die Standardbibliotheken hinzu und als fast das wichtigste, wie ich finde, den "Geist" der Sprache zu erfassen und zu verinnerlichen. Tut man das nicht, dann wird man immer holprig und unelegant in einer Sprache bleiben.

Man kann in allen Sprachen Fortran programmieren, wenn man will. (Ja, damit hab ich auch schon Geld verdient, ist aber etwas her.)


----------



## Spacerat (19. Okt 2012)

[OT]





Crian hat gesagt.:


> Man kann in allen Sprachen Fortran programmieren, wenn man will.


I kann Denglisch, also Deutsch in Englisch sprechen, oder wie soll man's verstehen? Fortran ist doch afaik auch nur 'ne Sprache?[/OT]


----------



## Akeshihiro (19. Okt 2012)

[OT]





Spacerat hat gesagt.:


> [OT]I kann Denglisch, also Deutsch in Englisch sprechen, oder wie soll man's verstehen? Fortran ist doch afaik auch nur 'ne Sprache?[/OT]


Das sollte vermutlich nur heißen, dass nur weil man technisch eine Sprache "nutzt", man diese aber eigentlich doch nicht nutzt (Konventionen, Techniken, ...). Beispielsweise ist Java ja OOP, es gibt aber auch Leute, die prozedural programmieren oder sonst was anstellen, nur kein OOP [/OT]


----------



## Gast2 (19. Okt 2012)

Spacerat hat gesagt.:


> Welcher Gedanke fördert diese Annahme? Vllt. zeigts ja auch nur den Hype um die Portabilität, die Bytecode liefert.


hmmm - weil Objectiv-C geradezu explodiert ist in 3 Jahren? Java geht langsam Berg ab, .NET hällt sich ungefähr die Waage (VB--, C#++). C++ geht runter.



> Weil's der einzig  verbleibende Grund ist, wo man sich für nativen Code entscheiden würde, solange man die Wahl hat und penibel Taktzyklen zählt.


Wenn Du anfängst Taktzyklen zu zählen musst Du in den vom Compiler erzeugten Code schauen - bevor der Assembler drüber fährt. Und wenn Du das machen musst, dann befindest Du Dich nicht mehr auf einem normalen PC sondern im embedded Bereich und machst Sicherheitskritische Echtzeitanwendungen. Nicht mal den aktuellen Prozessor den ich programmiere zähle ich die Taktzyklen - wozu auch?

Bei allen anderen Dingen sind die Prozessoren völlig unterfordert.



> Wenn man nicht gerade irgendwelche Microcontroller programmiert, wo ohnehin C vorherrscht,


Welcher Gedanke fördert diese Annahme? Ich habe hier ein BS für einen Microcontroller das (offiziell) seine API nur als C++ bereitstellt.



> lohnt sich für einen "bereits" Java-Entwickler die zusätzliche Erlernung von C++ kaum.


Welcher Gedanke fördert nun diese Annahme?


----------



## Marco13 (19. Okt 2012)

C++ lohnt sich auf jeden Fall, weil es besser und schneller ist als Java. 

:joke:

Ich würde fast so weit gehen, zu sagen, dass sich jede (echte) Programmiersprache "lohnt". (~"Lohnt sich Spanisch wenn man schon Italienisch kann?") Das übliche Bashing und was für welchen speziellen Fall in welcher Hinsicht "besser" ist, findet sich in ungefähr 31231 Threads hier im Forum und im Netz insgesamt.


----------



## Beni (19. Okt 2012)

Ein bisschen C++ erweitert sicherlich den Horizont. 

Da kann man mal genauer beobachten, was der Rechner macht (z.B.: Heap vs Stack)
Oder neue Konzepte und deren Auswirkungen lernen, wie Templates oder "call by reference".


----------



## Rudolf (19. Okt 2012)

Das finde ich ja interessant. Warum hatte ObjiC den größten Zulauf unter den "oberen" Sprachen und warum geht der Trend für Java nach unten, hätte etwas umgekehrtes erwartet


----------



## Empire Phoenix (19. Okt 2012)

Weil wenn man für gayphones entwickeln muss nunmal in objectc programmiert (erzwungenermaßen) , und da das richtig kacke dokumentiert ist muss man halt mehr nachfragen / googlen ect, und schon hat man bei der art wie dieser index generiert wird einen richtig hohen wert 

(An all Mac Fag's es handelt sich hierbei um eine halb sarkastische aussage, ihr braucht nicht aus protest flugzeuge in hochhäuser fliegen)


----------



## Spacerat (19. Okt 2012)

mogel hat gesagt.:


> Ich habe hier ein BS für einen Microcontroller das (offiziell) seine API nur als C++ bereitstellt.


Dabei kann es sich nur um ein Bundle wie z.B. Arduino handeln (Arduino selber natürlich nicht, denn da steht offiziell C/C++) und nicht um eine reine Prorgammierschnittstelle (ISP InSystemProgrammer). Letztere lassen die Sprache relativ (auf der Treiber CD ist eigentlich immer ein C-Compiler zu finden) offen, weil letztendlich auch da nur für den Controller verständlicher "Bytecode" (prozessorabhängiger Maschinencode) übertragen wird.
Was immer wieder gerne vergessen wird, ist die Tatsache, dass Programmiersprachen eigentlich nur Dolmetscher zwischen Mensch und Maschine sind und als Programmiersprache deswegen nur das in Frage kommt, was man am ehesten versteht.
C++ ist und bleibt die Weiterentwicklung von C, bietet unter anderem OOP dessen Kenntnisse man sich als Javaentwickler hoffentlich bereits angeeignet hat. Warum also sollte man sich noch mit C++ belasten, wenn man mit Java und C selbiges erreicht. Den Horizont erweitern, ist eine gute Idee aber nur wenn man plant, es auch zu nutzen. Das wäre für Java vorwiegend der Microcontroller-Bereich, obwohl ich da auch schon von Javaprozessoren gehört, mich aber noch nie damit befasst habe.
Das hier ist zwar 'ne Einführung in die Programmierung, könnte aber dennoch hilfreich sein.


----------



## s4ke (19. Okt 2012)

Spacerat hat gesagt.:


> Je mehr Sprachen man sich aneignet, desto häufiger verhaspelt man sich.



Genau meine Meinung! Erst die eine Sprache zu einem Punkt lernen, dass man sagen kann, man sei sattelfest und fängt an an den Grundlagen zu kratzen. Dann kann man sich auf die nächste Sprache stürzen.


----------



## KuhTee (19. Okt 2012)

Rudolf hat gesagt.:


> Auf der anderen Seite ist Java konzeptionell weiter als C++ und bringt bei Performance und Programmiereleganz einiges mehr als C++...


Zum Beispiel? Du meinst doch nicht etwa solch abgrundtief hässliches wie Java Generics?


Warum man C++ lernen sollte? Nun, um richtig programmieren zu lernen natürlich  Viele Java Entwickler haben null Ahnung, wenns mal etwas technisch tiefer gehen soll. Zwar geht es auch mit C technisch in die Tiefe, aber C++ ist wesentlich mehr als nur eine "Erweiterung" von C. Gerade die Art und Weise wie C++ mit Klassen und Objekten umgeht ist für Java Entwickler immer ganz toll und begeisternd, wenn sie dann mal durchgestiegen sind.


----------



## Helgon (20. Okt 2012)

Da muss ich KuhTee zustimmen.. ich bin Fanboy von gar nichts, also nicht falsch verstehen, aberals ich dann C++ "richtig gelernt" hab, hatte ich manchmal wirklich Euphorie momente, weil alles plötzlich einen Sinn ergab. Einfach weil es notwendig war, dies im Zuge dessen was im Buch gemacht wurde zu erklären (in dem C++ Buch). Oder das man nicht nur auf Funktionen des Java SDK zugreift, sondern sich wirklich mal selber Gedanken macht wie etwas funktioniert (klar gibt es bspw auch Boost, aber mal davon abgesehen).

Ich z.B. hab C++ "nur" für DirectX gelernt. Wofür auch sonst, Treiber schreib ich keine (warum oder wofür auch), für Microcontroller nimmt man wie gesagt eh C, und wenns an etwas mit ner GUI geht lieber C# oder Java, was wesentlich bequemer als der "Umweg" über QT ist. 

Trotzdem muss ich sagen, dass mir das C++ lernen am meisten gebracht hat - in Punkto das ich wirklich verstehe was da passiert und wie und eben nicht nur das etwas passiert.


----------



## Spacerat (20. Okt 2012)

KuhTee hat gesagt.:


> Zum Beispiel? Du meinst doch nicht etwa solch abgrundtief hässliches wie Java Generics?
> 
> Warum man C++ lernen sollte? Nun, um richtig programmieren zu lernen natürlich  Viele Java Entwickler haben null Ahnung, wenns mal etwas technisch tiefer gehen soll. Zwar geht es auch mit C technisch in die Tiefe, aber C++ ist wesentlich mehr als nur eine "Erweiterung" von C. Gerade die Art und Weise wie C++ mit Klassen und Objekten umgeht ist für Java Entwickler immer ganz toll und begeisternd, wenn sie dann mal durchgestiegen sind.


Trolling vom feinsten. :lol:
Wenn man richtig programmieren will, sollte man sich Maschinensprache aneignen. Ansonsten ist's doch wohl Sache des Entwicklers, welchen "Dolmetscher" er bevorzugt bzw. bevorzugen kann. Je nach dem, was möglich ist und man besser versteht.
Hier steht auch nirgends, dass C++ 'ne simple C-Erweiterung ist, sondern 'ne Weiterentwicklung von C, mit viel neuem und einigen "Einschränkungen" (also Dinge die, warum auch immer, in C++ nicht mehr funktionieren). Wär's nur 'ne Erweiterung, gäbe es keinen Unterschied zu C, denn man könnte beliebig zwischen den Sprachen wechseln.


----------



## Network (20. Okt 2012)

Die Frage nach dem lohnen:
- Hobbytechnisch werden dich andere Programmiersprachen nicht weiter bringen als es bereits Java tut, sie werden dich sogar eher zurücksetzen. Es gibt keinen Grund eine andere Sprache zu erlernen der selben Generation.

- In der Industrie ist es aber wichtig, nicht nur die theoretische Syntax eines Programmes zu kennen (das hilft dir schonmal überhaupt nicht weiter) sondern eine Sprache musst du verstehen und anwenden können in verschiedenen Bereichen.
-> Wir hatten es hier mal vor kurzem da hat die eine Seite mit C++ und wir mit Java gearbeitet.
Der Retter des Tages war dann der der für die connection der Systeme gesorgt hat und zwar in einem passablen Zeitraum.
Um nur ein praktisches Beispiel zu nennen.

In einem Vorstellungsgespräch angeben zu können, man kenne mindestens eine weitere Sprache als die firmenspezifische bringt oft schonmal einen sehr großen Bonus ein.

Verschiedene Situationen können auftreten, oder Nebenprojekte entstehen die in einer anderen Sprache gelöst werden müssen (Und da gibt es so einige Gründe) wie bspw. (um nur noch ein Beispiel zu nennen) hat ein Kundenpc nicht unbedingt eine JVM auf seinen (meist Windows) Rechnern installiert und das dauert dann häufig mal eine ganze Woche bis auf einem Firmenpc eine neue Software installiert ist.
Dann ist es natürlich besser Sprachen zu verwenden die direkt jeder Windows-PC ausführen kann.
Und an solchen Situationen revanchiert sich die investierte Zeit.

Gruß
Net

PS: Programmiersprachen sind für die meisten Entwickler oftmals soetwas wie Religionen. Und da jeder alles bockig in seiner Programmiersprache haben will...


----------



## Gast2 (20. Okt 2012)

Spacerat hat gesagt.:


> Dabei kann es sich nur um ein Bundle wie z.B. Arduino handeln


schön das für Dich die Welt nur Schwarz und Weiß ist - AixControl | AixOS Real-time Operating System



> Warum also sollte man sich noch mit C++ belasten, wenn man mit Java und C selbiges erreicht.


Das funktioniert nur weil Du C++ nicht verstanden hast. OOP macht mir auf dem BlackFin die Entwicklung um einiges leichter und weniger Fehleranfällig gegenüber C. Und der Destruktor ist ein Segen (auf dem Cupid) - ich vermisse diesen unter Java genau so wie unter .NET. (Das Aufräumen des Objektes vom GC ist für mich ein untragbares nicht deterministisches Verhalten)



> Den Horizont erweitern, ist eine gute Idee ...


das ist es immer - egal bei welchem Thema

habd, mogel


----------



## Spacerat (20. Okt 2012)

mogel hat gesagt.:


> schön das für Dich die Welt nur Schwarz und Weiß ist - AixControl | AixOS Real-time Operating System
> ...
> Das funktioniert nur weil Du C++ nicht verstanden hast. OOP macht mir auf dem BlackFin die Entwicklung um einiges leichter und weniger Fehleranfällig gegenüber C. Und der Destruktor ist ein Segen (auf dem Cupid) - ich vermisse diesen unter Java genau so wie unter .NET. (Das Aufräumen des Objektes vom GC ist für mich ein untragbares nicht deterministisches Verhalten)


Also ich würde diese AIX-Geschichte oder Cupid (kenn' ich beides nicht) nicht gerade als Microcontroller bezeichnen, Microcontroller sind meines Wissens einfache ICs.
Ich habe C++ nicht blos nicht nur verstanden, ich hab's mir noch nicht mal im Detail angeschaut, weil es halt noch nicht nötig war. OOP programmiere ich in Java und wenn etwas nicht in Java zu realisieren ist, bau' ich halt per JNI und C ein natives Binding. Das man sich in Java auf den GC nicht verlassen kann, ist richtig, aber es gibt ja glücklicherweise Techniken, mit denen man Speicher- und GC freundlich programmieren kann. Zumindest muss man sich weniger Gedanken um Memleaks machen, nur weil man mal irgendwo vergessen hat einen Destruktor aufzurufen.
Das eine Sprache fehleranfälliger sein kann, als 'ne andere, halte ich persönlich für ein Gerücht. Fehler macht nämlich ausschliesslich der jeweilige Entwickler und nur sehr wenige davon sind Flüchtigkeit, sondern entstehen eher dadurch, das der Entwickler die Programmiersprache nicht vollends beherrscht.
Das sich C++ für einen Javaentwickler nicht unbedingt lohnt, heisst ja nicht, dass C++ eine schlechte Sprache ist. Networks Beitrag kann man, bis auf die Tatsache, dass es Windows bzw. der Hardware völlig egal ist, durch welchen Sprachkompiler die *ausführbaren* Kompilate gejagt wurden, nur unterschreiben.


----------



## Antoras (20. Okt 2012)

Network hat gesagt.:


> Die Frage nach dem lohnen:
> - Hobbytechnisch werden dich andere Programmiersprachen nicht weiter bringen als es bereits Java tut, sie werden dich sogar eher zurücksetzen. Es gibt keinen Grund eine andere Sprache zu erlernen der selben Generation.


Wie wäre es mit: Es macht Spaß und man kann etwas Lernen? Nur darauf kommt es doch bei Hobbies an.



Network hat gesagt.:


> PS: Programmiersprachen sind für die meisten Entwickler oftmals soetwas wie Religionen. Und da jeder alles bockig in seiner Programmiersprache haben will...


Nach der Logik sind Frauen und Autos für die meisten Leute auch so etwas wie Religion, schon mal daran gedacht?



Spacerat hat gesagt.:


> Zumindest muss man sich weniger Gedanken um Memleaks machen, nur weil man mal irgendwo vergessen hat einen Destruktor aufzurufen.


Wer in C++ daran denken muss Destruktoren aufzurufen, der kann nicht vernünftig C++ programmieren. Es gibt da was, das nennt sich RAII.



Spacerat hat gesagt.:


> Das eine Sprache fehleranfälliger sein kann, als 'ne andere, halte ich persönlich für ein Gerücht. Fehler macht nämlich ausschliesslich der jeweilige Entwickler und nur sehr wenige davon sind Flüchtigkeit, sondern entstehen eher dadurch, das der Entwickler die Programmiersprache nicht vollends beherrscht.


Ich würde sagen, dass Flüchtigkeitsfehler öfter vorkommen. Jede NPE, AIOOBE, IAE usw. ist ein Flüchtigkeitsfehler.


----------



## KuhTee (20. Okt 2012)

Spacerat hat gesagt.:


> Trolling vom feinsten. :lol:


Aja...



Spacerat hat gesagt.:


> Ich habe C++ nicht blos nicht nur verstanden, ich hab's mir noch nicht mal im Detail angeschaut, weil es halt noch nicht nötig war.


Aha. Also hast du keine Ahnung und meinst hier gute Ratschläge verteilen zu müssen?



Spacerat hat gesagt.:


> Zumindest muss man sich weniger Gedanken um Memleaks machen, nur weil man mal irgendwo vergessen hat einen Destruktor aufzurufen.


Wie schon gesagt wurde: Allein diese eine Aussage zeigt, dass du keine Ahnung von C++ hast, nicht weisst wie man damit programmiert, und trotzdem spielst du hier den Checker. Klingt für mich nach... hm... wie war das Wort doch gleich... ? 

Ich hab eben schon mehrfach gesehen, wie (durchaus gute) Java Entwickler das erste mal mit C++ entwickelt haben. Da herrschte dann noch das falsche Denken "wenn man eine kann, kann man alle, Unterschiede sind nur Syntax" vor, und schon wurden riesige Objekte kopiert, Objekte beim Kopieren versehentlich geändert, und einfach umständlich programmiert (nämlich nach Java Art). Irgendwer schrieb hier, dass Java eleganter als C++ wäre... ach kommt schon, Java ist eine ungemein geschwätzige Sprache mit vielen Macken (und einem riesigen Auswahl an Bibliotheken, dafür mag ich es).

Vielleicht sollte man einfach C++ lernen um zu verstehen, was an Java alles Mist ist  (Generics, Try-with-ressources, als "Referenzen" bezeichnete (Null-)Pointer, ...). Dann fällt es einem auch leichter, für das jeweilige Projekt das richtige Werkzeug zu wählen. Denn das ist bei weitem nicht so egal, wie es hier manche darstellen.


----------



## Spacerat (20. Okt 2012)

KuhTee hat gesagt.:


> Aha. Also hast du keine Ahnung und meinst hier gute Ratschläge verteilen zu müssen?


Ja, das mein' ich. Warum auch nicht.


KuhTee hat gesagt.:


> Wie schon gesagt wurde: Allein diese eine Aussage zeigt, dass du keine Ahnung von C++ hast, nicht weisst wie man damit programmiert, und trotzdem spielst du hier den Checker. Klingt für mich nach... hm... wie war das Wort doch gleich... ?


Gehen dir die Argumente aus, oder was? Hier geht's darum, ob es sich lohnt als Javaentwickler noch C++ zu lernen. Die Frage ist doch, wofür sollte man. Die Antwort: "Aber bitte, wenn's dir Spass macht."


KuhTee hat gesagt.:


> Irgendwer schrieb hier, dass Java eleganter als C++ wäre... ach kommt schon, Java ist eine ungemein geschwätzige Sprache mit vielen Macken. Vielleicht sollte man einfach C++ lernen um zu verstehen, was an Java alles Mist ist


Klar... Macken hat C++ natürlich keine. Aber was soll's, Java mag vllt. beim Tiobe-Index gefallen zu sein, aber hast dir C++ mal angeschaut? Und dann nicht nur die roten Pfeile, sondern das Ganze Programm: Ratings, Deltas, 10-Jahres-Übersicht. Na was soll's... kann mir sehr gut vorstellen, dass viele C++-Lobbiisten so zwischen 2004 und 2005 irgendwie den Verstand verloren haben. Sieht ja aus wie'n Börsencrash. Mir sagen diese "Linien" jedenfalls, dass ich "genug" Ahnung von C++ habe, um zu wissen, das ich es nicht brauche: "Es gibt da 'ne Programmiersprache, die soll nicht so Kagge sein wie Java. Nur was daran besser ist, können nicht mal die vernünftig in wenige Worte packen, die es eigentlich können müssten. Viel schlimmer noch, sie diskreditieren auch noch meine Frau... ach nee, mein Auto... oder war's doch nur meine Religion?"


----------



## Gast2 (20. Okt 2012)

;(



Spacerat hat gesagt.:


> Also ich würde diese AIX-Geschichte oder Cupid (kenn' ich beides nicht) nicht gerade als Microcontroller bezeichnen, Microcontroller sind meines Wissens einfache ICs.


Wie kann man sich nur selber so disqualifizieren?? AixControl stellt komplette Boards mit Microcontrollern her speziell abgestimt auf die Bedürfnisse des Kunden. Dieser Aussage entnehme ich also das Du Dich mit dem Thema noch nichtmal auseinander setzen willst.



> Ich habe C++ nicht blos nicht nur verstanden, ich hab's mir noch nicht mal im Detail angeschaut,


ach - und wieso meinst Du dann hier irgendwas über C++ behaupten zu können? Ich programmiere auch mit PHP und dennoch würde ich mir nicht anmaßen anderen PHP ausreden zu wollen. Dafür programmiere ich zu wenig damit.



> OOP programmiere ich in Java und wenn etwas nicht in Java zu realisieren ist, bau' ich halt per JNI und C ein natives Binding.


ah ja - wenn es mit C++ um Wochen einfacher wäre würdest Du Dir dennoch eine JNI/C Brücke bauen....



> Zumindest muss man sich weniger Gedanken um Memleaks machen, nur weil man mal irgendwo vergessen hat einen Destruktor aufzurufen.


Gratulation - Window (Java 2 Platform SE v1.4.2) - setzt Dich doch mal bitte mit Java und GC auseinander. Und im übrigen hat .NET das gleiche Problem. Das ist auch der Grund wieso ich es nicht verstehe warum .NET und Java keine Destruktoren mehr haben.

havbd, mogel


----------



## JohannisderKaeufer (20. Okt 2012)

Ausgehend von einem Java-Entwickler:

Wenn jemand C++ - Entwickeln möchte, dann soll er C++ lernen.

Wenn jemand ein besserer Programmierer werden möchte, dann würde ich nicht zusätzlich C++ lernen.


Programmiersprachen entstehen oft aus einer Problem-Domäne heraus. 
Erlang für verteilte hochverfügbare Systeme.
Lisp als Funktionale Sprache.

Und wenn ich nun ein besserer Programmierer werden möchte, würde ich mir auf diese Art die Sprache aussuchen die ich dazulernen möchte um die konzepte zur Lösung der Probleme zu erlernen, weshalb diese Sprachen entstanden sind.

Java und C++ sehe ich in dieser Form konzeptional zu nahe beieinander.


----------



## JavaMeetsBlueJ (20. Okt 2012)

Hier mal eine kleine Statistik von Gulp.de. Zeitraum: 09.12


----------



## ...ButAlive (20. Okt 2012)

Meiner Meinung nach, ist das schwerste bei der Softwareentwicklung Probleme zu lösen. Die Lösung dann in Form von Quellcode niederzuschreiben, ist  im Vergleich wieder einfach.

Wenn man eine Sprache lernt, lernt man nicht nur Syntax, sondern Konzepte, neue Frameworks und neue Herrangehensweißen.

Das ist ungefähr so wie bei einem Handwerker, der einen Werkzeugkoffer hat. Man kann eine Schraube mit einem Schraubenzieher oder mit einem Akkuschrauber einschrauben. Mit dem Akkuschrauber geht es schneller, aber dazu muss man erst einmal wissen, dass es Akkuschrauber gibt und sich einen zulegen. 

Als guter Softwareentwickler muss man sich immer weiterentwickeln und seinen Werkzeugkoffer ständig erweitern. Daher ist es nie falsch eine weitere Sprache zu lernen.

Ich portiere gerade beruflich ein in C++ geschriebenes Programm nach Java, daher sind meine (zugegebenermaßen rudimentären) C++ Kenntnisse nützlich. Zwar denke ich nicht, dass ich je als C++ Entwickler arbeiten werden, aber alten Code zu portieren kann einem immer wieder passieren.


----------



## Rudolf (20. Okt 2012)

KuhTee hat zumindest damit recht, dass Try-with-ressources mehr oder weniger ein Fehler waren, was auch auf der Seite von Java bereits zugegeben wurde, die null Pointer sind aber ok, solange man damit Fehler auslöst und nicht damit programmiert. Und Ja ich habe bereits mitbekommen, dass C/C++ mehr im Bereich Generics drauf haben als Java.

Nun frage ich mich aber, warum Java Destruktoren haben sollte? Ist es nicht genau das eine der stärken von Java, das es sich um die Objektverwaltung keine Gedanken machen muss? Und was dispose als Argument zu suchen hat, kann ich auch nicht nachvollziehen. vielleicht mag mir das mal hier einer erklären.


----------



## Gast2 (20. Okt 2012)

Moin,



Rudolf hat gesagt.:


> Nun frage ich mich aber, warum Java Destruktoren haben sollte? Ist es nicht genau das eine der stärken von Java, das es sich um die Objektverwaltung keine Gedanken machen muss? Und was dispose als Argument zu suchen hat, kann ich auch nicht nachvollziehen. vielleicht mag mir das mal hier einer erklären.


Wenn Du Dir mal genau durch liest welche Aufgabe Dispose hat (egal ob Java oder .NET) wirst Du feststellen das sich genau hier die Objektverwaltung selber ins Bein schießt.

In der Methode Dispose werden native Resourcen freigeben. Unter .NET ist das z.B. alles was mit GDI+ zusammen hängt. Wenn Du also jetzt ein Objekt erzeugst und bevor Du die Referenz weg wirfst kein Dispose aufrufst, erzeugst Du Memory-Leaks. Eigentlich genau das was beide Sprachen verhindern wollen. Ob ich jetzt an der Stelle manuell Dispose aufrufe oder wie unter C++ das Objekt mittels delete (und damit Destruktor) zerstöre kommt aufs gleiche raus.

Das Dumme an der Stelle ist das beide Sprache eben genau das breit treten das man sich nicht um die Speicherfreigabe kümmern muss. Zwar bietet C# an der Stelle using an, aber wenn ich ein Objekt länge brauche muss ich wieder vorher Dispose aufrufen. Und beide Sprachen greifen (naturbedingt) auf Systemresourcen zu: Fenster, Grafiken, blabla.

Ein kleines Beispiel


```
public static void main(String[] args) {
	new MyFrame(false);
	
	Thread t = new Thread(new Runnable() {
		@Override
		public void run() {
			System.gc();
			System.runFinalization();
			try {
				Thread.sleep(100);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	});
	t.start();
}
```

Der Thread dient nur dazu um den GC zu bitten mal etwas zu arbeiten - ob er es wirklich macht weis ich nicht.


```
public class MyFrame extends JFrame {

	private boolean single = false;
	
	public MyFrame(boolean single) {
		System.out.println("Konstruktor");
		
		setBounds(0, 0 + (single?100:0),  200, 50);
		setVisible(true);
		this.single = single;

		if (!single) {
			new MyFrame(true);
			this.setTitle("Main");
			setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
		} else {
			this.setTitle("Child");
			setDefaultCloseOperation(JFrame.HIDE_ON_CLOSE);
		}
	}
	
	@Override
	public void dispose() {
		super.dispose();
		System.out.println("dispose aufgerufen -> " + (single ? "child" : "main"));
	}
	
	@Override
	protected void finalize() {
		try { super.finalize(); } catch (Throwable e) { e.printStackTrace(); }
		System.out.println("finalize aufgerufen -> " + (single ? "child" : "main"));
	}
}
```

Es wird weder finalize noch dispose aufgerufen. Zu Laufzeit kann sein das der GC einfach nicht will - was in Ordnung ist (trotz das ich ihn persönlich bitte was zu machen). Aber spätestens wenn das Hauptfenster geschlossen wird sollte doch wenigstens irgendwas aufgerufen werden. Die Dispose Methode (zumindest für JFrame) wird erst bei setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE) aufgerufen. (Im Übrigen auch ohne das ich den GC bitte mal aufzuräumen)

Solange wie es nur ein Programm ist was morgens startet und abends beendet wird, kann über das Detail (meistens) hinweg gesehen werden. Das BS räumt anschließend freundlicher weise alles sauber auf. Aber hast Du das auf einem Server, holst ständig Resourcen und nicht via Dispose frei gibst, dann frisst sich der Server voll - das ist schlecht.

Ich arbeite beruflich zu wenig mit Java, aber ich habe ein Beispiel unter C#. Ca. 80 Kameras liefern 1x pro Sekunden ein Jpeg-Bild (zumindest hole ich es). Dann male ich darauf einen Zeitstempel und speichere die Dinger in einer DB. Nach dem Speichern habe ich, entsprechend der allg. Aussage der Hersteller, die Referenz einfach "vergessen". Nach ca. 24 bis 48 Stunden hat sich der Server entsprechend voll gefressen und fing an Arbeitspeicher auf die Festplatte auszulagern, irgend wann knallt es eben. Erst nachdem ich nach dem Speichern noch Dispose aufgerufen habe, war der Speicherverbrauch vernüftig.

hand, mogel


----------



## KuhTee (20. Okt 2012)

Spacerat hat gesagt.:


> Hier geht's darum, ob es sich lohnt als Javaentwickler noch C++ zu lernen. Die Frage ist doch, wofür sollte man. Die Antwort: "Aber bitte, wenn's dir Spass macht."


In welcher Sprache wird eigentlich so eine JVM in der Regel entwickelt?  Fakt ist, dass ca 80 bis 90% der Software auf meinem Rechner (ohne OS) in C++ geschrieben ist. Auf den meisten PCs wirds ähnlich aussehen. Fakt ist auch, dass C++ in der Industrie ungemein wichtig ist. Natürlich, die typischen Webanwendungen schreibt keiner in C++. Aber die Welt ist _deutlich_ größer.



Spacerat hat gesagt.:


> Klar... Macken hat C++ natürlich keine.


Sagt wer?



Spacerat hat gesagt.:


> Aber was soll's, Java mag vllt. beim Tiobe-Index gefallen zu sein, aber hast dir C++ mal angeschaut? Und dann nicht nur die roten Pfeile, sondern das Ganze Programm: Ratings, Deltas, 10-Jahres-Übersicht.


Mal abgesehen davon, dass der Tiobe-Index immer mit Vorsicht zu genießen ist (man kann ihn auch dahingehend interpretieren, dass Java so bescheiden ist, dass alle Welt Fragen hat), frage ich mich, was genau du damit aussagen willst? Die Notwendigkeit und Sinnhaftigkeit einer Sprache am Tiobe-Index festmachen? Das wird langsam lächerlich. Also wenn man Java kann, bedeutet das, dass PHP, JavaScript, SQL, Lisp usw alle unnötig sind, weil Java im Index höher steht?


----------



## Spacerat (20. Okt 2012)

mogel hat gesagt.:


> AixControl stellt komplette Boards mit Microcontrollern her speziell abgestimt auf die Bedürfnisse des Kunden. Dieser Aussage entnehme ich also das Du Dich mit dem Thema noch nichtmal auseinander setzen willst.


Nee, das ging in den falschen Hals, über dieses werde ich mich schon informieren. Ich kannte es wirklich noch nicht. Ob ich's (inkl. C++) dann auch brauche ist 'ne andere Geschichte. Immerhin; Danke für den Tipp.
Im übrigen masse ich mir nicht an, dem TO etwas auszureden, sondern überlasse es ihm. Ihr (du und QT) dagegen, masst euch an, soviel über beide Sprachen zu wissen und wisst über Java nur die Hälfte und über C++ anscheinend gar nichts, sonst würdet ihr mit Beispielen von dem was ihr wisst nicht so hinterm Berg halten und nicht dauernd nur Java kritisieren.

Zum GC... wenn man sich mit damit richtig auseinander setzen würde, würde man wissen, dass man von "finalize()", "dispose()", "System.gc()" und Zeugs besser Abstand nehmen sollte, diese Dinge sind offensichtlich "broken by Design" (das hab' ich aus diesem Forum), vermutlich, weil man der Annahme war, unbedingt Destruktoren zu benötigen. Die JVM gibt zur Laufzeit kein einziges Byte mehr an das OS frei (java.nio ist 'ne Ausnahme) sondern nur an den Heap. Die JVM verwaltet Objekte in Scopes welche penibel pro Objekt gemapped weden. Bei Zuweisungen wird geprüft, ob die Scope-Liste des alten Wertes (das gilt natürlich nur für Objekte) noch andere Scopes enthält (Was Scopes sind muss man hoffentlich nicht erklären). ist dies nicht der Fall, wird der Objektspeicher an den Heap zurückgegeben (eine Freigabe an das OS würde btw. den Heapspeicher extrem fragmentieren). Es werden also zu keiner Zeit irgendwelche Destruktoren gebraucht. Hätte gerne mal gewusst, wieso man das in C++ nicht auch so macht -  Moment... war da nicht was mit Operatorüberladung, innklusive Zuweisungsoperator?

@KuhTee:


> Fakt ist, dass ca 80 bis 90% der Software auf meinem Rechner (ohne OS) in C++ geschrieben ist.


Und das weis man bei hypothetisch 80 - 90% closed Source Software auf seinem Rechner natürlich genau. Keine Ahnung, warum man mit einem Community-Index vorsichtig sein sollte. Evtl. hat ja wirklich keiner Begriffen, was damals mit der Einführung von C# passiert ist und wieso sich das DotNet-Framework unter Windows nicht mehr (oder nur sehr schwer) deinstallieren lässt (und ich rede hier nicht vom Clientprofile), schon gar nicht die, die 90 - 100% open Source (inkl. OS) auf ihrem Rechner haben, von der man dann auch weis, dass sie in C++ geschrieben wurde. Aber Linux ist nun mal nicht da, wo es sein sollte. In Industrie und Verwaltung herrscht immer noch Windows vor, wo man anscheinend inzwischen auch mehr auf portablen Bytecode setzt.


----------



## Empire Phoenix (21. Okt 2012)

Reiens c++ in linux krams naja gelacht.

ist schon aufällig das man bei fast jedem linux dies hier mit installiert hat:
Low Level Virtual Machine ? Wikipedia
von den phython scripten die schon eher an programme grenzen zu schweigen.

AHja und dann war da ja noch die sache das größere teile des kernels in c und nicht in c++ sind.
Linus Torvalds: Why C++ Sucks | CIO Blogs


----------



## Spacerat (21. Okt 2012)

Empire Phoenix hat gesagt.:


> Reiens c++ in linux krams naja gelacht.
> 
> ist schon aufällig das man bei fast jedem linux dies hier mit installiert hat:
> Low Level Virtual Machine ? Wikipedia
> ...


Heisst das etwa, dass es nicht mal 90 bis 100% C++ auf anderen Rechnern ausser KuhTees sein können? Ich hab' das ehrlich gesagt nur über seine Zahlen geschätzt. Und nicht nur das. Selbst die Aussage, dass es sich dabei nur um ein OpenSource OS wie Linux handeln könnte war nur geraten. Wenn er damit also Werbung bzw. Überzeugungsarbeit für die C++-Lobby machen wollte, ging der Schuss eindeutig nach hinten los. Mich Unwissenden einfach in die Irre führen... herzlichen Dank. 
Ausserdem: Was ich weiter oben bereits für Windows und der Hardware auf der es läuft sagte, gilt auch überall sonst. Maschinen ist es egal, in welcher vom Menschen verständlicheren Sprache ein Programm geschrieben wurde. Solange es die Maschine versteht (und die versteht nun mal nur Maschinencode) gibt's kein Problem.
[EDIT]Wer im übrigen der Meinung ist, ist würde zu viel "nur Annehmen", Raten oder mir schlicht aus dem Ärmel schütteln, darf dies ruhigen Gewissens tun, denn irgendwie liegt ihr damit Richtig. Wen das aber letztendlich Disqualifiziert sei mal dahingestellt. Korrekte Annahmen bewahren einen vor Fehlentscheidungen und von falschen Annahmen lernt man nur dazu.[/EDIT]


----------



## schalentier (21. Okt 2012)

Mehrfach wurde hier auf die Platformunabhaengigkeit hingewiesen. 

Die soll ja bei Java besser sein. Ich frag mich dann immer, wieso gibt es eigentlich JNI, welches man (meistens) mit C/C++ programmiert, wenn doch Java angeblich platformunabhaengiger ist, als C/C++?

Die ganze Diskussion ist fuern A****, fuer einen guten Entwickler lohnt es sich IMMER, eine neue Sprache zu erlernen. Da muss man imho auch keine Argumente anbringen, eigne Erfahrungen sind einfach essentiell, um sinnvolle Diskussionen fuehren zu koennen. 

Guggt man sich heute aber C++ an, so sollte man unbedingt gleich C++11 nehmen.


----------



## Gast2 (21. Okt 2012)

Moin,



Spacerat hat gesagt.:


> wird der Objektspeicher an den Heap zurückgegeben (eine Freigabe an das OS würde btw. den Heapspeicher extrem fragmentieren).


etwas weiter führende Lektüre - MMU und Paging



> Es werden also zu keiner Zeit irgendwelche Destruktoren gebraucht.


es geht an der Stelle noch immer um Dispose und *native* Resourcen - das wo die JVM bzw. .NET nicht ran darf um es umherzuschieben und man es manuell aufräumen muss



> Hätte gerne mal gewusst, wieso man das in C++ nicht auch so macht


das ließ mal bitte genauer nach was der JIT-Compiler macht und was der Unterschied zwischen Java-Compiler und GCC (oder anderer) ist



> war da nicht was mit Operatorüberladung, innklusive Zuweisungsoperator?


???:L

habd, mogel


----------



## Spacerat (21. Okt 2012)

Keine Ahnung, was du meinst... MMU? Paging? Sonstwas? Damit hat man doch in der JVM gar nichts zu tun. Schlage vor, du liesst dich da noch mal selber ein. 
Wann immer man in Java ein Objekt zuweist, sind stets 2 Objekte involviert, nämlich das ursprüngliche und das neue. Die JVM holt sich also das aktuelle Object der Variable und das Scope in welcher die Variable definiert wurde. Aus einer Art [c]Map<Object, Set<Scope>>[/c] holt sich die JVM anschliessend die Scopes in welchen das Objekt zugewiesen wurde und entfernt das vorher ermittelte Scope aus dieser Liste. War es das letzte, kann das Objekt abgeräumt und der Speicher an den Heap zurückgegeben werden. Das geht alles noch recht fix. Die einzige Arbeit, die der GC nun noch hat, ist den Heap öfters mal zu defragmentieren. In C++ kann man diese "Halbautomatik" bei Zuweisungen natürlich vergessen, weil sich Operatoren inkl. des Zuweisungsoperators überladen lassen.
Und was genau meinst du mit nativen Resourcen, die man "von Hand" freigeben muss? Dateien? Grafikspeicher? Keine Ahnung. Das Betriebssystem wird jedenfalls schon beim Abräumen eines Objekts von der JVM über nicht länger benötigte Ressourcen benachrichtigt und das ohne das man "finalize()" usw. aufrufen muss. Es wird sogar dazu geraten "finalize()" und Zeugs komplett zu Vergessen, weil halt "Broken by Design". -> The Secret Life Of The Finalizer: page 1 of 2
@Schalentier: Plattformunabhängigkeit hatten wir doch vor gar nicht all zu langer Zeit in einem anderen Thread geklärt, oder war das nicht hier? Jede Sprache ist ansich Plattformunabhängig, solange ein Kompiler für die jeweilige Platfform existiert. Bytecode ist insoweit Plattformunabhängig, solange darauf Frameworks laufen, die diesen Bytecode verstehen (Portabilität).


----------



## Empire Phoenix (21. Okt 2012)

Statt finalize macht btw nen Phantomreference sinn um natives freizuräumen. Oder halt doch nen gutes altes dispose(). Wobei der meiner meinung nach wirklich wichtige unterschied ist einfach die sache dass man in java keine wildpointer haben kann. Das vereinfach das debugging von sehr großen projecten enorm. Zusammen mit den stacktraces wäre das mein arguemnt für java. c++ hat vorteile wenn es auf details ankommt. Zb physicengine wo man durch tricks etwas pro berechnung sparen kann und sich das über alles start aufaddiert.

Letztendlich kann man mit c/c++ btw auch gut platformunabhängig arbeiten. Man darf halt nur nichts platformspezifisches importieren.(oder packt sich ne middleware dazwischen) Der größere unterscheid ist, das man bei c für alle ziele compiliert und bei java für die jvm.

Btw es gibt den GCJ: The GNU Compiler for Java - GNU Project - Free Software Foundation (FSF) der im sinne von spacerats aussage java source einfach direkt auf maschinencode compiliert. 

Thema linux nur mal als beispiel für ein nicht ganz so c artiges progremm was viele linux user schon benutzt haben. http://en.wikipedia.org/wiki/Ubiquity_(software)

Btw man könnte übrigens mittels shared memory uns sowas schon direct in ajva treiber schreiben und jni umgehen
How To Write Directly to a Memory Locations In Java - Java Wiki

Darüber nachzudenken warum man das nicht tut bliebt zum selbstnachdenken als hausaufgabe stehen ^^


----------



## KuhTee (21. Okt 2012)

Spacerat hat gesagt.:


> Es werden also zu keiner Zeit irgendwelche Destruktoren gebraucht. Hätte gerne mal gewusst, wieso man das in C++ nicht auch so macht


Destruktoren ersparen einem unter Anderem solchen Müll wie Try-with-Ressources 



Spacerat hat gesagt.:


> Und das weis man bei hypothetisch 80 - 90% closed Source Software auf seinem Rechner natürlich genau.


Jeder Compiler hinterlässt Spuren. Sei es im Code oder in den Abhängigkeiten. Und wenn ein großer Teil der Software schon Abhängigkeiten zur msvcrt.dll hat, dann brauch man da nicht lange raten.



Spacerat hat gesagt.:


> Keine Ahnung, warum man mit einem Community-Index vorsichtig sein sollte.


Laut diesem Index steht Obj-C in der Wichtigkeit direkt hinter Java. Ist das realistisch? Eher nein. Der Index spiegelt vor allem auch Hypes wieder, wie eben bedingt durch den aktuellen Apple-Hype die Notwendigkeit von Obj-C. Aber die Welt besteht nicht nur als "Apps". Der Index zeigt auch, dass viele Informatiker mir schlechten Java Kenntnissen die Uni verlassen und nix weiter können. Ok, er "zeigt" es nicht, aber er zeigt das Resultat.



Spacerat hat gesagt.:


> In Industrie und Verwaltung herrscht immer noch Windows vor, wo man anscheinend inzwischen auch mehr auf portablen Bytecode setzt.


Oh, ich sage keineswegs, dass Java im Vergleich zu C++ eine untergeordnete Rolle spielt. Gerade auch in der Industrie. Nur wie gesagt, die besteht nicht nur aus Webanwendungen  Und auf dem User-PC, auf dem sich eine nicht unerhebliche Menge an Spielen befindet, ist C++ schon nahezu automatisch vorherschend. Eben durch die Games.



Spacerat hat gesagt.:


> Heisst das etwa, dass es nicht mal 90 bis 100% C++ auf anderen Rechnern ausser KuhTees sein können?


Was verdrehst du einfach meine Aussagen?



Empire Phoenix hat gesagt.:


> AHja und dann war da ja noch die sache das größere teile des kernels in c und nicht in c++ sind.
> Linus Torvalds: Why C++ Sucks | CIO Blogs


C ist eine angenehm zu programmierende Sprache, gerade für Low-Level Arbeiten. Habe damit auf dem GBA programmiert, und das macht schlichtweg Spaß. An der Stelle ist das aber eine Meinung von Torvalds, der viele Entwickler NICHT zustimmen. Man kann in C auch richtig beschissen programmieren, muss man sich nur mal sowas wie GObject anschauen *brrrrr*



Empire Phoenix hat gesagt.:


> Wobei der meiner meinung nach wirklich wichtige unterschied ist einfach die sache dass man in java keine wildpointer haben kann.


C++ bietet einem ebenfalls diese Möglichkeit. Ohne dass irgendwelche besonderen Anstrengungen nötig wären. Allerdings sind (wie bei Java) viele C++ Entwickler schlichtweg keine sonderlich guten Entwickler. Auch da herrscht häufig die Meinung "Hauptsache es läuft" vor. Wer in C++ dangling pointer produziert, kann schlichtweg nicht programmieren. Das schlimme ist ja, dass derjenige nichtmal nur unfähig ist, nein, sondern schlichtweg zu faul einfach einen Smartpointer zu verwenden. Welche das typische Ressourcen Problem (was Java ja hat) ungemein elegant löst.


----------



## Gast2 (21. Okt 2012)

Spacerat hat gesagt.:


> Keine Ahnung, was du meinst...


dann fasse ich das nochmal kurz für Dich zusammen



> icke hat gesagt.:
> 
> 
> 
> ...


Du willst Dich ja noch nicht mal damit auseinanders setzen. Das hat auch was mit der JVM am Hut, die JVM macht es selber. Aber darum geht es nicht. Ich wollte Dich eigentlich darauf hinweisen das Hauptspeicher in einem handelsüberlichen PC seit Jahren (Jahrzehnten?) nicht mehr fragmentiert wird. Ich hatte Dich auch an anderen Stellen auf entsprechende externe Quelle hingewiesen das Deine Informationen etwas falsch sind. Aber da hast Du auch nicht entsprechend reagiert.

willkommen im filter, mogel


----------



## Spacerat (21. Okt 2012)

mogel hat gesagt.:


> dann fasse ich das nochmal kurz für Dich zusammen... usw.


Wenn du meinst. Ich erkenne nur leider keinen Unterschied zwischen deinem zuletzt gesagten und meinen Äusserungen. Ganz genau, die JVM macht das selber und ich hab' sogar geschrieben wie sie das macht, aber egal (das Ganze heisst Mark and Compact Algorithmus). Also vergiss' diesen Destruktor-Blödsinn. Lt. meinem Link (du hast ihn dir nicht angesehen, oder?), wird bei "finalize()" mehr Speicher belegt gehalten als freigegeben, weil der GC diese Methoden ja auch irgendwann mal aufrufen muss.
Ach und Speicher fragmentiert nicht mehr? Das ist toll, dann benötigt man ja GC überhaupt nicht mehr. Obwohl eigentlich klar sein dürfte, dass wenn ich irgendwo im belegten Speicher mitten drin ein Objekt entsorge, ich schon mal 2 Fragmente bekomme (Mark and Sweep Algorithmus), da kann auch deine MMU oder dein Paging nicht gegen an. Ohne GC wäre man jetzt ganz schön arm dran. Ich frage mich, wessen Informationen hier falsch sind.
Naja egal... ich bin raus.


----------



## maki (21. Okt 2012)

Ach Leute, 

warum einen Flamewar starten wer die beste Religion... ähm Sprache hat?

Viele "Argumente" in diesem Thread sind nix weiter als Quatsch oder im besten Falle Trolling ("Warum man C++ lernen sollte? Nun, um richtig programmieren zu lernen natürlich Viele Java Entwickler haben null Ahnung, wenns mal etwas technisch tiefer gehen soll"), wer das nicht glaubt solle mal Empire Phoenix link folgen (Linus Torvalds: Why C++ Sucks | CIO Blogs) und ein bisschen drüber nachdenken was damit gemeint sein könnte...

C, C++, C#, Groovy, JavaScript, Ruby,  etc. pp. sind alles Sprachen die den "Horizont" erweitern können aber nicht müssen, aber da gibt es ja noch viel mehr.

Alles in allem bitte freundlich bleiben und immer daran denken:
EIn Javaentwickler ist nicht automatisch schlauer/schöner/besser als ein Assembler Entwickler und umgekehrt.


----------



## Gast2 (22. Okt 2012)

Also ich kann nur soviel sagen:

Ich bin beruflich von C++ auf Java übergestiegen.
C++ bietet durchaus Vorteile, z.B. ist es meiner Meinung nach bequemer als Java.
Aber eigentlich gibt es kaum etwas in C++, was man mit Java nicht auch programmieren könnte, zumindest in der endgültigen Funtionalität, jedoch ist es unter Umständen schwieriger.
Hingegen gibt es wieder Fälle, in denen es umgekehrt ist.

Ob es sich in Endeffekt lohnt, muss wohl jeder für sich selbst entscheiden, aber wenn du die Zeit & Gelegenheit hast C++ zu lernen, warum solltest du sie dann nicht auch nutzen, es kann nur Vorteile bringen 

MfG J


----------



## Spacerat (22. Okt 2012)

jurom hat gesagt.:


> C++ bietet durchaus Vorteile, z.B. ist es meiner Meinung nach bequemer als Java.
> Aber eigentlich gibt es kaum etwas in C++, was man mit Java nicht auch programmieren könnte, zumindest in der endgültigen Funtionalität, jedoch ist es unter Umständen schwieriger.
> Hingegen gibt es wieder Fälle, in denen es umgekehrt ist.


Ich denke mal, das könnte durchaus an einer gewissen Vorbelastung liegen. Wenn man mit Java in die Programmierung eingestiegen ist, kann es halt passieren, dass man in C++ zu viel Java denkt, umgekehrt natürlich genauso. Deswegen trietzen sich Entwickler verschiedener Lobbies wohl auch immer, weil ihnen das Verständnis der jeweils anderen Sprache fehlt. Umdenken? Hat schon mal jemand versucht 'nem Linkshänder Rechtsschreiben beizubringen? Hab' ich (selber Linkhänder) mal versucht und das hat zumindest nicht funktioniert.
Eines ist jedenfalls sicher, die Zukunft liegt im portablen Bytecode mit wenig nativen Code. Ich meine auch, dass es möglich sein sollte, mit C++ Bytecode zu erstellen und mit Java (mit GCJ lt. Empire Phoenix anscheinend definitiv) halt auch nativen Code. Man benötigt doch eigentlich nur den richtigen Target-Kompiler. Die Annahme stützt sich darauf, dass C/C++ Kompiler für allerlei Zielsysteme (z.B. Arduino oder dem was mogel sagte) existieren. Faktisch müssen die Kompilationen nur vom jeweiligen Zielsystem verstanden werden und das diese Zielsysteme keinesfalls Quelltexte irgendeiner Form verstehen, ist wohl auch klar.


----------



## Olli_M (22. Okt 2012)

Portabler Bytecode hat sicher eine ganze Menge Vorteile. Jedoch ist bei uns gerade die Situation so, 
dass wir in den letzten Jahren viel in Java geschrieben haben (angefangen hab ich selber mit Delphi),
aber die Zielsysteme in aller Regel Windows-basiert waren. Das heisst, die ganze schöne Portabilität haben wir kaum genutzt, mussten aber immer wieder feststellen, dass Java gewissermassen in einer Art "Paralleluniversum" auf einer Windows Maschine läuft, was zwar lösbare, aber doch sehr lästige Probleme machte.

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.

Die Diskussion über dispose() und Destruktoren (die es ja z.B. in Delphi notwendigerweise geben muss) fand ich noch recht interessant. dispose() hab ich selber in Java noch nie gebraucht (und das JFrame.DISPOSE_ON_CLOSE zähle ich mal nicht dazu), das heisst aber natürlich nicht, dass es niemals gebraucht würde (es wird ja mitunter gebraucht, wie hier schon erläutert wurde). Streams muss man ja z.B. auch von Hand schliessen in Java, das nimmt einem ja auch niemand ab... GC ist schon nett, dennoch muss man einiges beim Beenden beachten.

Bei meinen ersten Monaten mit Java habe ich einige Dinge schlichtweg gehasst, vor allem GUI Programmierung mit Swing. GridBagLayout (ohne geht es oft nicht), Glues, Struts, constraints und was es sonst noch alles gibt, du liebe Zeit... :rtfm:  Ein GUI, das man mit Delphi in 2 h erstellt hat, braucht x-mal solange in Swing und sieht immer noch "naja, schön ist anders" aus...

Die reine OOP-Seite von Java ist jedoch durchaus elegant (wenngleich ich manchmal "freischwebende" Utility-Methoden wie in Delphi vermisst habe, aber das ist nur ein geringes Manko). Sogar an den vielgescholtenen Generics kann ich derzeit nicht viel Schlimmes entdecken, wenn man sie in Maßen verwendet (obwohl ich auch schon Code gelesen habe, den ich bei bestem Willen nicht mehr kapiert hab, der wimmelte nur so von <> Klammern).

Olli


----------



## KuhTee (22. Okt 2012)

Spacerat hat gesagt.:


> Deswegen trietzen sich Entwickler verschiedener Lobbies wohl auch immer, weil ihnen das Verständnis der jeweils anderen Sprache fehlt.


Schon mal auf die Idee gekommen, dass es durchaus Entwickler gibt, die in mehreren Sprachen durchaus kompetent sind?



Olli_M hat gesagt.:


> Jedoch ist bei uns gerade die Situation so,
> dass wir in den letzten Jahren viel in Java geschrieben haben (angefangen hab ich selber mit Delphi),
> aber die Zielsysteme in aller Regel Windows-basiert waren. Das heisst, die ganze schöne Portabilität haben wir kaum genutzt, mussten aber immer wieder feststellen, dass Java gewissermassen in einer Art "Paralleluniversum" auf einer Windows Maschine läuft, was zwar lösbare, aber doch sehr lästige Probleme machte.


Das habe ich bei uns im Unternehmen in einer anderen Abteilung auch schon bemerkt. Lustig ist es, wenn es dann eine in C++ geschriebene "Launcher" EXE gibt 
Übel wird es aber dann, wenn in Java geschriebene Software nicht mehr unter Linux läuft, weil die Abhängigkeiten zu Windows so gross geworden sind und nicht ausreichend abstrahiert wurde.



Olli_M hat gesagt.:


> Sogar an den vielgescholtenen Generics kann ich derzeit nicht viel Schlimmes entdecken, wenn man sie in Maßen verwendet (obwohl ich auch schon Code gelesen habe, den ich bei bestem Willen nicht mehr kapiert hab, der wimmelte nur so von <> Klammern).


Es geht bei der Kritik an den Generics ja auch nicht um die Verwendung in Maßen, sondern um die extreme Unzulänglichkeit, insbesondere wenn man C++ Templates kennt. Im Endeffekt sind Java Generics nämlich nichts weiter als vom Compiler bzw der VM übernommenes automatisches Casting. Mit all den daraus resultierenden Problemen bzw Dingen die einfach in Java nicht machbar, in C++ aber ganz und gäbe sind (mit "nicht machbar" beziehe ich mich konkret nur auf Generics, das ist keine allgemeingültige Aussage).


----------



## schalentier (22. Okt 2012)

Olli_M hat gesagt.:


> Die reine OOP-Seite von Java ist jedoch durchaus elegant (wenngleich ich manchmal "freischwebende" Utility-Methoden wie in Delphi vermisst habe, aber das ist nur ein geringes Manko). Sogar an den vielgescholtenen Generics kann ich derzeit nicht viel Schlimmes entdecken, wenn man sie in Maßen verwendet (obwohl ich auch schon Code gelesen habe, den ich bei bestem Willen nicht mehr kapiert hab, der wimmelte nur so von <> Klammern).



Also beim besten Willen, aber als _elegant_ wuerde ich Java's OOP Konzept nun wirklich nicht bezeichnen. Es ist furchbar starr, unglaublich geschwaetzig und nicht wirklich konsistent. 

Gugg dir z.B. mal Ruby (die Sprache, nicht unbedingt gleich Rails) an. Oder auch sehr interessant: Coffeescript. Beiden gemein ist, dass man Klassen und Objekte im Code veraendern kann. Genau das, wofuer man bei Java  "Addons" braucht (asm oder AspectJ) braucht. 

Der Effekt der dadurch eintritt ist, dass man keine riesigen (oder unglaublich viele) starre Klassen schreibt, sondern eher Code-Bausteine, die dann in einer Anwendung (oder im Test) zusammenkonfiguriert werden. Dadurch ist es viel einfacher, einzelne "Features" an einer Stelle zu buendeln, anstatt den Code ueber viele andere Stellen verteilen zu muessen. Das find ich deutlich eleganter. 

Zum Thema C++ 11 weise ich nochmal auf die geniale Keynote von Bjarne Stroustrup hin!


----------



## Travel (22. Okt 2012)

KuhTee hat gesagt.:


> Im Endeffekt sind Java Generics nämlich nichts weiter als vom Compiler bzw der VM übernommenes automatisches Casting. Mit all den daraus resultierenden Problemen bzw Dingen die einfach in Java nicht machbar, in C++ aber ganz und gäbe sind (mit "nicht machbar" beziehe ich mich konkret nur auf Generics, das ist keine allgemeingültige Aussage).



http://www.oracle.com/technetwork/java/javase/generics-tutorial-159168.pdf


----------



## KuhTee (22. Okt 2012)

Travel hat gesagt.:


> http://www.oracle.com/technetwork/java/javase/generics-tutorial-159168.pdf


Ja... und?


----------



## Travel (22. Okt 2012)

KuhTee hat gesagt.:


> Ja... und?



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


----------



## Travel (22. Okt 2012)

@ 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 (22. Okt 2012)

Travel hat gesagt.:


> 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 (22. Okt 2012)

KuhTee hat gesagt.:


> 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 (22. Okt 2012)

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


----------



## Spacerat (23. Okt 2012)

KuhTee hat gesagt.:


> 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 (23. Okt 2012)

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 (23. Okt 2012)

Olli_M hat gesagt.:


> 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 (23. Okt 2012)

maki hat gesagt.:


> 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 (23. Okt 2012)

maki hat gesagt.:


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



Hm? gibts da etwas was man wissen sollte?


----------



## maki (23. Okt 2012)

.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 (23. Okt 2012)

Olli_M hat gesagt.:


> 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 (23. Okt 2012)

Spacerat hat gesagt.:


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



Spacerat hat gesagt.:


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



Spacerat hat gesagt.:


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



Spacerat hat gesagt.:


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


Yeah, Flamewar.  Was sind denn die entsprechenden Vorteile?



Spacerat hat gesagt.:


> 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 



Spacerat hat gesagt.:


> 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 (24. Okt 2012)

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 (24. Okt 2012)

KuhTee hat gesagt.:


> 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 (24. Okt 2012)

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 (24. Okt 2012)

maki hat gesagt.:


> 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 (24. Okt 2012)

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


Gilt das nicht für das meiste hier diskutierte?


----------



## KuhTee (24. Okt 2012)

Never 
Wir erschließen neue Kenntnisse hier...


----------



## Gast2 (24. Okt 2012)

Moin,



Olli_M hat gesagt.:


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



maki hat gesagt.:


> 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 (24. Okt 2012)

mogel hat gesagt.:


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


----------

