hilfe : von c++ zu java

[netrobot]

gibt es welche online-bücher (ebook), die die unterschiede zwischen beiden sprachen beschreiben?

[elise]

wenn du googlest, kommt einiges..

http://www.google.de/search?client=firefox-a&rls=org.mozilla%3Ade-DE%3Aofficial_s&hl=de&q=unterschied+java+c%2B%2B&meta=&btnG=Google-Suche

ich würde versuchen, java ganz neu zu denken, und nicht zu arg auf c++ vergleichen zu harren.

[phlox81]

Also ich hab ja jetzt mein erstes Großes Java Projekt am laufen,
die Erfahrungen die ich gemacht habe:
- Vermeide lokale Variablen in Java, da ja nur der GC diese wieder Zerstören kann
- Vermeide tiefer gehende Rekursion, da das Speicher kosten kann
- Gewöhn dich daran, das es in Java keinen implizierten Standard Konstruktor gibt,
alles muss mit new erstellt werden. Sonsts ist es null, und zur Laufzeit fliegt ne Exeption
- In Java 1.4.2 gibts noch keine Templates, daher darf man bei Containern viel
casten, man gewöhnt sich aber dran
- In Java gibts keine Mehrfachvererbung, welche ja in C++ manchmal ganz nützlich ist.

phlox

[grenouille_unreg]

phlox81 schrieb:

- Vermeide lokale Variablen in Java, da ja nur der GC diese wieder Zerstören kann

Wenigstens werden diese bei Speicherknappheit wieder freigegeben.

phlox81 schrieb:

Vermeide tiefer gehende Rekursion, da das Speicher kosten kann

In welcher Sprache wohl nicht!!!

phlox81 schrieb:

Gewöhn dich daran, das es in Java keinen implizierten Standard Konstruktor gibt,

Ist mir neu!!!

class Foo
{
  int i;
}

Überleg mal.

phlox81 schrieb:

alles muss mit new erstellt werden. Sonsts ist es null, und zur Laufzeit fliegt ne Exeption

Falsch! Es gibt Prototype-, Factory-Pattern, Reflections, etc.
Ausserdem werde primitive Typen (int, double...) ohne new deklariert.

phlox81 schrieb:

In Java 1.4.2 gibts noch keine Templates, daher darf man bei Containern viel
casten, man gewöhnt sich aber dran

Noch so ein armer User der das Glocken leuten verpasst hat.

phlox81 schrieb:

- In Java gibts keine Mehrfachvererbung, welche ja in C++ manchmal ganz nützlich ist.

Zu recht auch, ABER .... (Pfui Teufel geh weg von mir )

[Gast]

phlox81 schrieb:

- Vermeide lokale Variablen in Java, da ja nur der GC diese wieder Zerstören kann

Uneindeutig und unwichtig. Lokale Variablen sind entweder vom Typ int, short, char, byte, long, float, double oder < Referenz > und die die Referenz wird dann zerstört wenn der Stack Frame abgebaut wird. Was du natürlich meinst, sind die Objekte auf dem Heap. Du denkst aber fälschlicherweise, dass der GC große Schwierigkeiten damit hätte, viele kurzlebige Objekte zu zerstören. Wenn man weiß, wie der GC arbeitet, weiß man auch, dass die Arbeit des GC dafür gegen null geht. Schlimm sind Objekte, die mittel-lang leben.

- Vermeide tiefer gehende Rekursion, da das Speicher kosten kann

In welcher Sprache ist das nicht so? Ist das in Java mehr als in üblichen Sprachen? Dadurch, dass der größte Datentyp auf dem Stack 8 Bytes hat, stelle ich mir das nicht dramatisch vor. In anderen Sprachen, kann ich schon mal ne Matrix mit 16*4 Bytes auf den Stack flacken, oder zwei und multipliziere sie und brauch dann den Platz für drei.

- Gewöhn dich daran, das es in Java keinen implizierten Standard Konstruktor gibt,
alles muss mit new erstellt werden. Sonsts ist es null, und zur Laufzeit fliegt ne Exeption

Ja, verdrehe nur die Augen. Du hast anscheinend nicht mal kapiert, was eine Referenz ist.

