Ich hasse Java

[Krishty]

… und damit ich in Zukunft jedem Fanboy einen Link auf die Krawatte kotzen kann statt stundenlang alte ICQ-Rants und verstreute Forenbeiträge rauszusuchen, sammle ich meinen Hass hier

Beachtet mich einfach nicht

[Alexander Kornrumpf]

Komm schon du kannst doch mehr als ein paar polemische Bildchen!

[Krishty]

Vor allem kann ich mehr als fünf pro Beitrag :(

[CodingCat]

Endlich! Ein eigener Jammerthread für Java, das hat ja lange gedauert! Da mich mein geliebtes Studium in diesem Semester besonders nachdrücklich zu Java zwingt, kann ich nicht nur jedem Punkt beipflichten, sondern sehe mich sogar in der glücklichen Lage, eigenen Hass beizusteuern:

Die NIO-Memory-Mapping-API ist die größte Katastrophe, die man sich vorstellen kann. Zwar funktioniert das Memory-Mapping an sich, dafür verlässt sich die API jedoch an Stelle einer deterministischen Unmap-Methode ganz einfach vollends auf den Garbage-Collector, heißt so viel wie: Unmap findet nur dann vielleicht statt, wenn keine Referenz mehr auf das entsprechende ByteBuffer-Objekt vorhanden ist. Selbst dann hat sich der GC jedoch zuverlässig als zu langsam herausgestellt, der Adressraum scheint im Programmverlauf einfach willkürlich überzulaufen. Noch schöner wird es, wenn dasselbe Dateifenster mehrmals hintereinander gemappt wird, noch bevor der GC sich verwaister Mappings angenomment hat. In diesem Fall fliegt einem auch mal irgendwann einfach so das gesamte Programm um die Ohren, weil der GC sich urplötzlich entschließt, mal eben eins der beiden parallel existierenden Mappings aufzuheben, diese sich jedoch leider gegenseitig durch irgendwelche Sperrungen das Unmapping ohne Programmabsturz mit VM-Errors unmöglich machen.

Abhilfe schafft nur das Einstreuen von GC-Calls nach jeder vermuteten Verwaisung von MappedByteBuffer-Referenzen. Um ein einziges Mapping aufzuheben!

[Chromanoid]

Ich programmiere trotzdem gerne mit Java :P.
Ich finde C++ nerviger als Java daher entwickle ich lieber mit Java :D. Und würdet ihr mit Java programmieren, wäre der Jammer-Thread sicherlich nicht so voll :D. Dank GWT programmiere ich jetzt sogar JavaScript RIAs mit Java - HTML5 ich komme :mrgreen:.
@CodingCat: NIO ist tatsächlich nicht das Gelbe vom Ei. Ich hoffe NIO2 macht es besser.

[Krishty]

Extra für Cat:

Und würdet ihr mit Java programmieren, wäre der Jammer-Thread sicherlich nicht so voll :D

Dafür wäre ich längst mit einem halbautomatischen Gewehr in den Abendnachrichten gelandet :)

[Chromanoid]

:D

[eXile]

Da war man eine halbe Woche nicht da und dann dieser ... quatsch, dieser Thread ist einfach nur YEEEEEAAAAAAAAAAHHHHH!

Mal meine persönliche Liste (bitte korrigiert mich, ich habe von Java wohl am wengisten Ahnung überhaupt!):

• Templates: Muss ich ja wohl nichts mehr zu sagen.
• Operatorüberladung: SRSLY JAVA? Dann kommt so etwas bei raus: x.add(y.divide(y.pow(5).abs(), BigInteger.valueOf(4))). SRSLY.
• Funktionszeiger: Benutze ich fricking oft. Am häufigsten sogar Arrays von Funktionszeigern. Nämlich immer dann, wenn ich Klassen hätte, die nur aus einer einzigen Funktion und keinen Daten besteht. Thanks for the class bloat, Java! (Gilt übrigens auch für die ganzen Exception-Klassen.)
• Pro String: 24 Bytes Overhead.
• Synchronization: Ich habe erst letzte Woche ein Paper über Code-Optimierung gelesen. Tl;dr: Lokale Optimierung kann man unter Java vergessen, stattdessen müssen Locks wegoptimiert werden. Im SpecJVM DB Benchmark gab es 53.000.000 Synchronisationspunkte, davon 99,9% wegen Vector.
• Kein quicksort: Und damit meine ich nicht quicksort in einem strengen Sinne nach dem Wikipedia-Artikel, sondern einfach eine Sortierungsfunktion, welche bei wenigen Elementen nun einmal etwas schnelleres als Mergesort benutzt.
• Wie schon gesagt: Kein IEEE 754, dafür aber Exceptions schmeißen ist retarded.

