c++ vs. java... was hat zukunft
-
MenschenKenner schrieb:
Gast++ schrieb:
Btw: Zwei Menschen steigen in eine leere Fahrstuhlkabine. Beim nächsten Halt steigen drei aus.
Kommentare zum Phänomen von Experten:Experimentalphysiker: "Messfehler!"
Theoretischer Physiker: "Der Dritte hat sich reingetunnelt!"
Mathematiker: "Nun ja, wenn ein Mensch wieder einstiege wäre die Kabine erneut leer!"Ich (DER Experte): 9 Monate Fahrzeit, viel Essen und Langeweile.
Den muss ich mir merken
-
Mal kurz eine Frage in die Runde: Wieso wird eigentlich niemals davon ausgegangen das man die VM für Java ändern kann?
Ich könnte mir schon vorstellen, das man z.B. für systemnahe programmierung eine entsprechende VM nimmt, die eben die Hardware direkter ansteuert. Genauso wird es doch für zeitkritisches Java gemacht, da wird eine spezielle VM genommen.Eigentlich bräuchte man doch nur die VM auf dem System zu ändern, den Code braucht man nicht anzufassen.
Mal ein Beispiel:
-Für alle x86-Prozessoren wird die normale JVM genommen, die eben den größten gemeinsamen Nenner bildet, damit möglichst alle Java-Programme mit dieser VM laufen.
-Für spezielle Systeme, die schneller laufen müssen, wird eben eine speziellere VM eingesetzt
-Für zeitkritsche Systeme eben eine zeitkritsche VMEin weiterer Pluspunkt für eine VM:
Stellt dir vor du schreibst Heute ein Programm in C++ für eine normale x86 32Bit Maschine. In 5 Jahren sind alle 32bit Maschinen endlich weg und es gibt nur noch 256bittige. In C++ musst du dein Programm neu kompilieren, damit es den Vorteil von den jetzigen Maschinen hat. Bei Java entwickelt sich das Programm über die JVM, das heist dein Programm bleibt immer aktuell, du hast 0 Mehraufwand.Nehmen wir doch mal das Jahr2000 Problem, alle alten Programme mussten gepatcht werden, in Java verwende ich die Klasse Calendar, die dank der Entwicklung der JVM, immer richtig rechnen wird. Anstatt 1000 Programme zu patchen, reicht es das neuste JVM auf dem System zu installieren.
Setzt natürlich eine gewährte Kompatibilität vorraus.
Das kann nur von jemand kommen der noch keine größeren Projekte mit C# gemacht hat und die Sprache + .Net nur vom Hörensagen kennt... Sorry, im Vergleich zu C# + .Net unter Windows ist Java _keine_ Alternative wenn Aspekte wie Wirtschaftlichkeit und Einhalten von engen Deadlines im Vordergrund stehen...
Was kann man den in .NET was man nicht auch in Java kann?
Äh - ja, wo ist jetzt der Unterschied zu dem normalen Umgang mit Source ? Wo ist da die spezifische Reflectionnutzung ?
Was Du da beschreibst, mache ich genauso ... eben mit C++, aber das ginge mit Fortran, COBOL, ASM, .... genauso.Geht Reflection in C++ genauso wie in Java? Also kann man (nur) kompilierten Code nehmen und daraus auf alle Eigenschaften der Klasse zugreifen?
Trotzdem verbessert sich die Performance von Java natürlich von Version zu Version. Wenn man sich die Bug-Fixes anschaut, ist man sogar sehr überrascht, welch simple und effektive Performancesteigerungen selbst in Version 7 noch eingebaut werden. ...man sollte denken, das Java schon ausgereifter wäre. Naja, aber wie schon gesagt: Das wird von Menschen geschrieben. Und die entdecken auch nach 10 Jahren nochmal, dass jemand mal nicht so sehr auf irgendetwas bestimmtes geachtet hat. Sei es nun aus Fahrlässigkeit oder deshalb, weil damals noch eine völlig andere Infrastruktur anzutreffen war.
Die C++-Compiler sind ja auch nicht über Nacht geschrieben worden und die VM Sprachen werden auch erst seit kurzem entwickelt. Ausserdem greift hier wieder mein obiges Beispiel: Ein Bug in einer VM kann durch ein Update der VM behoben werden. Wegen eines Bugs im C++-Compiler muss das Programm (bzw. alle Programme) neu kompiliert werden.
Naja, aber genauso werden die C++ Compiler natürlich auch immer besser.
Und davon profitieren die Benutzer erst, wenn der Autor sich erbarmt einen Patch für sein Programm anzuferdigen.
-
DEvent schrieb:
Ein weiterer Pluspunkt für eine VM:
Stellt dir vor du schreibst Heute ein Programm in C++ für eine normale x86 32Bit Maschine. In 5 Jahren sind alle 32bit Maschinen endlich weg und es gibt nur noch 256bittige. In C++ musst du dein Programm neu kompilieren, damit es den Vorteil von den jetzigen Maschinen hat. Bei Java entwickelt sich das Programm über die JVM, das heist dein Programm bleibt immer aktuell, du hast 0 Mehraufwand.Sooo einfach ist das alles nicht. Du willst Vorteile von 64Bit-Maschinen (oder noch mehr) mit Java ausnutzen bzw. diese Maschinen voll ausnutzen? Dann hast Du ein Problem: Java ist prinzipiell auf 32Bit ausgelegt. Willst Du mal ein Array mit 5 Mrd. Einträgen nutzen? In Java kannst Du das vergessen, auch in 10 Jahren wird das nicht möglich sein. Arrays haben in Java ein Attribut length, das ein int ist. Und die Größe eines ints ist ganz genau in der Sprache festgelegt: 32 Bit. Ebenso sieht es mit vielen Rückgabewerten usw. aus, die in der Standardbibliothek auftauchen. Du hast also prinzipiell Limitierungen, wenn es darum geht, mit der technischen Entwicklung der Rechner mitzuhalten. Und diese Limitierungen wird man nicht überwinden können, denn dadurch würde ein Großteil des bereits existierenden Javacode kaputt gehen. Wenn Du die JVM oder die Standardbibliothek änderst, dann muss alter Code weiterhin lauffähig bleiben. Wie stellst Du Dir das bei solchen Änderungen vor? Sun bringt es ja noch nichtmal fertig, deprecated-Elemente nach ein paar Jahren auch tatsächlich zu entfernen.
Wenn man einen statischen Compiler wie bei C++ hat, dann sind solche Änderungen leichter durchführbar. Da muss ein Programm nur genau einmal kompilierbar sein und nicht immer. Wenn es mit einem neueren Compiler nicht mehr kompilierbar ist, dann nimmt man halt einen alten. Die Nutzung der JVMs kannst Du als Entwickler hingegen weniger kontrollieren. (Wenn man davon absieht, dass viele Programme ihre eigene JVM mitliefern.)
Insofern denke ich, dass es momentan zwar sehr gut für Java aussieht, was Nutzung usw. betrifft, langfristig gesehen wird Java aber früher als C++ an Grenzen stoßen. ...was nicht heißt, dass C++ dann wieder die bisherigen Anwendungsgebiete von Java einnimmt: Bis dahin wird sicherlich eine andere Sprache kommen.
btw: 256Bit-Rechner wird es im Breiten Einsatz für den Privatnutzer IMHO nie geben. So weit wird die technische Entwicklung nicht gehen. Mit 64Bit ist Schluss. Man kann sich ja leicht überlegen, wieviele Miniaturisierungsschritte noch kommen müssten, bis 128Bit Sinn machen. Da würde man dann bei Strukturgrößen landen, die einfach nicht vorstellbar sind.
-
Gregor schrieb:
btw: 256Bit-Rechner wird es im Breiten Einsatz für den Privatnutzer IMHO nie geben. [...]
Zitat:
"640K sollte genug für jedermann sein."
Bill Gates, 1981
-
DEvent schrieb:
Ich könnte mir schon vorstellen, das man z.B. für systemnahe programmierung eine entsprechende VM nimmt, die eben die Hardware direkter ansteuert. Genauso wird es doch für zeitkritisches Java gemacht, da wird eine spezielle VM genommen.
Eigentlich bräuchte man doch nur die VM auf dem System zu ändern, den Code braucht man nicht anzufassen.
Wie genau stellst du dir das mit "Hardware direkter ansteuern" denn vor ohne "den Code anzufassen"? Wie könnte ich denn heute schon Java-Code für den Fluxkompensator von morgen schreiben?
-
rüdiger schrieb:
pale dog schrieb:
btw, damit vm-sprachen hierbei nicht ganz alt aussehen:
so'ne vm hat die möglichkeit zur laufzeit den code zu optimieren (jit-compiler) und ihre 'virtuellen maschinenparameter' an die umgebung anzupassen. es wäre schon denkbar, dass in manchen situationen ein vm-programm scheller läuft, als eine statische 'exe'.Andererseits kann man nicht so viel Zeit für die Optimierung verwenden, da man ja alles jit machen muss. Aber der Vorteil bei der Optimierung den Java gegenüber C++ hat sind einfach: Keine Pointer. So kann man Aliasing-Probleme etc direkt ausschließen und den Code besser optimieren. Das gilt natürlich für alle Sprachen die keine Pointer haben. Daher ist Fortran zB immer noch sehr beliebt für Berechnungen.
Klar hat Java Pointer, es versteckt sie nur recht gut
(genauer gesagt, hantierst du in Java fast nur mit Pointern, auch wenn sie dort als "Referenz" bezeichnet werden und nicht durch ein explizites * gekennzeichnet werden)Und was die Entwicklung der VM angeht: Java definiert afair exakte Größen für die verwendeten Datentypen - unabhängig von den tatsächlichen Möglichkeiten des Systems. Im C++ Standard sind legiglich Mindestgrößen definiert (und es ist durchaus erlaubt, daß irgendein zukünfitger Compiler 16-Bit-char's festlegt).
-
DEvent schrieb:
...
Äh - ja, wo ist jetzt der Unterschied zu dem normalen Umgang mit Source ? Wo ist da die spezifische Reflectionnutzung ?
Was Du da beschreibst, mache ich genauso ... eben mit C++, aber das ginge mit Fortran, COBOL, ASM, .... genauso.Geht Reflection in C++ genauso wie in Java? Also kann man (nur) kompilierten Code nehmen und daraus auf alle Eigenschaften der Klasse zugreifen?...
Ich habe nie geschrieben, dass "Reflection" (eine spezielle JavaTechnik) in C++ genauso ginge !
Es geht mir darum, welche Fachlichkeit Gregor damit abbilden möchte ... und was immer er dazu bislang gesagt hat (außer dem ominösen Verweis auf sein laufendes Projekt), erledigt mein Compiler (Sprache nahezu beliebig) genauso - wenn nicht gar besser.Gruß,
Simon2.
-
CStoll schrieb:
Klar hat Java Pointer, es versteckt sie nur recht gut
(genauer gesagt, hantierst du in Java fast nur mit Pointern, auch wenn sie dort als "Referenz" bezeichnet werden und nicht durch ein explizites * gekennzeichnet werden)ja, Java arbeitet intern sogar mit pointern auf pointer...
für den benutzer ist dies alles aber nicht sichtbar, d.h. er kann sich keine 'dangling and wild' pointers einfangen oder sich mit pointerarithmetik verheddern.
wieder ein punkt für Java
CStoll schrieb:
Und was die Entwicklung der VM angeht: Java definiert afair exakte Größen für die verwendeten Datentypen - unabhängig von den tatsächlichen Möglichkeiten des Systems. Im C++ Standard sind legiglich Mindestgrößen definiert (und es ist durchaus erlaubt, daß irgendein zukünfitger Compiler 16-Bit-char's festlegt).
ja, das ist in Java festgelegt, ebenso wie die byte order. du weisst ja selbst, welche probleme unterschiedliche byte-order und plattformabhängige grössen von datentypen so mit sich bringen.
...und noch ein punkt für Javawie ist das scoring zur zeit? 15:20 für Java?
-
pale dog schrieb:
CStoll schrieb:
Klar hat Java Pointer, es versteckt sie nur recht gut
(genauer gesagt, hantierst du in Java fast nur mit Pointern, auch wenn sie dort als "Referenz" bezeichnet werden und nicht durch ein explizites * gekennzeichnet werden)ja, Java arbeitet intern sogar mit pointern auf pointer...
für den benutzer ist dies alles aber nicht sichtbar, d.h. er kann sich keine 'dangling and wild' pointers einfangen oder sich mit pointerarithmetik verheddern.
...Ach, wenn doch Sun und die anderen Java-Protagonisten das doch von Vorneherein so gut ausgedrückt hätten !!
Die Verkürzung "no pointers" bringt einfach aufs falsche Gleis.Gruß,
Simon2.
Übrigens: C++ zwingt niemanden dazu, Pointerarithmetik anzuwenden - ich selbst habe sie noch nie verwendet (außer zu Lernzwecken). Ich kann schwerlich einen Punkt für Java nur dafür vergeben, dass sie einfach eine Technik verwirft
Sonst würde ich einfach meinen eigenen Java-Nachkommen entwerfen, in dem ich 2 Features rauswerfe, die in Java von Angängern zu Schwierigkeiten geführt haben - und hätte plötzlich eine "besser Sprache".
-
pale dog schrieb:
CStoll schrieb:
Klar hat Java Pointer, es versteckt sie nur recht gut
(genauer gesagt, hantierst du in Java fast nur mit Pointern, auch wenn sie dort als "Referenz" bezeichnet werden und nicht durch ein explizites * gekennzeichnet werden)ja, Java arbeitet intern sogar mit pointern auf pointer...
für den benutzer ist dies alles aber nicht sichtbar, d.h. er kann sich keine 'dangling and wild' pointers einfangen oder sich mit pointerarithmetik verheddern.
wieder ein punkt für JavaAber dafür kann man sich ganz schnell verheddern, wenn man das Pointer-Konzept nicht verstanden hat (wenn ich in C++ ein Objekt an eine Funktion übergebe, kann ich ganz genau kontrollieren, wie der Bezug zwischen Argument und Parameter aussieht - in Java ist die Übergabekonvention fest vorgegeben.
=> Wenn du es schon so willst, Punkt für C++.(und du hast mal wieder nur die Hälfte von meinem Beitrag gelesen - der bezog sich vor allem auf das Optimierungspotential aus den (angeblich) fehlenden Pointern)
CStoll schrieb:
Und was die Entwicklung der VM angeht: Java definiert afair exakte Größen für die verwendeten Datentypen - unabhängig von den tatsächlichen Möglichkeiten des Systems. Im C++ Standard sind legiglich Mindestgrößen definiert (und es ist durchaus erlaubt, daß irgendein zukünfitger Compiler 16-Bit-char's festlegt).
ja, das ist in Java festgelegt, ebenso wie die byte order. du weisst ja selbst, welche probleme unterschiedliche byte-order und plattformabhängige grössen von datentypen so mit sich bringen.
...und noch ein punkt für JavaAber durch diese Festlegungen versperrst du dir den Weg für zukünftige Entwicklungen. C++ Compiler mit 128-Bit int's sind kein Problem, Java Compiler werden auch in Hundert Jahren noch mit 32-Bit hantieren.
=> der Punkt geht ebenfalls an C++.wie ist das scoring zur zeit? 15:20 für Java?
Keine Ahnung, ich hab' da nicht mitgezählt.
(aber wenn ich raten würde, dürfte auf lange Sicht ein unentschieden herauskommen)
-
Simon2 schrieb:
Ich kann schwerlich einen Punkt für Java nur dafür vergeben, dass sie einfach eine Technik verwirft
die technik wird ja nicht verworfen sondern abstrahiert bzw. 'gekapselt'.
daran dürften OOP-fans doch nichts auszusetzen haben...
-
CStoll schrieb:
Andererseits kann man nicht so viel Zeit für die Optimierung verwenden, da man ja alles jit machen muss. Aber der Vorteil bei der Optimierung den Java gegenüber C++ hat sind einfach: Keine Pointer. So kann man Aliasing-Probleme etc direkt ausschließen und den Code besser optimieren. Das gilt natürlich für alle Sprachen die keine Pointer haben. Daher ist Fortran zB immer noch sehr beliebt für Berechnungen.
Klar hat Java Pointer, es versteckt sie nur recht gut
(genauer gesagt, hantierst du in Java fast nur mit Pointern, auch wenn sie dort als "Referenz" bezeichnet werden und nicht durch ein explizites * gekennzeichnet werden)Ich glaube rüdiger meinte Pointer auf primitive Typen. Bei Objekten bleibt das Aliasing-Problem natürlich bestehen, aber da ist das meistens auch nicht so wichtig.
-
pale dog schrieb:
Simon2 schrieb:
Ich kann schwerlich einen Punkt für Java nur dafür vergeben, dass sie einfach eine Technik verwirft
die technik wird ja nicht verworfen sondern abstrahiert bzw. 'gekapselt'.
daran dürften OOP-fans doch nichts auszusetzen haben...
Wie jetzt ? Doch Pointerarithmetik in Java ?unsigned int i = 0x010204; unsigned char* p = (unsigned char*) &i; *p |= 0x10; *(p+1) |= 0x20;Show me ...
Gruß,
Simon2.
-
pale dog schrieb:
Simon2 schrieb:
Ich kann schwerlich einen Punkt für Java nur dafür vergeben, dass sie einfach eine Technik verwirft
die technik wird ja nicht verworfen sondern abstrahiert bzw. 'gekapselt'.
daran dürften OOP-fans doch nichts auszusetzen haben...
Ich weiß nicht, ich weiß nicht. An sich spricht natürlich nichts gegen eine Abstraktion von Zeigern. Aber IMHO macht es Java falsch und andere Sprachen, z.B. Eiffel machen es richtig. Java hat eben *keine* allgemeine Zeigerabstraktion sondern es verwendet unter der Haube Zeiger, um andere Konzepte zu implementieren. Was mir fehlt, ist eine Zeiger-Schnittstelle, mit der ich z.B. auf das erste Element in einem 'int'-Array (*nicht 'Integer'!) zeigen kann und zum nächsten Element springen kann. Cs Stärke ist, dass es sowas eingeführt hat. C++s Stärke ist, dass dieses Konzept abstrahiert und verbessert wurde ('is' sei ein 'int'-Array):
// C: int* pi = &is[0]; *++pi;// C++: vector::iterator pi = is.begin(); *++pi;Das Iterator-Konzept von Java reicht da nicht heran.
-
CStoll schrieb:
Aber durch diese Festlegungen versperrst du dir den Weg für zukünftige Entwicklungen. C++ Compiler mit 128-Bit int's sind kein Problem, Java Compiler werden auch in Hundert Jahren noch mit 32-Bit hantieren.
=> der Punkt geht ebenfalls an C++.jein
in 100 jahren wird der heutige, 32-bittige Java datentyp (int) zwar gleich bleiben, aber dafür können zusätzliche, breitere datentypen eingeführt werden, wenn bedarf bestehen sollte (deren repräsentation sich übrigens auch niemals ändern wird).
sorry, den punkt müssen wir C++ leider wieder abziehen.Simon2 schrieb:
Wie jetzt ? Doch Pointerarithmetik in Java ?
unsigned int i = 0x010204; unsigned char* p = (unsigned char*) &i; *p |= 0x10; *(p+1) |= 0x20;Show me ...
nein, so doch nicht
die pointer sind versteckt in Java.
-
pale dog schrieb:
CStoll schrieb:
Aber durch diese Festlegungen versperrst du dir den Weg für zukünftige Entwicklungen. C++ Compiler mit 128-Bit int's sind kein Problem, Java Compiler werden auch in Hundert Jahren noch mit 32-Bit hantieren.
=> der Punkt geht ebenfalls an C++.jein
in 100 jahren wird der heutige, 32-bittige Java datentyp (int) zwar gleich bleiben, aber dafür können zusätzliche, breitere datentypen eingeführt werden, wenn bedarf bestehen sollte (deren repräsentation sich übrigens auch niemals ändern wird).
sorry, den punkt müssen wir C++ leider wieder abziehen.Aber um diese breiteren Datentypen nutzen zu können, müsstest du alle deine Programme von Hand anpassen - da wünsche ich dir viel Spaß bei dem Versuch, in einem größeren Projekt alle Vorkommen von 'int' zu finden und zu entscheiden, welcher größere Datentyp für diese Werte nun ausreichend ist. Meine C++ Projekte muß ich nur neu compilieren, um die neue Architektur nutzen zu können.
Simon2 schrieb:
Wie jetzt ? Doch Pointerarithmetik in Java ?
unsigned int i = 0x010204; unsigned char* p = (unsigned char*) &i; *p |= 0x10; *(p+1) |= 0x20;Show me ...
nein, so doch nicht
die pointer sind versteckt in Java.[/quote]Und das ist das Problem
Die Pointer sind zwar da (und man muß sich immer wieder vor Augen führen, daß man in Wirklichkeit "nur" Zeiger in der Hand hält), aber wirklich nutzen kann man sie nicht.
-
pale dog schrieb:
...
Simon2 schrieb:
Wie jetzt ? Doch Pointerarithmetik in Java ?
unsigned int i = 0x010204; unsigned char* p = (unsigned char*) &i; *p |= 0x10; *(p+1) |= 0x20;Show me ...
nein, so doch nicht
die pointer sind versteckt in Java.Ergo: Dem Programmierer steht diese Technik nicht zur Verfügung => Java hat diese Technik "verworfen". Mehr habe ich nicht behauptet.
Andernfalls könnte man Fortran auch als OO-Sprache bezeichnen (die eben "OO kapselt"), wenn der Compiler in OO geschrieben ist.
Blöder als das finde ich dagegen die (schon von Konrad angeführte) Sonderrolle von int&Co (und das Fehlen von "Objektsemantik") ... aber das haben wir schon in einem anderen Thread gehabt.
Das strenge Definieren der Wertebereiche (und der internen Repräsentation) finde ich dagegen großartig ! Da man sich aber damit Optimierungspotential verschenkt, hätte ich mir einfach beides gewünscht: Datentypen, deren Repräsentation festgelegt ist und solche, die Plattformspezifika zulassen (für HW-nahe Geschichten) - vielleicht sogar einen definierten Übergang zwischen beiden.Gruß,
Simon2.
-
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
Aber durch diese Festlegungen versperrst du dir den Weg für zukünftige Entwicklungen. C++ Compiler mit 128-Bit int's sind kein Problem, Java Compiler werden auch in Hundert Jahren noch mit 32-Bit hantieren.
=> der Punkt geht ebenfalls an C++.jein
in 100 jahren wird der heutige, 32-bittige Java datentyp (int) zwar gleich bleiben, aber dafür können zusätzliche, breitere datentypen eingeführt werden, wenn bedarf bestehen sollte (deren repräsentation sich übrigens auch niemals ändern wird).
sorry, den punkt müssen wir C++ leider wieder abziehen.Aber um diese breiteren Datentypen nutzen zu können, müsstest du alle deine Programme von Hand anpassen - da wünsche ich dir viel Spaß bei dem Versuch, in einem größeren Projekt alle Vorkommen von 'int' zu finden und zu entscheiden, welcher größere Datentyp für diese Werte nun ausreichend ist. Meine C++ Projekte muß ich nur neu compilieren, um die neue Architektur nutzen zu können.
warum sollte ich in einem bereits funktionierenden programm alle 'ints' ändern wollen
das wäre doch blödsinn.CStoll schrieb:
pale dog schrieb:
Simon2 schrieb:
Wie jetzt ? Doch Pointerarithmetik in Java ?
unsigned int i = 0x010204; unsigned char* p = (unsigned char*) &i; *p |= 0x10; *(p+1) |= 0x20;Show me ...
nein, so doch nicht
die pointer sind versteckt in Java.Und das ist das Problem
Die Pointer sind zwar da (und man muß sich immer wieder vor Augen führen, daß man in Wirklichkeit "nur" Zeiger in der Hand hält)...nein, warum sollte man im entfernstesten an zeiger denken, wenn man mit Java programmiert?
Simon2 schrieb:
pale dog schrieb:
...
Simon2 schrieb:
Wie jetzt ? Doch Pointerarithmetik in Java ?
unsigned int i = 0x010204; unsigned char* p = (unsigned char*) &i; *p |= 0x10; *(p+1) |= 0x20;Show me ...
nein, so doch nicht
die pointer sind versteckt in Java.Ergo: Dem Programmierer steht diese Technik nicht zur Verfügung => Java hat diese Technik "verworfen".
aber warum sollte man diese technik nutzen sollen, ausser man will solche haarsträubenden codes basteln wie in deinem beispiel da oben?
man macht einfach:int i = 0x010204; i |= 0x102000und gut is'
-
pale dog schrieb:
aber warum sollte man diese technik nutzen sollen, ausser man will solche haarsträubenden codes basteln wie in deinem beispiel da oben?
Weil sich über die Jahre gezeigt hat, dass das Zeiger-Konzept eine sehr simple und mächtige Abstraktion ist, um mit der Maschine zu kommunizieren. Sicher, wenn man nicht hardwarenahe programmieren will, braucht man die Spezialisierung "Zeiger" nicht unbedingt. Das Über-Konzept "Iterator" wäre aber trotzdem praktisch.
-
pale dog schrieb:
CStoll schrieb:
pale dog schrieb:
CStoll schrieb:
Aber durch diese Festlegungen versperrst du dir den Weg für zukünftige Entwicklungen. C++ Compiler mit 128-Bit int's sind kein Problem, Java Compiler werden auch in Hundert Jahren noch mit 32-Bit hantieren.
=> der Punkt geht ebenfalls an C++.jein
in 100 jahren wird der heutige, 32-bittige Java datentyp (int) zwar gleich bleiben, aber dafür können zusätzliche, breitere datentypen eingeführt werden, wenn bedarf bestehen sollte (deren repräsentation sich übrigens auch niemals ändern wird).
sorry, den punkt müssen wir C++ leider wieder abziehen.Aber um diese breiteren Datentypen nutzen zu können, müsstest du alle deine Programme von Hand anpassen - da wünsche ich dir viel Spaß bei dem Versuch, in einem größeren Projekt alle Vorkommen von 'int' zu finden und zu entscheiden, welcher größere Datentyp für diese Werte nun ausreichend ist. Meine C++ Projekte muß ich nur neu compilieren, um die neue Architektur nutzen zu können.
warum sollte ich in einem bereits funktionierenden programm alle 'ints' ändern wollen
das wäre doch blödsinn.Vielleicht weil sich mit dem neuen System die Anforderungen an das Programm geändert haben und die 32 Bit von int plötzlich doch nicht mehr ausreichen
nein, warum sollte man im entfernstesten an zeiger denken, wenn man mit Java programmiert?
Klar kannst du gerne vergessen, daß du mit Pointern arbeitest. Aber deswegen sind sie trotzdem da (mit fast allen damit verbundenen Problemen, aber ohne echte Vorteile gegenüber C++ Zeigern).
aber warum sollte man diese technik nutzen sollen, ausser man will solche haarsträubenden codes basteln wie in deinem beispiel da oben?
man macht einfach:int i = 0x010204; i |= 0x102000und gut is'
Weil man's kann
(*scnr*) (und ob dein Code wirklich die selbe Wirkung hat wie Simon's, ist auch offen)