- In Java 1.4.2 gibts noch keine Templates, daher darf man bei Containern viel
casten, man gewöhnt sich aber dran

Man gewöhnt sich nicht daran, sondern baut einen typsicheren Wrapper. Im übrigen gibt es auch in Java 1.5 nichts, was mit Templates vergleichbar ist.

- In Java gibts keine Mehrfachvererbung, welche ja in C++ manchmal ganz nützlich ist.

Das ist sogar mal richtig. Gratulation.

Alles in allem hast du ziemlichen Stuss erzählt.

[Artchi]

Der eine ist unregistriert und feuert zurück, der andere ist Java-Fan und fühlt sich deshalb angegriffen und meint phlox81 labert stuss. Klar, es war nicht alles richtig, aber das meiste war richtig.

- Rekursionen: max. 256 mal und dann gibts einen Stackoverflow, das ist die Realität. Sowohl auf einer Client-VM als auch auf einer IBM-WebSphere-Server-VM fliegt mir das Ding um die Ohren. In XML darf ich nicht mal verkettete Listen abbilden, weil bei >256 Listen-Elementen fliegt eine Stackoverflow-Exception. Eine Rekursionstiefe von 256 ist nicht gerade der Hit. Jetzt kann man darüber streiten, ob man Rekursionen in Java vermeiden soll, weil der eine wohl nie diese Rekursionstiefe braucht. Oder kann mir jemand sagen, wie man diese Rekursionstiefe mit einem VM-Param erhöhen kann?

- Referenz = null: Mag sein das er nicht weiß was eine Referenz ist. Ändert nichts daran das die verdammten Referenzen null sein können und der Programmfluss dadurch aus der Bahn fliegt, weil mal wieder an einer Stelle nicht auf null abgefragt wurde. Ich liebe es, wenn mir Kollegen was von wegen "In C++ muß man ja andauernd aufpassen das einem die Pointer nicht um die Ohren fliegen. Kann mir in Java nicht passieren!" erzählen. Dann schreib ich mal einen zweizeiler in Java, und präsentieren ihnen einen schöne NullPointerException. Da ist das Staunen groß.

Und ja, Pointer und Java-Refs sind unterschiedlich, ich weiß. Ändert aber nichts am GAU in einer Software.

- Wrapper für Java-Container: toll, damit wird die Entwicklungs-Geschwindigkeit in Java erhöht.

[Gast]

Artchi schrieb:

der andere ist Java-Fan und fühlt sich deshalb angegriffen und meint phlox81 labert stuss.

Nein, er labert Stuss. Ich fühle mich nicht angegriffen.

- Rekursionen: max. 256 mal und dann gibts einen Stackoverflow, das ist die Realität. Sowohl auf einer Client-VM als auch auf einer IBM-WebSphere-Server-VM fliegt mir das Ding um die Ohren. In XML darf ich nicht mal verkettete Listen abbilden, weil bei >256 Listen-Elementen fliegt eine Stackoverflow-Exception. Eine Rekursionstiefe von 256 ist nicht gerade der Hit. Jetzt kann man darüber streiten, ob man Rekursionen in Java vermeiden soll, weil der eine wohl nie diese Rekursionstiefe braucht. Oder kann mir jemand sagen, wie man diese Rekursionstiefe mit einem VM-Param erhöhen kann?

-oss unter Windows NT. 30sec googlen, wahrscheinlich gibt es elegantere Lösungen.

- Referenz = null: Mag sein das er nicht weiß was eine Referenz ist. Ändert nichts daran das die verdammten Referenzen null sein können und der Programmfluss dadurch aus der Bahn fliegt, weil mal wieder an einer Stelle nicht auf null abgefragt wurde. Ich liebe es, wenn mir Kollegen was von wegen "In C++ muß man ja andauernd aufpassen das einem die Pointer nicht um die Ohren fliegen. Kann mir in Java nicht passieren!" erzählen. Dann schreib ich mal einen zweizeiler in Java, und präsentieren ihnen einen schöne NullPointerException. Da ist das Staunen groß.

