Das ist das Ende von C++!

thordk

TactX schrieb:

thordk schrieb:

geht nur darum, dass es auch c++ compiler gibt, die diese beiden features nicht bieten, weil sie eben ein zusatz sind, kein integraler bestandteil. in D isses anders.

Dir ist schon klar, dass eine Stringklasse bei manchen Implementierungen schlicht albern wäre? Eben deswegen gibt es ja die Unterscheidung zwischen "freestanding" und "hosted" environments.

naja, die unterscheidung gibs aber auch nur, weil es bisschen bekloppt wär, für jedes x-beliebige embedded system o.ä. den vollen lib funktionsumfang anzubieten (garantieren zu müssen), was meist nichtmal möglich wäre.

aber was trägt das zur diskussion bei? c++ bietet dies nur an, da so keine dedizierten c compiler herhalten müssen und man bestimmte möglichkeiten von c++ ausnutzen kann, sofern anwendbar. hier trifft wieder das "historisch gewachsen" zu.

will D denselben ansatz liefern? ich denke nicht. ne sprache, die ausgerechnet mit automatischer GC wirbt, wird wohl nicht für freestanding entwicklung konzipiert worden sein.

äpfel und birnen

Zeus

Artchi schrieb:

Ja, also die Idee von D ist ja nicht schlecht. Auch wenn ich wieder ein paar Sachen aus C++ vermisse. ...

Was vermisst du denn?

Ich muss sagen ich bin nach dem ersten ansehen sehr positiv überrascht. D bietet mir Sachen die ich in C++ immer vermisst hab . Natürlich wird D C++ in nächster Zeit nicht verdrängen, aber das Potenzial hat die Sprache ganz klar.

rüdiger

Optimizer schrieb:

Darum geht es doch nicht. Der Unterschied zu D ist, dass in C++ die Standard C++-String Klasse nicht als Sprachmittel zur Verfügung steht. Wenn du schreibst "Blubb", dann ist das ein char*.

Im Vergleich dazu ist in D, Java, C# und anderen Sprachen, die Strings auf Sprachebene integrieren, ein String-Literal wirklich vom Typ String. Zum Beispiel ist dadurch sowas wie "blubblubb".ToUpper() möglich. Klar, kann man darüber streiten, wie gigantisch der Vorteil ist. Auf Sprachebene erreicht man halt eine bessere Integration. Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Wenn man "foo" zu einem Objekt einer Klasse String macht, dann muss man aber einige "besondere" Klassen einführen. Das Widerspricht eben dem C++-Ansatz und würde die Sprache verkomplizieren. Ich meine eine Freestanding-Implementierung, die kein std::basic_string anbietet, macht dies ja aus einem gewissen Grund. Da macht es natürlich kein Sinn, das man sagt "Nö, eine Freestanding-Implementierung" darf das nicht.

Außerdem gibt es ja unterschiedliche String-Klassen, weil es eben nicht so leicht ist eine String-Klasse zu entwerfen. Die std::basic_string-Klasse ist ja alles andere als perfekt. Warum glauben gerade die D-Leute, die perfekte String-Klasse entworfen zu haben? (Wobei ich dazu sagen muss, das viele Probleme einer String-Klasse wohl für US-Amerikaner eh ziemlich abstrakt wirken dürften, mit denen sich jemand in Deutschland oder gar China rumprökeln muss.)

Der gleiche Grund ist es ja auch, warum man in C++ kein foreach hat, weil man damit eben die Trennung zwischen Sprache und Bibliothek aufheben müsste und ich halte viele Verbesserungen an C++ für sinnvoll. Aber sicher keine, die die Bibliothek mit der Sprache verwurschteln.

Zeus

Vielleicht habenn Sie genug Erfahrung gesammelt mit C++ Compiler bauen *g*

import std.stdio;

class Int{
	private int i;
}

void main() {
	Int i = new Int();
	i.i = 2;
	writef(i.i);
}

hmmmm 3 mal dürft ihr raten, was der Code macht.

Artchi

thordk schrieb:

string gehört zur standard lib, aber vector zur stl. aber is doch wurscht, wo der krams zugehört: es bleibt halt ne lib

