class Klasse1 {
    public:
      float *nummern;

      Klasse1(Klasse2 *klasse2) {
        nummern = new float[klasse2->laenge];
        for (int i = 0; i < klasse2->laenge; i++) {
          nummern[i] = 1.0f;
        }
      }
}

class Klasse2 {
    public:
      int laenge;
      Klasse1 objekt;

      Klasse2(int laenge) {
        this->laenge = laenge;
        objekt = Klasse1(this);
      }
}

Jetzt hatte ich erwartet, dass ich in einem Objekt der Klasse2 dann auf das Unterobjekt zugreifen kann und ein float-Array voll mit 1.0 habe. Ist aber nicht. Die Inhalte werden zurückgesetzt und ich bekomme irgendwelche Unsinnszahlen raus. Wenn ich aber im Konstruktor von Klasse2 mit "cout << Klasse1(this).nummern[0] << endl;" nachschaue, dann ist da 1.0 drin. Also stimmt irgendwas mit der anschließenden Zuweisung in "objekt" nicht. Nur was?

Wenn ich objekt als Zeiger gestalte, dann geht natürlich alles. Ich frage mich aber, ob das hier (oder auch im allgemeinen Fal) sinnvoll ist, weil ich dann ja jedes Mal, wenn ich das objekt benutzen will, ein Zeiger dereferenziert werden muss. Das kann's ja nicht sein, oder?

Dann noch ein paar Einzelheiten:
- Einer der Hauptpfeiler der OOP ist die Kapselung. Unter anderem bedeutet Kapselung in C++, dass man moeglichst nie Membervariablen oeffentlich zugaenglich macht. => Die Member nummern, laenge und objekt bitte als private deklarieren. Falls man dennoch Zugriff auf die member gestatten will, gibs sogenannte getter udn setter methoden.
- pointer werden beim Zerstoeren des beinhaltenden Objekts nicht automatisch Zerstoert. Du hast also ein Speicherleck, sobald du ein Objekt der Klasse1 hast (und wieder zerstoerst). Schreib also moeglichst einen Destruktro zu dieser Klasse.
- pointer werden 1:1 kopiert, wenn das beinhaltende Objekt per implizit generiertem operator= kopiert wird. Man endet also mit zwei Objekten, die auf den selben Speicher verweisen. Wird eins zerstoert, dann wird dessen Destruktor auch den Speicherbereich freigeben (du denkst doch hoffentlich an Speicherlecks, oder? :xmas1: ) - Resultat: das andere Objekt hat einen Pointer ins Nirvana. Die Loesung ist das Schreiben eines eigenen operator= fuer jede Klasse, die pointer als member hat. Also auch fuer Klasse1.
- Verwende initialisierungslisten, wo moeglich. Damit verhinderst du unnoetige Aufrufe von operator= im konstruktorrumpf.

ohne jetzt weiter auf Sinn und Unsinn des allgemeinen Designs einzugehn, wuerde ich deine beiden Klassen wie folgt umschreiben:

class Klasse1 {
public: 
  Klasse1(size_t n) nummern(n, 1.0f){}
private:
  std::deque<float> nummern;  //keine Pointer, keine Speicherlecks, 
                              //Kopieren ist sicher, alles bestens!
};

class Klasse2 {
public:
  Klasse2(size_t laenge) : laenge(laenge), objekt(laenge) {}
private:
  size_t laenge;
  Klasse1 objekt;
};

soooo ^^

Ich muss zugeben, diesen desaströsen Eindruck kann man von obigem Code durchaus gewinnen. Allerdings ist er nur ein Ausschnitt. Natürlich gibt es Default-Konstruktoren, und auch einen passenden Destruktor für alle Klassen, um dynamisch allokiertes Zeugs wieder zu löschen. Deswegen wird das auch gescheit kompliliert. Außerdem sind die meisten Sachen in meinem kompletten Code auch private (zugegeben: mein Fehler, dass ich sie hier alle unter public geschrieben habe). Ich habe außerdem absichtlich auf jede Art von STL-Datenverwaltung verzichtet, weil soweit ich weiß blanke Arrays immer noch am schnellsten sind, und mir das in meinem Fall sehr wichtig ist. Daher auch die zusätzliche Frage: Ist eine Initialisierungsliste tatsächlich schneller als ein Zuweisungs-Operator im Rumpf? Ich dachte, dass sei nur eine alternative Notation, die ohnehin gleich kompliiert wird. Oder ist das gar nicht der Grund, warum du diese Aufrufe vermeiden willst?