Zu guter letzt nun noch etwas, was nicht direkt mit der Java-Programmiersprache zusammenhängt, sondern eher mit der JVM-Implementation:

Bug 319514 in the Eclipse bug database has all the gory details, but in a nutshell, Oracle changed the company name property on java.exe from “Sun Microsystems, Inc” to “Oracle”. The change was not announced or documented in the release notes. Ironically, Eclipse has been using this value since 2007 to work around another Java problem where Sun’s default for the “MaxPermSize” option was too small for Eclipse to run. When it changed, the workaround no longer worked, and many people encountered “PermGen” errors when they started Eclipse.

But wait, there's more! In der Eclipse-Bug-Datenbank steht der Bug drin als RESOLVED NOT_ECLIPSE! Write once, debug everywhere.

[The_Real_Black]

kennt jemand JavaFX? bind?
"
var a = 5;
var b = bind a * 2

Label {
text: bind b.toString( )
}

"
WTF! Da bekommt man den Hass...

[Chromanoid]

mmh so rein optisch finde ich das eigentlich gar nicht so schlecht. ich finde das sieht besser aus als das Gekrebse bei wpf/xaml:

Code: Alles auswählen

<Slider x:Name="WidthSetterSlider" IsEnabled="{Binding IsChecked, ElementName=EnableHorizontalResize}" Maximum="400" Value="{Binding Text, ElementName=WidthSetterBox, Mode=TwoWay}" />

oder im code:
//make a new source
MyData myDataObject = new MyData(DateTime.Now);
Binding myBinding = new Binding("MyDataProperty");
myBinding.Source = myDataObject;
BindingOperations.SetBinding(myText, TextBlock.TextProperty, myBinding);

[Schrompf]

Ich fühl mich gut unterhalten. Aber ich hätte auch kein Problem damit, einen ähnlichen Thread über C++ zu lesen.

[Despotist]

Vielleicht passt das hier auch rein.

[CodingCat]

Ich verzweifle hier gerade an meinen Hash-Table-Klassen zur effizienten Speicherung von assoziativen Long- und Int-Daten. Da der ganze Sinn dieser Klassen ist, Arrays von primitiven Datentypen zu nutzen, um dem sonst unausweichlichen Overhead eines Vielfachen der tatsächlichen Datenmenge durch unnötige Referenzen aus dem Weg zu gehen, sind Generics keine Option. Macht vier synchron aktuell zu haltende nahezu identische Hash-Table-Klassen mit jeweils vier Unit-Test-Klassen ... nicht 2, nicht 3, nicht 4, ... 8 Klassen für eine Hash-Tabelle! :evil: :evil: :evil:

[CodingCat]

Sehr schön, wenn ich mit JUnit in Eclipse Testfälle ausführe, dann habe ich sogar richtige Resource Leaks, die anhalten, bis ich die IDE beende. Ich glaube das hier wird für die nächsten 5 Wochen Implementierungszeit mein Stammthread. :mrgreen:

[dowhilefor]

Erschreckend das vom Text her die Bilder oben auch auf C# passen :).

Ich bin auch großer Java Verächter, sogar soo sehr, das ich nichtmal Kaffe trinke ;)
Aber dagegen ein sehr großer C# Freund, passt das oder nennt man das schon Fanboy? ;)

[Krishty]

… ich bin (leider) nie dazu gekommen, auch nur eine Zeile darin zu schreiben, geschweige denn, mir über Monate eine Meinung zu bilden. Als Mensch habe ich da auch keine Zeit zu, und als Entwickler keinen Drang.

Microsoft sagt, C# ein besseres Java; Goslin sagt, es sei ein schlechteres Java. Wenn sie sich schon in dem einen Punkt einig sind, glaube ich auch, dass es eine Art Java ist. Wie J# und J++ zuvor.