LOL, also wer über eine Nullreferenz erstaunt ist, ist wahrscheinlich eher leicht zu beeindrucken. Außerdem ist hier was total komplett durcheinandergekommen. phlox81 hat daraus, dass es null-Referenzen gibt, geschlossen, dass es wohl keinen impliziten Standardkonstruktor gibt. Häh? Selbst er nicht weiß, was eine Referenz ist, hätte er selber einen Standardkonstruktor schreiben und feststellen können, dass er mit dem selben Code immer noch eine Exception kriegt.

Und ja, Pointer und Java-Refs sind unterschiedlich, ich weiß. Ändert aber nichts am GAU in einer Software.

Wenn C++ jedesmal abstürzen würde, wenn man einen ungültigen Zeiger dereferenziert, gäbe es ein paar GAUs weniger. Ich will jetzt hier keinen großen Vergleich anstellen (und schon gar keinen Flamewar starten), aber eine Exception ist kein GAU, so weit einsichtig musst du sein.

Wrapper für Java-Container: toll, damit wird die Entwicklungs-Geschwindigkeit in Java erhöht.

Nein, das ist scheiße, aber besser als 80mal zu casten. Ich habe ja nie gesagt, dass das toll ist.

Und was war jetzt kein Stuss? Dass es keine Mehrfachvererbung gibt, wie gesagt.

[Gregor@Home]

Artchi schrieb:

- Rekursionen: max. 256 mal und dann gibts einen Stackoverflow, das ist die Realität. Sowohl auf einer Client-VM als auch auf einer IBM-WebSphere-Server-VM fliegt mir das Ding um die Ohren.

Verstehe nicht, was du da meinst.

Testprogramm:

public class RecursionTest
{
   public static void main (String[] args)
   {
      method(1);
   }

   public static void method(int i)
   {
      System.out.println(i);
      method(i+1);
   }
}

Ausgabe:

[...]
84528
84529
84530
84531
84532
84533
84534

...dann fliegt die erwartete Exception.

Kannst du mal sagen, was du mit Rekusionstiefe 256 meinst?

java version "1.6.0-ea"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.6.0-ea-b36)
Java HotSpot(TM) Client VM (build 1.6.0-ea-b36, mixed mode, sharing)

[Gast]

Ich dachte, ab 1.6 kicken sie die Client VM? Wollten die nicht eine einzige VM machen?

[phlox81]

Na dann starten wir mal den FLame *g*

Was ich geschrieben habe, sind die Erfahrungen die ich gemacht
habe, seit dem ich beruflich Java programmiere.
Mag nicht alles 100% stimmen, ich hab nicht viel Erfahrung in Java.
Ich programmier schon Lange in C++, und hab gedacht, ich kann ja mal
kurz so die Erfahrungen die ich gemacht habe hier hin schreiben.

Lustig finde ich nur die Reaktionen, das man dann hier gleich beleidigt wird etc.

Ich weiss was Referenzen sind
Aber warum können diese in Java null sein ?
Hm, bräuchte man sonst Pointer ?

phlox81 hat daraus, dass es null-Referenzen gibt, geschlossen, dass es wohl keinen impliziten Standardkonstruktor gibt. Häh? Selbst er nicht weiß, was eine Referenz ist, hätte er selber einen Standardkonstruktor schreiben und feststellen können, dass er mit dem selben Code immer noch eine Exception kriegt.

Da hast du mich falsch verstanden.
Ich meinte damit, wenn int, float (...) automatisch intialisiert werden,
warum gilt das nicht auch für Objekte ?
Stattdessen werde ich dann zu new gezwungen.
Und sowas geht auch nicht:
String mystring("hallo welt");
Oder doch ? Klär mich auf

phlox

[phlox81]

Gregor@Home schrieb:

Testprogramm:

public class RecursionTest
{
   public static void main (String[] args)
   {
      method(1);
   }

   public static void method(int i)
   {
      System.out.println(i);
      method(i+1);
   }
}

Ergibt bei mir 12475. Auf XP Java 1.4.2

ALLERDINGS, wenn ich nun einen einfachen STring hinzupacke:
String mystring = new String("Tiefe: ");
Und ausgeben lasse:
System.out.println(mystring + i);

sinds nur noch Tiefe: 3620...

phlox

[Gregor@Home]

phlox81 schrieb:

Ich meinte damit, wenn int, float (...) automatisch intialisiert werden,
warum gilt das nicht auch für Objekte ?