Nö, ist nicht wurscht. Weil die Stdlib einen vector hat. Du scheinst nicht zu wissen, was die Stdlib und was die STL ist. Die STL ist eine bestimmte Implementierung, die von bestimmten Leuten entwickelt wird. (zu letzt bei SGI) Die Stdlib dagegen ist eine Spec in der ISO-C++-Norm, die string und vector enthält. Dadurch das die STL von jemandem in eigener Verantwortung entwickelt wird und nicht nach der Stdlib richtet, ist sie sogar zur Stdlib INKOMPATIBEL bzw. nicht mehr 100% kompatibel.

Fälschlicherweise sagt aber nur der Volksmund zur Stdlib "STL". Es ist halt nur tolerriert, aber richtiger wird es dadurch nicht.

thordk schrieb:

geht nur darum, dass es auch c++ compiler gibt, die diese beiden features nicht bieten, weil sie eben ein zusatz sind, kein integraler bestandteil.

Ein bestimmter C++ Compiler ist nicht C++. Du verwechselst hier ein PRODUKT mit einer Spec. Nur weil vielleicht ein von zehn Compilern keine vollständige Stdlib beiliegt, heißt das nicht, das C++ unvollständig ist. Versuche mal in deinen Kopf den Unterschied zwischen einer Spezifikation (ISO-C++) und einer Implementierung (Produkt) zu bekommen.
Wenn die EU für Autos die Euro4-Abgasnorm (Spezifikation) vorschreibt, und ein chinesischer Hersteller es nicht schafft Euro4 zu implementieren, kannst du auch nicht einfach sagen "Die Euro4 gibt es nicht, weil ein paar Hersteller kein Euro4 komplett in ihrem Auto X und Auto Y haben." Haha, sehr witzig.

thordk schrieb:

in D isses anders.

Es ist in dem einen D-Compiler ein string dabei, richtig. Aber was ist wenn ich morgen einen D-Compiler entwickle, und zeitlich nicht schaffe string einzubauen? Und sage: ihr könnt meinen D-Compiler benutzen! Hat dann D keinen Buildin-string mehr? Nach deiner Auffassung wäre das so.

thordk schrieb:

und? noch lang kein grund, hier den fanatiker zu spielen

Nö, ich informiere und stelle hier nur ein paar Unwahrheiten wieder richtig.

Artchi

Optimizer schrieb:

Darum geht es doch nicht. Der Unterschied zu D ist, dass in C++ die Standard C++-String Klasse nicht als Sprachmittel zur Verfügung steht. Wenn du schreibst "Blubb", dann ist das ein char*.

Ich streite ja nicht ab, das C++ in der Core-Language kein String hat. Aber ich streite ab, das C++ keinen Standard-String hat! Weil das ISO-C++-Dokument eindeutig std::basic_string und zwei typedefs enthält.

Optimizer schrieb:

Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Gerade du, der hier nun ein alter Hase im Forum ist, hätte ich eher zugetraut, das ihm bewusst ist, warum es soviele String-Klassen gibt. Schade.

Die vielen String-Klassen von Qt, MFC, wx usw. sind doch vor 1998 entstanden. Deshalb hat doch jeder seinen eigenen String gebastelt, weil es keine C++-Norm gab und man nicht davon ausgehen konnte, das es eine String-Klasse beim Compiler gab.

Aber z.B. std::wstring erfüllt mind. UCS2 bzw. UTF-16. Wenn jemand heute eine neue Lib entwickelt, wird er wohl kaum wstring umgehen.

[quote="Artchi"]
[quote="Optimizer"]Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.[/quote]
Gerade du, der hier nun ein alter Hase im Forum ist, hätte ich eher zugetraut, das ihm bewusst ist, warum es soviele String-Klassen gibt. Schade.

Die vielen String-Klassen von Qt, MFC, wx usw. sind doch vor 1998 entstanden. Deshalb hat doch jeder seinen eigenen String gebastelt, weil es keine C++-Norm gab und man nicht davon ausgehen konnte, das es eine String-Klasse beim Compiler gab.
[/quote]
Na und, das ändert nichts daran, dass das unheimlich nervt. Außerdem sind die std::(w)strings schon sehr mager, wenn man sie mit dem Java String vergleicht.

Artchi schrieb:

