Vor- und Nachteile Datenhaltung innerhalb von Klassen

[Leverator]

Hallo zusammen,
ich habe gerade eine theoretische Frage an Euch:
Welchen Vor- bzw. Nachteil hat es, wenn man Daten innerhalb der Klasse hält im Vergleich dazu, wenn man diese von Außen zum Berechnen hinzugibt.

Konkret halte ich in einer Struktur Daten, welche als Array organisiert die Daten bildet.
Z.B. so:

Code: Alles auswählen

struct stData {
  float *input;
  float *matrix[];
  flaot *output;
}

Und jetzt könnte ich diese Struktur innerhalb der Klasse verwenden:

Code: Alles auswählen

class calcData {
public:
  stData	D[100];
  [...]
  int calc();
  [...]
}

Und in der main dann:

Code: Alles auswählen

int main() {
  calcData clsData;
  clsData.calc();

  return 0;
}

Oder:

Code: Alles auswählen

class calcData {
  int calc( stData D )
};

Und in der main() rufe ich auf:

Code: Alles auswählen

int main() {
  stData D[100];
  d[0].input = new float[5];
  [...]
  for( int i=0; i<5; i++ ) {
    calcData::calc( D[i] );
  }
  
  return 0;
}

Welche Version benötigt die geringste Anzahl an CPU-Zyklen und welche verbraucht die geringste Menge an Speicher?
In diesem Beispiel liegt die Organisation der Daten in der main()-Funktion. Dieses würde natürlich durch eine übergeordnete Klasse geschehen.
Es geht mir hier lediglich um die Frage was effizienter läuft.

[cloidnerux]

Ich habe keine direkte Antwort zu Effizienz. Rein theoretisch müsste der Compiler beide Versionen ähnlich stark optimieren und bis auf ein paar extra CPU Zyklen für den OOP Ansatz auch gleich schnell laufen.

Generell geht deine Frage eher in eine Richtung über Designphilosophie und OOP.
Deiner erster Fall ist theoretisch der OOP ansatz. Du abstrahierst deine Daten in ein Objekt, das in seinem Kontext Funktionen anbietet, z.B eben calc. Daher ist es für dich als Programmierer einfacher, weil du ja immer mit dem Objekt und nicht nur einer Sammlung floats arbeitest.

Der zweite Fall ist eher ein Datenbasierter Ansatz oder halt ohne OOP. Du hast Daten als Blob im Speicher und Arbeitest direkt mit diesem Blob. Alle Verwaltung musst du in deinem Haupt-Code durchführen. Die Weitergabe erfolgt immer über den direkten Pointer zu deinem Blob an Daten. Sowas ist für manche Anwendungen mehr als Ausreichend. Besonders in Embedded Kontext oder Treibern, die sehr Deterministisch und statisch sind, ist der zusätzliche Programmieroverhead von Klassen selten mit einem Mehrwert verbunden.
Planst du aber eine größere Desktop Software ist es durchaus besser, OOP zu nutzen.

Wenn du deinen Code optimieren möchtest, definiere dir erstmal Anforderungen. Man kann sehr viel Zeit damit Verbringen irgendwelchen Code zu schreiben, evt sogar selbst mit Assembler anzufangen, ohne dabei einen nennenswerten Vorteil zu erreichen. Wenn du echtzeit Audio oder Video machen möchtest, dann kann man definieren wie viel Zeit man hat. Liegt man darunter, alles gut. Schafft man es nicht, muss man sich auch anschauen, ob man es überhaupt schaffen kann.

[Leverator]

Danke für Deine Antwort.

Im Prinzip habe ich bereits so etwas ähnliches erwartet.
Tatsächlich soll meine Software später einmal auf einem STM32 laufen und Numbercrunching machen: Filtern und Faltungen im Zeit- bzw. Frequenzbereich (=fft). Letzteres wäre dann paketweise organisiert, Ersteres wären Datenstreams, die mit den jeweils aktuellen Daten rechnen - soweit vorhanden.

In der Zwischenzeit habe ich daher einen datenbasierten Ansatz gewählt.
Die Definition, wieviel Zeit ich für das Berechnen habe ist - da Privatprojekt - nicht wirklich relevant. Aber ich befürchte schon, dass ich durchaus interessante Anwendungen finden werde, die dann tatsächlich entsprechend performant umgesetzt werden wollen.

Ich kann einfach den Overhead durch OOP nicht recht überblicken: Wenn class im Prinzip nur ein anderes Wort für struct ist, dann dürfte sich doch kaum etwas ändern, oder? Werden mit jedem Instanziieren des Objektes auch die Prozeduren mit instanziiert? Hätte ein Pointer auf die jeweilige (gleiche) Prozedur in unterschiedlichen Objekten eine andere Adresse? Oder gibt es da im Hintergrund durchaus erhebliche Optimierungen?

Viele Grüße,
Lev

[cloidnerux]

Es gibt gute Infos dazu, wie der C++ compiler deinen Code umsetzt und was im Hintergrund noch an OOP-Management passiert. Ich kenne mich damit nicht aus, da ich dann irgendwann mich in andere Themen vertieft habe und ich auch viel Embedded gemacht habe, wo es ehh nicht relevant war. Meine Erfahrung nach ist OOP auf den meisten Embedded Plattformen auch unnötig und liefert nur begrenzt irgendeinen Mehrwert. Die Applikation ist meistens rein deterministisch, du hast wenig code-reuse oder sehr spezielle Verzahnung mit der Hardware, sodass sich abstraktion nur begrenzt überhaupt lohnt.

Besonders für Number crunching, FFTs und ähnliches ist der Code sehr überschaubar, aber du willst ja maximal viel vorteil aus DMA und ähnlichem ziehen. Da macht die Verkapselung und Klassen egt mehr Aufwand als nutzen.