null ist ein gültiger Wert, mit dem man arbeiten kann. IMHO ist das auch der klügste Wert, auf den man eine Variable, die auf ein Objekt zeigen könnte initialisieren kann, wenn man nichts besseres weiß. Was im übrigen die automatische Initialisierung betrifft...

Hast du schonmal sowas gemacht?

int i;
System.out.println(i);

Dann wüßtest du, dass das nur sehr eingeschränkt stimmt. Java macht auch hier das einzig sinnvolle, was es tun kann. Und das ist eine Fehlermeldung beim kompilieren ausgeben.

[Gast]

phlox81 schrieb:

Lustig finde ich nur die Reaktionen, das man dann hier gleich beleidigt wird etc.

Ach komm, ich hab dich doch nicht beleidigt oder? Ich hab doch auch schon oft Stuss geschrieben, Gregor ist gleich jemand, den du dazu fragen kannst.

Ich weiss was Referenzen sind
Aber warum können diese in Java null sein ?
Hm, bräuchte man sonst Pointer ?

Pointer sind nach allgemeinem Verständnis Variablen, die Adressen enthalten. Das trifft auf die Referenzen in Java nicht unbedingt zu. Es ist nicht unüblich, Referenzen Pointer auf Pointer auf das Objekt sein zu lassen. Ich habe aber nicht nachgeschaut, wie es bei der Sun VM ist. Es muss auf jeden Fall kein Pointer sein. Außerdem verbindet man mit dem Begriff Pointer Sachen wie Basis-Adresse, Offset, alles Dinge, die dem Java-Programmierer nicht direkt zugänglich sind. Warum soll eine Referenz nicht null sein können? Nur weil es in C++ halt gerade nicht so ist?

Da hast du mich falsch verstanden.

vielleicht.

Ich meinte damit, wenn int, float (...) automatisch intialisiert werden,
warum gilt das nicht auch für Objekte ?
Stattdessen werde ich dann zu new gezwungen.

float und int werden nicht initialisiert, siehe Gregor. Außer natürlich in Klassen, mit 0. Und Referenzen mit null. Unterscheidet sich doch gar nicht. Ich weiß natürlich, dass du meinst, dass kein Objekt erstellt wird, aber bei einem Pointer in C++ würdest du doch das auch nicht erwarten.

Und sowas geht auch nicht:
String mystring("hallo welt");

Es geht String mystring = new String("hallo welt"), denn String hat nen Copy-Konstruktor. Das Literal "hallo welt" ist eine statische Konstante innerhalb der Klasse, die initialisiert wird, sobald die Klasse geladen wird.

String mystring("hallo welt");

Ist in Java gar kein gültiges Statement, da es nicht der Grammatik gehorcht, das wäre die einfachste Erklärung.

[Gregor@Home]

Optimizer schrieb:

Ich hab doch auch schon oft Stuss geschrieben, Gregor ist gleich jemand, den du dazu fragen kannst.

Genau! Damals wie heute. Optimizer redet so oft Stuss. Sicherlich fast genauso oft wie ich. Ob es jetzt um Primzahlen geht oder ob er die Nutzung eines Konstruktors empfiehlt, der so ziemlich der unnützeste Konstruktor ist, den es gibt:

Optimizer schrieb:

Es geht String mystring = new String("hallo welt"), denn String hat nen Copy-Konstruktor.

An allen möglichen Stellen redet Opti Stuss. Es ist ja kaum erträglich. *SCNR*

[Bashar]

Optimizer schrieb:

String mystring("hallo welt");

Ist in Java gar kein gültiges Statement, da es nicht der Grammatik gehorcht, das wäre die einfachste Erklärung.

Und selbst wenn es das wäre und analog C++ funktionieren würde, dann würde es keinen Sinn ergeben, da der Typ String eine Objektreferenz auf einen String bezeichnet, und diese hat keinen Konstruktor, der Strings annimmt. Eine äquivalente Konstruktion in C++ wäre sowas in der Art

string *myString("hallo Welt");

und das ist ja auch Unsinn.

[Irgendwer]

Ich weiss was Referenzen sind
Aber warum können diese in Java null sein ?
Hm, bräuchte man sonst Pointer ?