Optimizer schrieb:

Während es für C++ zahllose String-Klassen gibt und keine so richtig in der Praxis Standard ist, hast du in D die Situation, dass jeder die eine String-Klasse benutzt, schon allein indem er ein Literal hinschreibt.

Gerade du, der hier nun ein alter Hase im Forum ist, hätte ich eher zugetraut, das ihm bewusst ist, warum es soviele String-Klassen gibt. Schade.

Die vielen String-Klassen von Qt, MFC, wx usw. sind doch vor 1998 entstanden. Deshalb hat doch jeder seinen eigenen String gebastelt, weil es keine C++-Norm gab und man nicht davon ausgehen konnte, das es eine String-Klasse beim Compiler gab.

Na und, das ändert nichts daran, dass das unheimlich nervt. Außerdem sind die std::(w)strings schon sehr mager, wenn man sie mit dem Java String vergleicht.

Die smilies weg, nicht die BBCodes

Artchi

Was nervt dich? Die Standard-Strings? Oder die vielen Strings aus anderen Libs? Benutze dann halt eine Lib, die Standard-Strings verwendet. Dann nervt es nicht mehr. Wenn mich an einem Auto was grundlägend nervt, kauf ich das Auto nicht.

Die Boost-Leute schaffen es komischerweise in ihrer gesamtheit die Standard-Strings zu benutzen. Wenn Qt, WX u.a. es nicht schaffen auf Standard-Strings zu switchen, kann ISO-C++ nichts dafür. Beschwert euch doch bei den Urhebern von Qt, WX usw. Sollen sie halt endlich umbauen. Aber natürlich macht Qt das nicht, weil dann würden sie einen Abhängigkeitsgrund weniger haben.

MS hat ihre gesamte Win32-API auf const wchar_t* umgebaut. Kann ich problemlos std::wstring benutzen und wenn ich mal einen Parameter an Win32 übergebe, mache ich einfach c_str(), fertig. Es geht, wenn der API-Urheber es nur will.

Artchi schrieb:

Was nervt dich? Die Standard-Strings? Oder die vielen Strings aus anderen Libs?

Eigentlich beides.

Benutze dann halt eine Lib, die Standard-Strings verwendet. Dann nervt es nicht mehr. Wenn mich an einem Auto was grundlägend nervt, kauf ich das Auto nicht.

Manche Arbeitgeber woll nicht, dass man dauernd neue Libs einschleppt.

MS hat ihre gesamte Win32-API auf const wchar_t* umgebaut. Kann ich problemlos std::wstring benutzen und wenn ich mal einen Parameter an Win32 übergebe, mache ich einfach c_str(), fertig. Es geht, wenn der API-Urheber es nur will.

Das finde ich ja auch so toll, das man den "guten" std::string wieder zum "bösen" char* macht.
Sogar die STL ist so inkonsequent

basic_fstream (const char *__s, ios_base::openmode __mode=ios_base::in|ios_base::out)

TOLL!!!

Gregor

Artchi schrieb:

Wenn Qt, WX u.a. es nicht schaffen auf Standard-Strings zu switchen, kann ISO-C++ nichts dafür.

Ich denke nicht, dass man die Infrastruktur rund um eine Sprache bei der Betrachtung der Sprache ignorieren sollte. Das geht an der Realität vorbei. Es ist eine bewusste Entscheidung, bei C++ nur eine relativ kleine Standardbibliothek zu haben und das ist ein zentrales Problem von C++. Genau das führt dazu, dass derartige Inhomogenitäten bei der Verwendung üblicher Werkzeuge entstehen.

Du meinst, ISO-C++ ist nicht an solchen Inhomogenitäten schuld? Ok, so kann man das natürlich sehen. Wenn man den eigenen Verantwortungsbereich derart stark einschränkt, dass man sich für fast gar nichts zuständig fühlt, kann man auch an fast gar nichts schuld sein. Ich sehe eine umfassende Standardbibliothek aber durchaus als etwas an, für das der Standard verantwortlich sein sollte.

BTW: Genau aus dem gleichen Grund wird D nie irgendeine Relevanz bekommen: Da fehlt einfach eine umfassende Standardbibliothek.

Artchi