Und diesen Absatz kriege ich irgendwie unmöglich formuliert, ohne jemanden zu beleidigen. Darum reduziere ich es auf: Der Gedanke, wie viel Geld, Zeit und Bugs man gespart hätte, wenn man einfach Visual Basic generalüberholt hätte statt alle zwei Jahre eine managed Sprache auf den Markt zu werfen, die gegenüber Java und den n Plagiaten alles anders, aber nichts besser macht, sagt für mich enorm viel über den Stand der kommerziellen Software-Entwicklung an sich aus.

[Chromanoid]

Also ich persönlich finde C# besser (als Java) wenn es um Sprachkonstrukte geht und schlechter wenn es um Paket/Klassenverarbeitung geht. Alles einfach dll zu nennen finde ich nervig und ich vermisse die Paketstruktur von Java - ich mag diesen Assembly-Kram überhaupt nicht...
Wenn du in deine Engine mal eine Art Scriptsprache oder so einbaust, könntest du es ja mal mit C# versuchen :).

[BeRsErKeR]

Erschreckend das vom Text her die Bilder oben auch auf C# passen :).

Ich bin auch großer Java Verächter, sogar soo sehr, das ich nichtmal Kaffe trinke ;)
Aber dagegen ein sehr großer C# Freund, passt das oder nennt man das schon Fanboy? ;)

Ich persönlich mag beides nicht und finde es auch recht ähnlich. Aber ich will, wegen des Threadtitels, mal bei Java bleiben.

Ich finde diese "Alles muss in eine Klasse"-Philosophie sowas von daneben. Es ist nicht nur völlig sinnfrei, sondern teilweise auch kein guter Weg. Wenn ich einmalig genutzte Codefragmente oder Funktionen wie eine einmalige globale Initialisierung, mathematische Funktionen oder die main-Funktion habe, wozu dann Klassen? Und dann noch Garbage Collection. Da kommt einem echt das gruseln. Wenn ich sowas brauche, dann mach ich was falsch. Es würde ja nicht mal stören, wenn man durch so ein aufgezwungenes Feature nicht einen Haufen an Performance einbußen würde. Sowas gehört mMn einfach nicht in eine Programmiersprache.

Man versucht heutzutage immer mehr dem Programmierer unter die Arme zu greifen. Halt z.B. mit Dingen wie GC. Aber sowas will man nicht unbedingt und teilweise hat man einfach keine Wahl. Das ist leider auch ein Grund, weshalb ich die neue C++ Version eher unfreudig begutachte. Ich möchte selbst entscheiden wie ich programmiere und passe selbst auf was ich tue. Wenn mir alles abgenommen wird oder untransparent wird, dann lerne ich auch weniger finde ich. Jemand, der nur Java programmiert wird vielleicht nicht verstehen was Pointer sind oder wie sie funktionieren und somit erst gar nicht mit bestimmten Problemstellungen konfrontiert werden. Aber ist das gut? Ist es nicht viel lernreicher, mit Problemen konfrontiert zu werden und Lösungen dafür zu finden?

Ein Vergleich: Am Anfang sind Programmierer wie kleine Kinder, die keine Ahnung von der Welt haben (bezogen auf die Programmierung). Java-Programmierer sind wohl behütet von ihren Eltern (z.B. dem Garbage Collector) und müssen sich nicht um Memory-Management kümmern (sie haben keine Ahnung davon). Der C-Programmierer kommt nach kurzer Zeit nicht mehr ohne Pointer und Memory-Management aus. Er macht seine eigenen Erfahrungen, scheitert ab und an, aber kommt letztlich zu einem hohen Wissensstand darüber und beherrscht die Thematiken größtenteils. Mir gefallen die C-Kinder irgendwie besser. :)

[Krishty]

Man versucht heutzutage immer mehr dem Programmierer unter die Arme zu greifen. Halt z.B. mit Dingen wie GC. Aber sowas will man nicht unbedingt und teilweise hat man einfach keine Wahl. Das ist leider auch ein Grund, weshalb ich die neue C++ Version eher unfreudig begutachte.

Wo wird einem dort die Wahl genommen?

[rüp]

Ein Vergleich: Am Anfang sind Programmierer wie kleine Kinder, die keine Ahnung von der Welt haben (bezogen auf die Programmierung). Java-Programmierer sind wohl behütet von ihren Eltern (z.B. dem Garbage Collector) und müssen sich nicht um Memory-Management kümmern (sie haben keine Ahnung davon). Der C-Programmierer kommt nach kurzer Zeit nicht mehr ohne Pointer und Memory-Management aus. Er macht seine eigenen Erfahrungen, scheitert ab und an, aber kommt letztlich zu einem hohen Wissensstand darüber und beherrscht die Thematiken größtenteils. Mir gefallen die C-Kinder irgendwie besser. :)