Pointer sind nach allgemeinem Verständnis Variablen, die Adressen enthalten. Das trifft auf die Referenzen in Java nicht unbedingt zu. Es ist nicht unüblich, Referenzen Pointer auf Pointer auf das Objekt sein zu lassen. Ich habe aber nicht nachgeschaut, wie es bei der Sun VM ist. Es muss auf jeden Fall kein Pointer sein. Außerdem verbindet man mit dem Begriff Pointer Sachen wie Basis-Adresse, Offset, alles Dinge, die dem Java-Programmierer nicht direkt zugänglich sind. Warum soll eine Referenz nicht null sein können? Nur weil es in C++ halt gerade nicht so ist?

Ach komm, du scheinst zu viel Java programmiert zu haben und gar nicht mehr zu wissen wie man mit Pointern in C++ umgeht. Schon allein die Tatsache, dass du den Begriff "Pointer" mit Begriffen wie "Basis-Adresse" oder "Offset" assoziierst zeigt doch schon, dass alle Pointer für dich gleich Pointer auf Arrays sind.

Es gibt aber auch Pointer die auf ganz einfache Objekte zeigen. Diese sind entweder NULL, zeigen auf ein Objekt oder auf ein ehemaliges Objekt. Letztere sind entweder zu Recyceln oder zu Zerstören direkt nach ihrer Entstehung. Das Argument, dass Java Referenzen nicht in die Pampa zeigen können gilt nicht : Wenn man sich nicht um solche Referenzen kümmert wird der GC den Speicher nicht recyceln können.

Also fassen wir mal zusammen : C++ Pointer können NULL sein, auf ein Objekt zeigen und müssen nach ihrem Gebrauch beseitigt werden, Java Referenzen können null sein, auf ein Objekt zeigen und müssen nach ihrem Gebrauch beseitigt werden. Hört sich für mich irgendwie nach dem gleichen an.

Hingegen, ist es garantiert, dass C++ Referencen immer fest mit einem Objekt verbunden sind was bei Java Referencen nicht der Fall ist.

Die Tatsache, dass Pointer in C++ und Java Referenzen wegen der unterschiedlichen Speicherverwaltung anders implementiert sind, ist ein Implementierungsdetail, das den Benutzer der Klassen "C++" und "Java" nichts angeht.

Fals du mir nicht glauben solltest:

The reference values (often just references) are pointers to these objects, and a special null reference, which refers to no object.

http://java.sun.com/docs/books/jls/third_edition/html/typesValues.html#4.3.1

[Blue-Tiger]

Optimizer schrieb:

phlox81 schrieb:

- Vermeide lokale Variablen in Java, da ja nur der GC diese wieder Zerstören kann

Uneindeutig und unwichtig. Lokale Variablen sind entweder vom Typ int, short, char, byte, long, float, double oder < Referenz > und die die Referenz wird dann zerstört wenn der Stack Frame abgebaut wird. Was du natürlich meinst, sind die Objekte auf dem Heap. Du denkst aber fälschlicherweise, dass der GC große Schwierigkeiten damit hätte, viele kurzlebige Objekte zu zerstören. Wenn man weiß, wie der GC arbeitet, weiß man auch, dass die Arbeit des GC dafür gegen null geht. Schlimm sind Objekte, die mittel-lang leben.

Wo kann man mehr ueber die Arbeitsweise des GC erfahren?

[Gregor@Home]

Blue-Tiger schrieb:

Wo kann man mehr ueber die Arbeitsweise des GC erfahren?

So auf die Schnelle habe ich nur folgendes gefunden. Da steht aber vermutlich schon einiges drin:

http://java.sun.com/docs/hotspot/gc5.0/gc_tuning_5.html

[Gast]

Irgendwer schrieb:

Ach komm, du scheinst zu viel Java programmiert zu haben und gar nicht mehr zu wissen wie man mit Pointern in C++ umgeht. Schon allein die Tatsache, dass du den Begriff "Pointer" mit Begriffen wie "Basis-Adresse" oder "Offset" assoziierst zeigt doch schon, dass alle Pointer für dich gleich Pointer auf Arrays sind.