KennerDesProblems schrieb:

Manche Arbeitgeber woll nicht, dass man dauernd neue Libs einschleppt.

Ja, und? Was kann die C++ Norm dafür? Die anderen sind immer schuld? Wir können auch kein Java 1.5 oder 1.6 benutzen, weil unser Kunde leider IBM Java WebSpehere mit 1.4 vorschreibt. Weil IBM leider noch keinen WebSphere mit Java 1.5 rausgebracht hat. So, und nun? Ist jetzt Java EE inkonsistent? Nein, unser Kunde und IBM ist schuld das wir immer noch auf Java 1.4 rumkurken müssen. Ich gebe aber nicht SUN oder Java die Schuld! Weil ich sehr wohl zwischen Java-Spec und Implementierung/Produkt unterscheiden kann.

KennerDesProblems schrieb:

MS hat ihre gesamte Win32-API auf const wchar_t* umgebaut. Kann ich problemlos std::wstring benutzen und wenn ich mal einen Parameter an Win32 übergebe, mache ich einfach c_str(), fertig. Es geht, wenn der API-Urheber es nur will.

Das finde ich ja auch so toll, das man den "guten" std::string wieder zum "bösen" char* macht.
Sogar die STL ist so inkonsequent

Das kannst du vielleicht nicht wissen, aber die Win32-API ist eine C-API, nichts C++. Deshalb kann da schlecht eine String-Klasse benutzt werden. Aber ist ok. Das Beispiel habe ich nur aufgeführt, um zu zeigen, das eine API sehr wohl von einem Typ (in dem Fall char) auf einen aktuelleren/sinnvolleren Typ (in dem Fall wchar_t) umgestellt werden kann. Das C keine Klassen kennt, hat ja nichts mit C++ zu tun.

KennerDesProblems schrieb:

basic_fstream (const char *__s, ios_base::openmode __mode=ios_base::in|ios_base::out)

TOLL!!!

Ja, das stimmt allerdings. Das ist ein Defizit im noch aktuellen C++ Standard. Es sagt keiner, das C++ die perfekte Sprache ist.

Um dich aber zu beruhigen, in der C++2009-Norm werden solche Sachen auf die String-Klassen wahrscheinlich umgebaut (ein Proposal liegt dem Komitee vor). In der ISO-C++-TR2 wird es wahrscheinlich sogar eine path-Klasse geben. Leider ist das Thema TR2 erstmal auf 2009 verschoben, da sich das Komitee bis 2009 voll auf die neue ISO-C++-Norm konzentrieren will. Also, es wird an der C++-Spec weiter gearbeitet um diese zu verbessern.

Wenn C++-Benutzer diese Features nicht nutzen, ist das nicht die Schuld der Norm. Siehe auch IBM WebSphere.

Simon2

Hi,

also wenn ich sehe, dass bei uns immer noch Cobol-Programmierer eingestellt werden, wage ich zu bezweifeln, dass es überhaupt das "Ende einer Sprache" gibt.
Die Frage ist eher, welche Nische(n) eine neue Sprache besetzen (und ggf. einer anderen Sprache abknöpfen) wird.

Gruß,

Simon2.

Artchi

Gregor schrieb:

Artchi schrieb:

Wenn Qt, WX u.a. es nicht schaffen auf Standard-Strings zu switchen, kann ISO-C++ nichts dafür.

Ich denke nicht, dass man die Infrastruktur rund um eine Sprache bei der Betrachtung der Sprache ignorieren sollte. Das geht an der Realität vorbei. Es ist eine bewusste Entscheidung, bei C++ nur eine relativ kleine Standardbibliothek zu haben und das ist ein zentrales Problem von C++. Genau das führt dazu, dass derartige Inhomogenitäten bei der Verwendung üblicher Werkzeuge entstehen.

Du meinst, ISO-C++ ist nicht an solchen Inhomogenitäten schuld? Ok, so kann man das natürlich sehen. Wenn man den eigenen Verantwortungsbereich derart stark einschränkt, dass man sich für fast gar nichts zuständig fühlt, kann man auch an fast gar nichts schuld sein. Ich sehe eine umfassende Standardbibliothek aber durchaus als etwas an, für das der Standard verantwortlich sein sollte.