Man kann aber auch so argumentieren, dass der C-Programmierer bis ins hohe Alter Fehler beim Speichermanagement machen wird, während der Java-Programmierer am Ende einfach mal 8 Millionen Dollar verdient hat. ;)

[The_Real_Black]

Man kann aber auch so argumentieren, dass der C-Programmierer bis ins hohe Alter Fehler beim Speichermanagement machen wird, während der Java-Programmierer am Ende einfach mal 8 Millionen Dollar verdient hat. ;)

Oder der C# Entwickler... ;-)

Ein anderes Argument ist das C++ Entwickler viel aufwand treiben bzw getrieben haben um genau auf solche Systeme zukommen wie sie in C# bzw Java bereits implementiert sind. Eine Speicherverwaltung selbst zuschreiben ist ein riesen Aufwand welches am Ende keinen Profit abwirft und nur viele Arbeitsstunden kostet. Oben wurde auch das Klassen Konzept bemängelt, aber Klassen bieten eine natürlichere Art Programme zu entwerfen da man auch in der Realität solche Einteilungen treffen kann. (Mein Beispiel ist immer "Tier": Tier ist ein Lebewesen, ein Eichhörnchen ist ein Tier, eine Ente ist ein Tier... und wenn man von Ente, Eichhörnchen, Hase und Hirsch gleichzeitig ableitet bekommt man einen Wolpertinger!?? Für welche die nicht wissen wovon ich rede: http://de.wikipedia.org/wiki/Wolpertinger ) Objektorientiertheit hat sich entwickelt da man versucht hat möglicht seine Daten gewönht zu verwalten also ist dieser Trend zu begrüßen.

PS kennt einer Singularity?
http://de.wikipedia.org/wiki/Singularity
Da sieht man was die Zukunft bringen wird...

[Schrompf]

Ein anderes Argument ist das C++ Entwickler viel aufwand treiben bzw getrieben haben um genau auf solche Systeme zukommen wie sie in C# bzw Java bereits implementiert sind.

Nein. Das ist nur ein klassisches Klischee. In Wirklichkeit betreibt man oft, aber wenig Aufwand, um praktische Lösungen für vielfältige spezifische Lebenszeitprobleme von Resourcen zu finden. Wenn Du viel Aufwand betreibst, nur um am Ende eine AllesErledigt-Lösung zu bekommen, die es eh schon gibt (z.B. der GC in Java), dann hast Du nur Deinen Job ineffizient gemacht.

[BeRsErKeR]

Man versucht heutzutage immer mehr dem Programmierer unter die Arme zu greifen. Halt z.B. mit Dingen wie GC. Aber sowas will man nicht unbedingt und teilweise hat man einfach keine Wahl. Das ist leider auch ein Grund, weshalb ich die neue C++ Version eher unfreudig begutachte.

Wo wird einem dort die Wahl genommen?

Hmm das hab ich falsch formuliert. Die neue C++ Version stört mich eher in der Hinsicht, dass sie sich Sprachen wie C# oder Java annähert. Und selbst ein GC war ja mal angedacht. Außerdem stören mich schlecht nachvollziehbare Konstrukte wie "auto", lambda expressions oder user-defined literals/suffixes.

Ein Vergleich: Am Anfang sind Programmierer wie kleine Kinder, die keine Ahnung von der Welt haben (bezogen auf die Programmierung). Java-Programmierer sind wohl behütet von ihren Eltern (z.B. dem Garbage Collector) und müssen sich nicht um Memory-Management kümmern (sie haben keine Ahnung davon). Der C-Programmierer kommt nach kurzer Zeit nicht mehr ohne Pointer und Memory-Management aus. Er macht seine eigenen Erfahrungen, scheitert ab und an, aber kommt letztlich zu einem hohen Wissensstand darüber und beherrscht die Thematiken größtenteils. Mir gefallen die C-Kinder irgendwie besser. :)

Man kann aber auch so argumentieren, dass der C-Programmierer bis ins hohe Alter Fehler beim Speichermanagement machen wird, während der Java-Programmierer am Ende einfach mal 8 Millionen Dollar verdient hat. ;)