Wenn man keine Ahnung hat...
Habe ich irgendwas von Arrays gesagt? Ein Pointer in C++, so wie du ihn wahrscheinlich öfters mal benutzt, zeigt auf die Basisadresse eines Objekts und die einzelnen Datenelemente sind offset. Einfache Pointerarithmetik. Du hast zu wenig maschinennah programmiert, vielleicht in dem Maße, wie ich zu viel Java programmiert habe, oder mehr. Achso, es ist ja völlig falsch, was haben Pointer schon mit Adressen zu tun??

Es gibt aber auch Pointer die auf ganz einfache Objekte zeigen. Diese sind entweder NULL, zeigen auf ein Objekt oder auf ein ehemaliges Objekt.

Alles uninteressant. Interessiert den Pointer gar nicht, was das ist.
Vielleicht wird dir so der Unterschied klar:
Pointer in C++ oder einer maschinennahen Sprache: 0x2ee37c22
Referenzen in Java: Objekt #632 oder null
Der Pointer zeigt auf eine Basisadresse, die Referenz kann intern als Pointer repräsentiert werden, muss aber nicht. Kann völlig anders sein. Kann eine Objekt-ID sein. Kann ein Array-Index sein, wo der wahre Pointer gespeichert ist. Hat Vorteile bei der Implementierung des GC.

Letztere sind entweder zu Recyceln oder zu Zerstören direkt nach ihrer Entstehung. Das Argument, dass Java Referenzen nicht in die Pampa zeigen können gilt nicht : Wenn man sich nicht um solche Referenzen kümmert wird der GC den Speicher nicht recyceln können.

Deshalb zeigen sie noch lange nicht in die Pampa.

Also fassen wir mal zusammen : C++ Pointer können NULL sein, auf ein Objekt zeigen und müssen nach ihrem Gebrauch beseitigt werden, Java Referenzen können null sein, auf ein Objekt zeigen und müssen nach ihrem Gebrauch beseitigt werden. Hört sich für mich irgendwie nach dem gleichen an.

Ja, weil du mir gerade erzählt hast, wie du Java-Referenzen und C++-Pointer benutzt. Du hast weder gesagt, was sie sind, noch dass man mit C++-Pointern noch andere Dinge anstellen kann. Mir ehrlich gesagt vollkommen egal, ob du glaubst, dass es das selbe ist. Es ist mir ungefähr so egal wie Vera am Mittag.

Hingegen, ist es garantiert, dass C++ Referencen immer fest mit einem Objekt verbunden sind was bei Java Referencen nicht der Fall ist.

Weiß ich doch. Was hat das mit dem Thema zu tun? Ich habe diese beiden Arten von Referenzen nie verglichen.

Die Tatsache, dass Pointer in C++ und Java Referenzen wegen der unterschiedlichen Speicherverwaltung anders implementiert sind, ist ein Implementierungsdetail, das den Benutzer der Klassen "C++" und "Java" nichts angeht.

Das entscheidest also du, ob mich das was angeht? Wenn du mir sagen willst, dass diese beiden Dinge das selbe sind, halte ich dich nicht davon ab, das zu glauben. Mir wirklich sehr egal, was du glaubst. Aber du schreibst mir nicht vor, was mich zu interessieren hat.

Gregor@Home schrieb:

Genau! Damals wie heute. Optimizer redet so oft Stuss. Sicherlich fast genauso oft wie ich. Ob es jetzt um Primzahlen geht oder ob er die Nutzung eines Konstruktors empfiehlt, der so ziemlich der unnützeste Konstruktor ist, den es gibt

Du hast mich mal wieder.

[Gast]

Schon allein die Tatsache, dass du den Begriff "Pointer" mit Begriffen wie "Basis-Adresse" oder "Offset" assoziierst zeigt doch schon, dass alle Pointer für dich gleich Pointer auf Arrays sind.

Übrigens: dass du NULL sagst, zeigt mir schon, dass du dich mit C++ nicht vollständig auskennst und mit dem Konzept des Überladen von Methoden nicht vertraut bist. Hast du dir schon mal überlegt, dass man foo(Auto*) und foo(int) haben kann? Weißt du was passiert, wenn du foo(NULL) aufrufst? Richtig, nicht das, was man vielleicht als erstes erwarten würde. Womit zweifelsfrei bewiesen wäre, dass du noch nie was vom Überladen von Methoden gehört hast. Einleuchtend, oder?