Allerdings hat mich dein dritter Punkt auf eine Idee gebracht. Ich ging davon aus (weil ich sowas gelesen hatte), dass operator= in diesem Fall gar keine Zuweisung, sondern der Copy-Konstruktor ist. Ist das hier gar nicht der Fall?

a) Initialisierungsliste für Klasse2:
das Objekt vom Typ Klasse1 wird an dem zugehörigen Platz mittels des Konstruktors Klasse(Klasse2*) konstruiert. Ende.

b) Operator= im Rumpf:
- das Objekt wird, da keine Initliste, am zugehörigen Platz mittels default-Ctor konstruiert.
- Im Rumpf wird mit Klasse1(this) ein zweites (temporäres) Objekt vom Typ Klasse1 mittels des Konstruktors Klasse1(Klasse2*) erstellt
- Klasse1::operator= wird für objekt aufgerufen, als Argument erhält er das temporäre Objekt
- das temporäre Objekt wird wieder zerstört

Na, welche Version ist kürzer?

Und nein, im Konstruktor-Rumpf ist das = kein copy-Ctor, da dort bereits alle Member konstruiert worden sind. Konstruktoren werden pro Objekt immer exakt einmal aufgerufen, und das geschieht für alle Member vor dem Konstruktor-Rumpf.
Die einzige Art, wo ein = einen Copy-Ctor darstellt, ist bei der Definition einer lokalen Variablen:

class A {
public:
  A(int i);      //Ctor
  A(const A& a); //copy-Ctor
};

int main() {
  A a1(5); //normaler Ctor
  A a2(a1); //Copy-Ctor
  A a3 = a1;  //Copy-Ctor durch =-Zeichen!
  A a4 = 17;  //ACHTUNG! auch Copy-Ctor
              //der Compiler macht daraus 
//A a4 = A(17); also 2 Ctor-aufrufe (ein temporäres Objekt)
//der Copy-Ctor _kann_ hier allerdings wegoptimiert werden (muss aber nicht)
}

Was die Geschwindigkeitsvorteile von blanken Arrays gegen STL-Container angeht, so können da durchaus gewisse Vorteile sein. Es ist aber fraglich, ob du genau an der Stelle durch die Verwendung von dynamischen Arrays so viel wett machst. Selbst wenn das Programm oft läuft, musst du immernoch die aufsummierten Mikrosekunden gegenrechnen gegen den Aufwand, den op=, den Dtor, den Copy-Ctor und andere Methoden entsprechend sicher zu tippen, und gegen den Aufwand, die Fehler, die sich bei sowas eigentlich immer irgendwann einschleichen, zu finden und zu beheben. Nicht zu vergessen den Aufwand bei der späteren Wartung, wenn man sich durch das Pointer- und Array-gefrickel wieder durchwursteln muss

objekt = Klasse1(this);

und keine Initialisierung.
Und nach der Zuweisung wird sofort der Destruktor des temp. Objekts "Klasse1(this)" aufgerufen, der höchstwahrscheinlich den Speicher für den Zeiger "nummern" löscht (und auch richtigerweise löschen sollte).

Und weil dies eben zu diesen Problemen führt, verwendet man (möglichst) keine Klassen mit dynamischen Speicher, sondern die dafür vorgesehenen Klassen der Standard C++ Library (z.B. std::vector, std::deque etc).

Ich habe außerdem absichtlich auf jede Art von STL-Datenverwaltung verzichtet, weil soweit ich weiß blanke Arrays immer noch am schnellsten sind, und mir das in meinem Fall sehr wichtig ist.

und dies ist blanker Unsinn...

Zitat:
Ich habe außerdem absichtlich auf jede Art von STL-Datenverwaltung verzichtet, weil soweit ich weiß blanke Arrays immer noch am schnellsten sind, und mir das in meinem Fall sehr wichtig ist.

und dies ist blanker Unsinn...

Genau, blanker Unsinn.