Kann man. Es ist ja auch nur meine ganz persönliche Wertung. Ich bin halt jemand, der gern etwas lernt und versteht und nicht einfach viel Geld verdienen will obwohl ich nur die Hälfte verstehe. Für mich ist das ähnlich wie GameMaker und Programmiersprache. Wenn ich ein Spiel machen will kann ich mit einem GameMaker schneller zum Ziel kommen, aber wie man ein Spiel programmiert sehe ich dann meist nicht.

[unique75]

Frage: Was ist schlimmer als ein abgebissener Apfel mit einer Made drin?
Antwort: Ein abgebissener Apfel mit einer halben Made drin.

Ich überlasse es jedem selbst zu entscheiden, was davon Java oder C# ist.

Ich halte es aber für verkehrt daraus einen allgemeingültigen Rückschluß für alle Äpfel zu machen. Genauso ist es mit dem GC. Ein guter GC verbraucht zu Spitzenzeiten nicht mehr als 10% und das auch nur wenn man eine für die Applikation ungeeignete Memorypolicy eingestellt hat. Hat man einen GC so baut man auch viel komplexere und aus OOP-Sicht sinnvollere Objektbeziehungen, weil es nicht mehr interessiert WER/WANN/Wo es freigegeben wird.

Hier noch ein paar andere Anmerkungen:

- wir arbeiten filebasiert, weil das VisualStudio/Eclipse und überhaupt die ganze Welt so macht, also muss das richtig sein
- wir schreiben 100 Methoden in ein File, weil das so ungemein die Wartbarkeit und Lesbarkeit erhöht
- wir lieben Files, denn wir haben einen netten Compiler, der uns auf zyklische Referenzen aufmerksam macht
- wir lieben den Compiler, denn die Menge "aufmerksam machen" verknüpft mit der Menge "hilfreich" ergibt in unserer Welt die leere Menge
- wir brauchen keinen GC, es ist viel performanter es selbst zu tun, so lasten wir unsere CPU nur 4% aus, anstatt 5%
- wir brauchen keinen GC, wir sind unfehlbar und überblicken alle 100000 Objektbeziehungen und -querverweise
- da wir so unfehlbar sind gibt es auch so selten Programme mit Pufferüberläufen, Abstürzen und Memoryleaks
- wir sind sogar so unfehlbar, dass wir ganze Klassenhierarchien final/private machen
- wir brauchen Typen, und weil die so geil sind, schreiben wir die gleich 3x hin, Microsoft sagt, das muss so sein
- wir brauchen native Datentypen, denn das bringt Performance... für den Rest haben wir ja Boxed
- wir brauchen native Datentypen, denn wir wollen mit Bytegrenzen rechnen, anstatt mit mathematisch unbegrenzten Zahlenräumen
- wir alignen auf 2 Bytes, Speicherlayout ist eben geil, in der realen Welt nehm ich ja auch ne Schraube die exakt 20 Holzspanbreiten braucht
- und das wichtigste... wir brauchen eine performante Sprache... denn ich möchte gleich ein paar printfs machen

Ich hoffe ich konnte helfen :D

[Krishty]

Ein anderes Argument ist das C++ Entwickler viel aufwand treiben bzw getrieben haben um genau auf solche Systeme zukommen wie sie in C# bzw Java bereits implementiert sind. Eine Speicherverwaltung selbst zuschreiben ist ein riesen Aufwand welches am Ende keinen Profit abwirft und nur viele Arbeitsstunden kostet.

Das Argument geht jedes Mal komplett am Problem vorbei – C++ hat eine Speicherverwaltung, die genau so automatisch ist wie Javas – und eben zusätzlich noch deterministisch. Selber schreiben muss man garnichts.
Der enorme Vorteil ist, dass bei C++ Ressourcen automatisch verwaltet werden, während in Java nur Speicher verwaltet wird (und es dafür noch nicht einmal Garantien gibt, da auch ein GC, der nie etwas tut, ein gültiger GC ist). Solche Fehler wie CodingCats Dateien, deren Speicherabbilder sich gegenseitig abschießen weil es keine deterministische Freigabemethode gibt, sind in Java sehr hässlich bis unmöglich zu lösen; in C++ ist die Lösung jedoch bereits Teil des Sprachkonzepts, da es im Gegensatz zu Java und C# garantierte Finalisierung bietet (nicht nur manuelle Finalisierung durch finally). Und es gibt in „echten“ Anwendungen jede Menge nicht-Speicher-Ressourcen …

