klasse mit statischen membern, welche in anderer Klasse eingeschachtelt ist

PiCiJi

Ich habe eine Klasse, die eine weitere Klasse enthält, welche statische member enthält.

Ich instanziere die äußere Klasse einmal auf dem Stack. Dies ist das Hauptobjekt, welches über die gesamte Lebenszeit der Anwendung existiert.

Das Hauptobjekt instanziert dann später member der äußeren Klasse auf dem Heap und kopiert die Eigenschaften des Hauptobjektes in ein heap member. Dies soll eine Arbeitskopie darstellen.

Der Konstruktor der äußeren Klasse erstellt mehrere member der inneren Klasse. Für all diese member gilt der gleiche Wert, was die static Variablen betrifft.

Jetzt zu meinen Fragen:
Ist es richtig, dass für 2 verschiedene Objekte der äußeren Klasse, die static Eigenschaften der member der inneren Klasse jeweils verschieden sein können? Oder hat ein static member der inneren Klasse für alle Objekte stets den selben Wert, selbst wenn die Objekte verschiedenen Objekten der äußeren Klasse angehören?
Spielt es dabei eine Rolle, dass ich Objekte der äußeren Klasse auf dem heap und stack anlege?

unskilled

Nein - static ist immer global und einmalig - außer bei templates...

Spielt es dabei eine Rolle, dass ich Objekte der äußeren Klasse auf dem heap und stack anlege

Wer kommt denn auf so ne Idee? Oo

bb

drakon

unskilled schrieb:

Nein - static ist immer global und einmalig - außer bei templates...

Streng genommen auch bei Templates. Man muss bedenken, dass Templates keine Klassen sind, sondern Schablonen von Klassen.
Das ist ja auch einmalig:

class foo{
static int i;
};

class bar{
static int i;
}

PiCiJi

danke für die Info, dann muss ich mein Programm ändern, da die static member der inneren Klasse für verschieden Ojekte der äußeren Klasse auch verschieden sein können sollen.

Warum verwendest du dann überhaupt static member?

PiCiJi

weil bestimmte Eigenschaften für die Objekte der inneren Klasse immer gleich sind.

Das mit dieser außeren und inneren Klasse hört sich für mich nach nem komischn design an. Was willst du überhaupt machen?

PiCiJi

ich erstelle pro Bildzeile eine Arbeitskopie mittels des main threads, damit anhand dieser in einem 2. Thread die Bildzeile berechnet und gecacht werden kann, während der main Thread die Programmausführung weiter voran treibt.

Ich habe den 2. Thread zur Zeit deaktiviert. Das erstellen einer Arbeitskopie auf dem heap (Ziel: 224 * 60 Objekte pro Sekunde) (nur für das Anlegen der Objekte) kostet ja brutal viel Rechenzeit. Die Anwendung läuft 75% langsamer. Das geht gar nicht.

Ich muss die Objekte(max. 224) wohl vorher einmalig anlegen und dann nur die Eigenschaften ändern.

Nachtrag: im release Modus ist der Geschwindigkeitsverlust nur 15%.

unskilled

PiCiJi schrieb:

Nachtrag: im release Modus ist der Geschwindigkeitsverlust nur 15%.

Ich frag mich immer wieder, warum es so viele gibt, die Geschwindigkeitsmessungen im Debug-Modus durchführen... Aber wenigstens isses dir noch von allein aufgefallen ^^

PiCiJi schrieb:

Ich muss die Objekte(max. 224) wohl vorher einmalig anlegen und dann nur die Eigenschaften ändern.

Hört sich sinnvoll an ^^

bb

Wozu du da so ne komische Klassenstruktur bruachst, versteh ich aber immer noch nicht.

Wie wäre es wenn du die Objekte aus einem Objektpool holst, statt jedes mal inklusive Speicheranforderung und Speicherfreigabe eine Menge Zeit zu verbraten?

PiCiJi

ja das suchen nach freien Speicher auf dem heap dauert schon seine Zeit. Ich lege die Objekte jetzt vorher einmalig an, da mir die maximale Anzahl vorher bekannt ist. Der geringe Nachteil ist, das mehr Speicher benötigt wird.

@detroit
ich brauche die eingeschachtelte Klasse nicht zwingend. Ich hatte diese erst vor ein paar Monaten rein gearbeitet. Der einzige Grund dafür war, zusammengehörige Elemente auch zusammengehörig zu verpacken. Die äußere Klasse beschreibt das Caching allgemein. Eine innere Klasse z.b. beschreibt die Hintergründe aus denen ein Bild bestehen kann oder eine weitere die Berechnung der sprites usw.
Z.b. kann ein Bild aus maximal vier Hintergründen bestehen, jeder Pixel eines Hintergrundes ist priorisiert um später zu entscheiden, welcher Pixel von welchem Hintergrund dargestellt wird. Es gibt nun Eigenschaften, welche für alle Hintergründe identisch sind, darum static.