"Java"-Klassen für C++

[Flummi]

Hallo,

weiß vielleicht jemand, ob es für C++ sowas wie Java-Klassen gibt?
Was ich meine ist nicht eine Reimplementation der Java-Klassen in Java, sondern in C++. Also dass man quasi Klassen ala String, Object, Array, Integer, usw. hat.

danke im Vorraus,
Flummi.

[locus vivendi]

ACDK dürfte dem recht nahe kommen.
http://acdk.sourceforge.net/

Was Containerklassen angeht, würde ich aber eher solche empfehlen, die dem "C++ Stil" entsprechen. Also z. B. die der Standardbibliothek.

[Flummi]

Ok, danke. Was ich noch wissen wollte: Gibt es für C++ auch sowas wie eine API-Referenz, wo man nachschauen kann, welche Klassen es gibt und was sie können, sowas wie im Stil der Java-API unter http://java.sun.com/j2se/1.5.0/docs/api/ ?

[locus vivendi]

Gibt es für C++ auch sowas wie eine API-Referenz, wo man nachschauen kann, welche Klassen es gibt und was sie können, sowas wie im Stil der Java-API [...]
Ja. Zur Libstdc++, das ist die Implementierung der C++ Standarbibliothek des GCC, gibt es eine ähnliche Referenz. Die empfinde ich aber als etwas unübersichtlich. Die Dinkumware-Referenz ist ebenfalls der Java-API Doku relativ ähnlich. Aber gerade für C++ würde ich auch immer ein Buch oder ein gutes Tuturial, oder allgemein Lehrmaterial empfehlen. Sprich, es ist vermutlich hilfreich auch solche Texte anzuschauen die weniger dem Stil einer reinen API-Doku wie von dir verlinkt entsprechen.

Die angesprochenen Referenzen findest du jedenfalls hier.
http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html
http://www.dinkumware.com/manuals/default.aspx?Page=

[Flummi]

Ok, danke dir vielmals,
schönen Abend wünsche ich,
Flummi.

[anda_skoa]

Eine Klassenbibliothek, die auch vom Stil her eher Java-ähnlich ist, wäre Qt

Ist auch von der API Dokumentation vergleichbar, wenn auch nicht ganz im Umfang :)

Ciao,
_

[Flummi]

Ah, cool. Thanks :)

[panzi]

Wennst aber net mehr brauchst als string, list, vector (resizeable array) und andere standard sachen, dann reicht ja die STL, und die is bei jedem C++ Compiler sowieso dabei.
Eine von vielen Referenzen für die STL wäre jene:
http://www.sgi.com/tech/stl/

[RHBaum]

@anda_skoa

Aehm QT, Java aehnlich ? das haam die Jungs von Trolltech nu wirklich ned verdient ^^

@Flummi
Gibt ne menge GUI- API's fuer windows z.b. oder fuer Linux. Wenn es plattformunabhaengig sein soll (wie Java) scheiden schon mal ne menge aus ...
viele verwenden auch keine C++ (Klassen) sondern eher c schnittstellen, um ihre API's nicht nur fuer c++ sondern auch fuer andere sprachen zugaenglich zu machen. Ausserdem gibts beim exportieren von Klassen ueber dll/so grenzen hinweg immer wieder probleme (unter windows mehr als wie unter unix, besonders wenn man den quellcode ned offenlegen will)

Also bleiben fuer plattformunabhaengige und klassenbasierte Libs nur noch ne Handvoll ueber.
Auf Anhieb faellt mir da auch nur die QT und wxWidgets noch ein.

Ciao ...

[Flummi]

Danke für die zahlreichen Antworten. Eventuell hätte ich mein Anliegen, warum ich gerne java-ähnliche Klassen bei C++ hätte, erläutern sollen: Ich fand es einfach extrem angenehm, einer Referenz auf den Typ "Object" Objecte quasi jeder anderen Klasse zuteilen zu können, weil mehr oder weniger alle anderen davon abgeleitet sind.
Ist das bei C++ überhaupt möglich? In einem meiner C++-Bücher las ich nämlich, dass dann ja die Member-Variablen und Methoden, die in der Unterklasse zwar existieren, in der Basisklasse aber nicht, unter den Tisch fallen. Das heißt wohl, dass man sie nicht mehr verwenden kann, ok, aber heißt das auch, wenn ich das Objekt wieder einer Referenz des richtigen Typs zuweise, dass die Daten/Metoden auch nicht mehr vorhanden sind? Oder "tauchen" die wieder auf?

[Joghurt]

Du müsstest dann casten, am besten zur Laufzeit mit dynamic_cast<NeueKlasse>, der wirft dann eine Exception, wenn das Übergebene Objekt gar nicht die Klasse ist.