Oben wurde auch das Klassen Konzept bemängelt, aber Klassen bieten eine natürlichere Art Programme zu entwerfen da man auch in der Realität solche Einteilungen treffen kann.

Unsinn. OOP hilft, aber es zu erzwingen ist ein katastrophaler Fehler. In welche Klasse gehört min()?

PS kennt einer Singularity?
http://de.wikipedia.org/wiki/Singularity
Da sieht man was die Zukunft bringen wird...

Das Ziel von Singularity war afaik primär, C# an die Grenzen zu bringen und, sekundär, die Verbesserung von statischer Analyse sowie die Vorbereitung darauf, den NT-Kernel in Richtung eines Mikrokernels zu entwickeln. Singularity selber (oder ähnliche Projekte) wird der Kunde auch die nächsten 20 Jahre nicht sehen.

Man versucht heutzutage immer mehr dem Programmierer unter die Arme zu greifen. Halt z.B. mit Dingen wie GC. Aber sowas will man nicht unbedingt und teilweise hat man einfach keine Wahl. Das ist leider auch ein Grund, weshalb ich die neue C++ Version eher unfreudig begutachte.

Wo wird einem dort die Wahl genommen?

Hmm das hab ich falsch formuliert. Die neue C++ Version stört mich eher in der Hinsicht, dass sie sich Sprachen wie C# oder Java annähert. Und selbst ein GC war ja mal angedacht. Außerdem stören mich schlecht nachvollziehbare Konstrukte wie "auto", lambda expressions oder user-defined literals/suffixes.

Ja, das meiste davon finde ich auch hässlich. Jedoch hat es seine Existenzberechtigung und wenn man nicht will, kann man der Syntax fernbleiben – man wird sicher nie „versehentlich“ ein Lambda deklarieren, wenn man was anderes meinte.

[unique75]

min() gehört in die Klasse Number und von der sollten Dinge wie Int, Float, Fraction etc abgeleitet sein. Da C++ aber native Datentypen hat wars das mit dem schönen OOP. Sobald man:

int x;

hinschreibt, sollte der Compiler automatisch eine Instanz der Klasse Int anlegen, nichts anderes. Das was C++/Java/C# usw. tun ist einfach nur miserabel.

[Krishty]

min() gehört in die Klasse Number und von der sollten Dinge wie Int, Float, Fraction etc abgeleitet sein.

min() ist nicht vom internen Aufbau einer Zahl abhängig, also nein.

[unique75]

Was meinst du denn mit "internen" Aufbau einer Zahl?

[Krishty]

Ich weiß nicht, wie Methoden in Smalltalk realisiert sind, also sag, wenn ich falsch liege – aber in C++/C#/Java haben Klassenmethoden vollen Zugriff auf private Attribute und Methoden der Klasse. Und das würde im Fall von min() die Kapselung verletzen, weil die Beziehung „kleiner als“ öffentlich abrufbar und unabhängig von der konkreten Implementierung einer Zahl ist. Zudem gehört min() in kein Objekt, weil die beiden Zahlen bei dieser Operation gleichberechtigt sind.

[unique75]

Ich glaube du hängst viel zu sehr in der C++ Welt mit seinen nativen Datentypen. Mit den Klassenmethoden und Zugriffsrechten hast du Recht, das ist auch in Smalltalk und sicherlich jeder anderen Programmiersprache so. Stell dir vor du hast eine Klasse String, und diese hat eine Instanz-Methode add(char*). Dann schreibst du doch sicherlich auch sowas wie:

String str;
str.add("Hallo");

Es ist doch mehr als naheliegend dieselbe Annahme auch für eine Zahl zu treffen. Ich schreibe eine Klasse Integer mit der Instanzmethode min(int).

Integer i;
i.min(5)

Wenn jetzt der Compiler noch so intelligent wäre und die Klasse Integer vordefiniert hätte und alle kleingeschriebenen "int" als "Integer" deuten würde und sofort als Instanz der Klasse Integer intern anlegen würde, dann hättest du genau das was ich geschrieben habe. Aber der C++ Compiler ist halt dämlich und alle Welt will immer die nativen Datentypen.