Ja, richtig. Ich sage, das es eine Norm gibt, und diese umgesetzt werden kann. Wenn ein C++ Compiler-Hersteller mir als Kunden keinen guten Compiler liefert (dazu gehört auch eine gewisse Einhaltung der Norm), kann ich mich gegen dieses Produkt entscheiden und ein besseres wählen. Genau das gleiche sehe ich bei Libraries, wie Qt. Wer Qt einsetzt und dafür auch bezahlt, hat bewusst die QString-Klasse in Kauf genommen. Ergo hat er sich gegen ein Produkt entschieden, welches wahrscheinlich Standard-Strings benutzt.

Nehmen wir SmartWin++, eine moderne C++-GUI-Lib für Windows. Diese benutzt konsequent std::basic_string. Warum? Weil diese Library erst nach der ISO-C++-Norm entwickelt wurde. Man hat die verfügbare Standardlib-Klassen genutzt. Finde ich gut! Ich sehe auch andere neue Libraries, die immer mehr Standard-Klassen einsetzen und z.B. auf eigene Strings verzichten. Die Infrastruktur ist ja da.

Ich muß hier auf Arbeit z.B. mit Java 1.4 arbeiten, weil leider IBM noch keinen WebSphere mit Java 1.5 rausgebracht hat. Aber weißt du auf wen wir fluchen? Nicht Java oder Sun. Nein, sondern auf IBM und unseren Kunden der IBM-Produkte einsetzt.

Nach deiner C++-Vorstellung, wäre also Java schuld, das einige Java-Enterprise-Hersteller nicht den kompletten aktuellen Java-Spec unterstützen??? Ich kann hier viele Sachen nicht umsetzen und einsetzen, wie ich es in Java 1.5 oder gar 1.6 machen könnte/wollte. Ich muß mich immer mit externen Lösungen (Libs) bedienen. Das gleiche kann man auch auf Firmen wie Trolltech übertragen. Sie gehen nicht mit der aktuellen C++-Spec.

Was die Mini-Standardlib angeht. Wer sagt dir denn, das das C++-Komitee eine Mini-Lib haben will? Im ernst, ich habe dergleichen noch nie offiziell gehört/gelesen. Ganz im Gegenteil, das Komitee sucht vergeblich Leute, die Library-Vorschläge einreichen! Es wurde vor zwei Jahren offiziell nochmal vom Komitee ein Aufruf gestartet, das die Community bitte Vorschläge für XML, Netzwerk, Unicode und andere Libraries einreicht. Das einzige was bisher nicht eingereicht wurde, sind XML-Lib-Vorschläge.

Das was man als C++-Nutzer nicht erwarten kann, ist eine GUI-Lib, obwohl Bjarne Stroustrup offiziell sich sowas wünscht. Aber er sagt, das es hier keine Lösung geben kann, die die C++-Community befriedigen könnte. Mein Meinung: Javas Swing zeigt es ebenfalls, da es auch dort mehrere GUI-Libs (SWT z.B.) gibt. Weil Swing nicht jedem Anspruch/Vorstellungen gerecht werden kann (obwohl mir pers. Swing seeehr gut gefällt).

Clw

Bevor jetzt irgendwelche Spekulationen aufkommen: In D gibt es auch keine string-Klasse wie in Java oder C# (zumindest keine standardisierte). String Literale sind vom Typ char[] ("..."c), wchar[] ("..."w), dchar[] ("..."d). Diese sind als dynamische Arrays implementiert und lassen sich genauso behandeln, wie alle dynamischen Arrays. Ein String-Literal muss nicht unbedingt ein c, w oder d als Typmarker haben, sondern sein Typ wird automatisch hergeleitet, wenn möglich

nep

Du hast schon recht mit dem was du sagst Artchi. Das ändert aber nix daran, dass es in der Praxis eben nun mal häufig nervig ist z.B. verschiedene Strings benutzen zu müssen. Und gerade du müsstest doch wissen, dass es gerade in der Praxis eben nicht so einfach ist, einfach mal zu sagen "Ne Lib xyz benutzt keinen std::string, also benutz ich die auch nicht". Oft hat man doch gar keine Wahl und ist an irgendwelche Vorgaben gebunden. Oder was bringt mir z.B. eine Lib die sich meinetwegen an den Standard hält, aber nicht alles kann was ich benötige?
Das ist in Java/C# eben nun mal einfach besser gelöst (oder anders ausgedrückt: produktiver). Da muss ich mich z.B. nicht um die verschiedensten String-Klassen kümmern.