Nennt sich RTTI (Run-Time Type Information), Google oder (sehr wahrscheinlich) der Stroustoup hilft weiter

[locus vivendi]

Ich fand es einfach extrem angenehm, einer Referenz auf den Typ "Object" Objecte quasi jeder anderen Klasse zuteilen zu können, weil mehr oder weniger alle anderen davon abgeleitet sind.
Ist das bei C++ überhaupt möglich?
In C++ sind klassen nicht implizit von einer gemeinsamen Oberklasse abgeleitet. Wenn du eine Klassenhierarchie entwirfst kannst du für diese aber eine gemeinsame Oberklasse benutzen. Das hilft dir natürlich nicht, wenn du fremde klassen hast. Allerdings kannst du mit Mehrfachvererbung arbeiten, d. h. du leitest eine neu Klasse sowohl von der Fremdklasse, als auch von deiner Oberklasse ab. Diese neu entstandene Klasse kann dann in deiner Klassenhierarchie mitspielen.


In einem meiner C++-Bücher las ich nämlich, dass dann ja die Member-Variablen und Methoden, die in der Unterklasse zwar existieren, in der Basisklasse aber nicht, unter den Tisch fallen.
Das ist korrekt, und nicht anders als bei Java.


Das heißt wohl, dass man sie nicht mehr verwenden kann, ok, aber heißt das auch, wenn ich das Objekt wieder einer Referenz des richtigen Typs zuweise, dass die Daten/Metoden auch nicht mehr vorhanden sind? Oder "tauchen" die wieder auf?
Hier kann ich nicht mehr ganz folgen. Wenn du eine Referenz (oder Pointer) vom Typ "Referenz auf Basisklasse" hast, die aber tatsächlich auf ein abgeleitetes Objekt zeigt, dann kannst du die Referenz auf den Typ "Referenz auf abgeleitete Klasse" casten, und über diese Referenz dann natürlich die Member der abgeleiteten Klasse ansprechen. Beantwortet das deine Frage?

[Flummi]

[...]
Hier kann ich nicht mehr ganz folgen. Wenn du eine Referenz (oder Pointer) vom Typ "Referenz auf Basisklasse" hast, die aber tatsächlich auf ein abgeleitetes Objekt zeigt, dann kannst du die Referenz auf den Typ "Referenz auf abgeleitete Klasse" casten, und über diese Referenz dann natürlich die Member der abgeleiteten Klasse ansprechen. Beantwortet das deine Frage?
Lol, ich bin auch schon ganz duselig :D, aber ja, das beantwortet meine Frage in der Tat. Danke.

[RHBaum]

@Flummi

Das was du so toll findest, ist eigentlich genau das, was eine typsichere Sprache verhindern will.
Leider kommt man grad bei umfangreicheren bibliotheken nicht immer drumherum. Trotzdem sollte man downcasts immer zumindest 2 mal betrachten um sicherzustellen das es wirklich notwendig ist. DIverse fachbuecher bezeichnen das dann auch gleich als designtechnische Schwachstelle.

Auch wenn es bequem ist, brauchst du es wirklich ?

Ciao ...

[Flummi]

@RHBaum:
Ich denke nicht, dass man es unbedingt braucht, aber wie gesagt, es macht vieles einfacher. Zum Beispiel, wenn ich an eine doppelt-verkettete, lineare Liste denke, mit solchen Knoten:

ListenKnoten* next;
ListenKnoten* prev;
Object* value;
Mit einem allumfassenden Basis-Objekt kann man den selben Knoten für alle Arten von Klassen verwenden, weil ich ja die Objekte immer casten kann.
Wenn ich das nicht kann, müsste man zB ja für jede Art Value eine Subklasse der Basisklasse ListenKnoten machen, die dann fähig ist, die entsprechenden Objekte aufzunehmen. Oder irre ich da? (bin noch blutiger Anfänger, wie man wahrscheinlich erkennen kann ;) ).

[anda_skoa]

Nur das man weder in Java noch in C++ selber eine verkettete Liste machen wird, weil es dafür fertige Standardcontainer gibt.

Und in C++ kannst du jeden Typ, auch primitive, in den Standardcontainer verwenden, weil der Container ohnehin vom Kompiler für genau diesen Typ bzw. die angebebene Basisklasse erzeugt wird.

Ciao,
_

[Flummi]

Schon klar, dass es vorgefertigte Klassen gibt, es ging mir ja nur um ein Beispiel. Eventuell kommt man ja mal in die Verlegenheit, selbst etwas schreiben zu müssen, dass genau die selbe Problematik aufweist.
Danke nochmals an alle für die tolle Hilfe :)