Also da war mein Missverständnis. Was ich gelesen hatte, bezog sich nur auf lokale Variablen. Aber so aus Interesse: Was macht denn dann eigentlich der Standard-Zuweisungs-Operator für eine neue Klasse, wenn man ihn nicht selbst schreibt? Ich könnte mir vorstellen, dass er einfach alle Variablen eins zu eins kopiert. Was passiert aber dann mit komplexeren Datentypen der zuzuweisenden Klasse?

Wäre es denn vorteilhaft hier die Variable objekt als Zeiger anzulegen? Dann müsste man natürlich kein komplettes Objekt kopieren und würde einfach beim Anlegen den new-Operator mit rein bringen. Allerdings müsste man beim Zugriff auf das Objekt jedes Mal einen Zeiger dereferenzieren. Wie macht ihr das denn bei solchen Fällen eher? (Oder lässt sich die Frage gar nicht so allgemein beantworten...)

Gut, vielleicht das mit den Arrays ist blanker Unsinn. Aber gibt es denn auch Zahlen, wie viel blanker Unsinn das ist? Also sind diese STL-Klassen tatäschlich genau so schnell wie reine Arrays. Es mag ja ein Vorurteil sein, aber immerhin wird ja bei diesen Klassen wohl noch verschiedenes Management ausgeführt, oder nicht? Also würde ich ja intuitiv sagen, dass da doch ein Unterschied sein müsste. Ich lasse mich aber auch gerne vom Gegenteil überzeugen.

Was macht denn dann eigentlich der Standard-Zuweisungs-Operator für eine neue Klasse, wenn man ihn nicht selbst schreibt? Ich könnte mir vorstellen, dass er einfach alle Variablen eins zu eins kopiert. Was passiert aber dann mit komplexeren Datentypen der zuzuweisenden Klasse?

Er weist alle Elemente einzeln zu. Wenn diese komplexe Datentypen mit eigenen Zuweisungsoperatoren sind, werden diese benutzt.

Was macht denn dann eigentlich der Standard-Zuweisungs-Operator für eine neue Klasse, wenn man ihn nicht selbst schreibt? Ich könnte mir vorstellen, dass er einfach alle Variablen eins zu eins kopiert. Was passiert aber dann mit komplexeren Datentypen der zuzuweisenden Klasse?

Genau, er kopiert alle Member 1:1. Für komplexe Datentypen (nicht PODs) wird deren Zuweisungsoperator aufgerufen.

Wäre es denn vorteilhaft hier die Variable objekt als Zeiger anzulegen?

Nein.

Also sind diese STL-Klassen tatäschlich genau so schnell wie reine Arrays.

Zugriffe auf vector mit operator[] sollten genau so schnell sein wie bei einem Array. Hier gibt es keinen Overhead und keine Indexprüfung (normalerweise). Der Operator sollte inline implementierbar sein.

Was macht denn dann eigentlich der Standard-Zuweisungs-Operator für eine neue Klasse, wenn man ihn nicht selbst schreibt? Ich könnte mir vorstellen, dass er einfach alle Variablen eins zu eins kopiert. Was passiert aber dann mit komplexeren Datentypen der zuzuweisenden Klasse?

Genau, er kopiert alle Member 1:1. Für komplexe Datentypen (nicht PODs) wird deren Zuweisungsoperator aufgerufen.

Der Zuweisungsoperator der nicht-statischen Member wird grundsätzlich aufgerufen, unabhängig vom Typ - im Falle von Klassen (POD oder nicht-POD) ist das ein Funktionsaufruf (der des jeweiligen für diese Klasse überladenen - explizit oder implizit deklarierten - Zuweisungsoperators), sonst der eines normalen Operators (Im Falle von Arrays als Membern wird der Operator für jedes einzelne Element aufgerufen). Andernfalls könnte man ja z.B. auch POD-Klassen mit konstanten Membern zuweisen.
Ein interessanter Aspekt des implizit deklarierten Zuweisungsoperators ist, dass er nicht exceptionsicher ist, falls irgendeines außer dem ersten Member bei der Zuweisung eine Exception werfen könnte. Das kann mal zu einer Abweichung der Regel der 3 führen, indem in entsprechenden Fällen nur der Zuweisungsoperator extra implementiert werden muss.