Artchi

@nep! Ja, natürlich weiß ich selber das es nicht so einfach ist. Ich arbeite täglich 8 Std. beruflich nicht mit dem was ich gerne hätte (z.B. immer das aktuellste Java). Wenn jemand Qt oder WX benutzt ist er natürlich in einer Zwickmühle. Und natürlich ist das die Realität. Nur frage ich mich, ob es das besser macht, wenn man auf die C++-Norm meckert? Es bringt nichts!

Genauso bringt es nichts, wenn ich in ein Java-Forum gehe, und dort über Java herziehe, weil ich IBMs WebSphere einsetzen muß. Dann sagen mir die Java-Forums-Members: "Wechsel doch den ApplikationServer, z.B. auf JBoss." Oder "Beschwer dich bei IBM!" Keiner Würde sagen "Ja, das ist leider die Realität. Java ist schlecht." Aber ich als C++-User soll von Java- und D-Fans mir anhören, das C++ schuld ist? Da wird doch mit zweierlei Maß gemessen. Das ist eigentlich das, was mich auf die Palme bringt. Fakten bringen mich nicht auf die Palme, nur Falschaussagen und vermischung von Fakten.

nep

Ich finde dein Beispiel mit dem WebSphere hat aber eine ganz andere Dimension. Das ist etwas spezielles was so mit Java ja erst mal wenig zu tun hat, ausser dass es eben mit Java geschrieben wurde. Mit Strings im Gegenzug wirst du eigentlich immer konfrontiert werden, egal was du machst. Es geht hierbei eben um viel grundlegendere Dinge, als z.B. ein Application Server.
Versteh mich nicht falsch, ich will jetzt auch nicht sagen "C++ ist scheisse", das ist es an sich ja auch nicht. Nur bringt einem das auch nicht viel, wenn man dann in der alltäglichen Praxis doch meistens eben mit genau solchen Problemen konfrontiert wird

Artchi

nep schrieb:

Das ist in Java/C# eben nun mal einfach besser gelöst (oder anders ausgedrückt: produktiver). Da muss ich mich z.B. nicht um die verschiedensten String-Klassen kümmern.

Man sollte aber nicht verheimlichen, das es auch in Java mittlerweile drei String-Klassen gibt, weil nicht eine einzige alle Anforderungen auf einmal abdeckt. Mittlerweile sind drei dabei:

String
StringBuilder
StringBuffer

Je nachdem, was ich gerade braucht, muß ich mir eine Aussuchen. Das einzige was in Java wirklich kosistenter ist, ist das die parameter bei Methoden String erwarten. Aber wie gesagt, hier könnten Qt usw. durch Überladung sich bessern. Beispiel ist der QPushButton. Warum gibts keine Überladung, z.B. so:

QPushButton::QPushButton ( const QString & text, QWidget * parent = 0 );
QPushButton::QPushButton ( const std::wstring & text, QWidget * parent = 0 );

Die Implementierung des 2. Ctors könnte dann eine Konvertierung nach QString machen. Mir als Benutzer der QPushButton-Klasse wäre es egal, was intern passiert. Ich könnte aber direkt meinen wstring übergeben.

MS hat das in Windows ähnlich gelöst (Pseudo-Code!):

void MessageBox (const char *text,    const char *title, ...);    // ASCII-Variante
void MessageBoxW(const wchar_t *text, const wchar_t *title, ...); // Unicode-Variante

Der Clou ist, das die MessageBox-Implementierung eigentlich MessageBoxW aufruft, und für den ASCII-User die Konvertierung nach Unicode übernimmt. Aber MS hat sich zumindest die Mühe gemacht, beide User zu bedienen. Sie nutzen also die C-Norm aus.

Das erwarte ich von den großen C++-Frameworks auch. Leider machen die das nicht, um die User abhängig von ihren Klassen zu machen. (so kommt es mir zumindest vor)