[panzi]

Will nur auf folgendes hinweisen: Was Templates sind weißt eh? Also in der STL (Standard Template Library) gibt es Templates für alles was man sich vorstellen kann. Bei einem Template (Vorlage) wird der Typ irgendeiner Variable ausgelassen, so das man ihn erst bei der Instantzierung ausfüllen kann. Damit schreibe ich einmal eine Listenklasse (ist in der STL schon erledigt) die ich dann für jeden Typ instanzieren kann.


#include <list>
#include <string>

//...

std::list<int> intlist;

intlist.push_back(5);
intlist.push_back(7);
intlist.push_back(3);

// ...

std::list<std::string> strlist;

strlist.push_back("hallo welt");
strlist.push_back("foo bar");


Sowas gibts auch ab JDK 1.5 ("Java 5") und fnde ich viel besser als den crap mit dem Object gecaste. Ist eben typsicherer.

[anda_skoa]

Schon klar, dass es vorgefertigte Klassen gibt, es ging mir ja nur um ein Beispiel. Eventuell kommt man ja mal in die Verlegenheit, selbst etwas schreiben zu müssen, dass genau die selbe Problematik aufweist.


Jein :)

Normalerweise hat man entweder eine Basisklasse oder ein Interface von dem alle Klassen ableiten bzw. das alle Klassen implementieren, oder man hat einen echt generischen Fall, wo man dann selber ein Template schreibt.

Mir fällt jetzt außer den Containern in Java auch kein Fall ein, der die Sache mit Object als Basis aller Klassen benötigen würde.

@panzi: die neuen Java Container sind leider nur syntaktisch vergleichbar, sie machen das Casten nur intern, zu einer echten generischen Implementierung hat es leider nicht gereicht

Ciao,
_

[panzi]

Jein :)@panzi: die neuen Java Container sind leider nur syntaktisch vergleichbar, sie machen das Casten nur intern, zu einer echten generischen Implementierung hat es leider nicht gereicht

Stimmt. Das merkt man bei irgeneiner Methode (hab Namen vergessen), die trotzdem immer noch ein Object in der Schnitstelle hat.

[locus vivendi]

Ich denke nicht, dass man es unbedingt braucht, aber wie gesagt, es macht vieles einfacher. Zum Beispiel, wenn ich an eine doppelt-verkettete, lineare Liste denke, mit solchen Knoten:

Code:
ListenKnoten* next;
ListenKnoten* prev;
Object* value;
Mit einem allumfassenden Basis-Objekt kann man den selben Knoten für alle Arten von Klassen verwenden, weil ich ja die Objekte immer casten kann.
Wenn ich das nicht kann, müsste man zB ja für jede Art Value eine Subklasse der Basisklasse ListenKnoten machen, die dann fähig ist, die entsprechenden Objekte aufzunehmen. Oder irre ich da?
Die Knoten kannst du mit Zeigern auf void untereinander verknüpfen. Ein void* kann nämlich auf jedes Objekt zeigen. Allerdings braucht man immer noch die Typinformation in irgendeiner Form, wenn Objekte mit einem nicht-trivialen Destruktor gespeichert werden sollen. Denn mithilfe eines void* alleine kommt man nicht an den Destruktor heran. In deinem Beispiel würde eine gemeinsame Basisklasse also tatsächlich helfen. Nur muss man im Gegenzug auch beachten, dass eine gemeinsame polymorphe Basisklasse gleich alle Objekte deren Typ eine Klasse ist aufblähen würde. Allerdings glaube ich mittlerweile das eine gemeinsame Basisklasse für alle Klassen, die sowieso schon polymorph sind ein guter Kompromiss wäre. Das würde sich mit verbreiteten C++-Implementierungen mit "fast" Null-Overhead bewerkstelligen lassen. Man könnte dann ja auch immer noch einen Mechanismus haben, um diese Basisklasse zu verhindern, wenn das wirklich gewünscht wird.

Noch ein letzter Punkt: In Java kann man ja nur *Referenzen* auf Objekte von Klassenttyp (also nicht "int" z.B.) in Collections packen, oder sagen wir mal in die Collections des JDK. Wenn man ähnlich dazu nur Pointer in C++-Containern speichern würde, dann würde dein Beispiel von oben nicht gelten. Denn Pointer haben einen trivialen Desktruktor, damit ist Kenntniss des exakten Typs nicht unbedingt notwendig um den Speicher für sie sauber abzuräumen. Allerdings ist damit immer noch nicht die ganze Wahrheit gesagt, um dein Beispiel betreffend Java und C++ zu vergleichen, aber ich höre jetzt trotzdem auf zu schreiben...