mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik C++: Wie nutzen 2 vererbte Objekte selben Speicherbereich?


Autor: Alexander I. (daedalus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich möchte folgendes machen:
class father
{
 protected:
  unsigned char data[4]; //Testdaten: a b c d
}

class son : public father
{
 private:
  unsigned char data0; // Testdaten: x
  unsigned char data1; // Testdaten: y
  unsigned int data23; // Testdaten: 150
}

son Myson = new son();

Im Speicher wird für Myson dann folgendes abgebildet
... #1 #2 #3 #4 #5 #6 #7 #8 ...    // Speicheradresse
...  a  b  c  d  x  y  0  150 ...  // Daten

Jetzt ist meine Idee folgende:
Ein anderes Objekt "other" erwartet als Übergabe-Parameter "father" und 
verarbeitet die Daten in "data". Wenn ich jetzt "other" den "Myson" 
übergebe, akzeptiert der Compiler das ja ohne weiteres, meine Intention 
ist aber: data0,data1,data23 ist equivalent zu data[0], data[1], data[2] 
und data[3], es soll also tatsächlich derselbe Speicherbereich genutzt 
werden, da "other" völlig egal ist, was in "data" steht, es für mich 
aber leichter ist, die Menge an Bytes in bstimmte Variablen zu 
unterteilen. Das müsste dann also so aussehen, dass data[] auf data0 
zeigt, im Speicher würde dann nur noch stehen:

... #1 #2 #3 #4 #5 #6 #7 #8 ... // Speicheradresse
...  x  y  0  150 ...           // Daten

Ich hoffe es ist klar, was ich da möchte? Gibts da einen Königsweg einen 
bereits definierten Datenbereich zu "spezialisieren"?

Vielen Dank schonmal im Vorraus

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex Wurst wrote:

Die vernünftigste Lösung für dein Problem ist es, wenn
du deiner son Klasse ein paar Zugriffsunktionen verpasst
über die son auf das Array zugreifen kann. Da das Array
protected ist, ist das auch legal.

Alles andere ist Murks.
class father
{
 protected:
  unsigned char data[4]; //Testdaten: a b c d
};

class son : public father
{
  public:
      
  unsigned char& data0()   { return data[0]; }
  unsigned char& data1()   { return data[1]; }
  int&           data23()  { return *(int*)&data[2]; }
};

int main()
{
  son a;

  a.data23() = 5;
}

Autor: OliverSo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein alternativer Murks wäre eine entsprechende union in class father.

Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OliverSo wrote:
> Ein alternativer Murks wäre eine entsprechende union in class father.

Ich denke die Absicht hinter der Ableitung besteht darin dass
es irgendwann mal mehrer abgeleitete Klassen geben wird, die
den Byte Buffer verschieden interpretieren. Sowas kann man
zb. machen, wenn über eine Schnittstelle eine Message hereinkommt,
es verschiedene Message Typen gibt und sich der bytemässige Aufbau
je nach MessageTyp unterscheidet.

Mit einer union trägt man dann das Wissen über den unterschiedlichen
Aufbau aller Messages in die Basisklasse wo man es aber eigentlich
nicht haben möchte.

Autor: Alexander I. (daedalus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig erkannt, Karl-Heinz,
es handelt sich hier um eine Art Netzwerkprotokoll nach ISO/OSI-Modell 
und da ist sowas durchaus sinnvoll, denn ein PHY-Layer braucht nicht die 
Infos des MAC-Layers verarbeiten sondern diese nur als Payload 
weiterreichen. Lösung?

Autor: Alexander I. (daedalus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ah, habe den ersten Post übersehen. Ich schaus mir mal an, vielen Dank.

Autor: OliverSo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>es soll also tatsächlich derselbe Speicherbereich genutzt
>werden

Die Lösung per getter ist natürlich mit Abstand die sauberste, um die 
unterschiedlichen views auf die Daten zu erzeugen.

Allerdings nutzt das Beispiel oben nicht den SELBEN Speicherbereich - 
ein per new() oder statisch neu angelegter son hat einen eigenen 
Speicherbereich für die gererbte data-Struktur, und die müsste im 
Konstruktor, wie auch immer, noch gefüllt werden. (Dann könnte man die 
Daten auch gleich dort übersetzten).

Auf Zugriff auf den SELBEN Speicherbereich geht wohl nur per pointer, 
der dann kopiert werden muß. Das spart bei einer 4-byte-Datenstruktur 
aber nicht wirklich viel ein :-)

Oliver

Autor: Ingo Elsen (ogni42)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die beschriebene Anwendung klingt aber nicht nach Vererbung 
("ist-ein-Beziehung") denn ein PHY-Layer-Objekt ist kein 
MAC-Layer-Objekt. Beide zeigen nur eine Sicht auf bzw. einen Ausschnitt 
eines Datum.

IMHO würde daher besser ein Objekt für das Netzwerkdatum passen. Die 
einzelnen Layer-Objekte haben evtl eine gemeinsame Basisklasse, die 
gemeinsame Informationen bereitstellt (z.B. Layername, ...) und 
Zugriffsmethoden, die die entsprechenden Daten bereitstellen.

Autor: Alexander I. (daedalus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

die Layer-Objekte verarbeiten verschiedene Datumsobjekte. Ums mal 
korrekt auszudrücken: MAC-Layer "ist ein" PHY-Layer, greift also auf die 
Funktionen von PHY zu und kapselt diese nach Außen hin. Der PHY-Layer 
soll lediglich mit Datenobjekten vom Typ "Container" arbeiten können, 
also im Endeffekt einen Menge an Bytes die übertragen werden, mit nahezu 
keinen Steuerdaten. Der MAC-Layer dagegen kann auch Datenobjekte vom Typ 
"Frame" verarbeiten und teilt dem PHY-Layer mit Hilfe der Headerdaten 
mit, was dieser zu tun hat (Hardware-Adressierung, Datenrate, etc.), 
übergibt diesem die Daten aber indem er sie zuvor zu einem "Container" 
castet.

Es bleiben ja nach wie vor dieselben Daten, nur einmal als Menge an 
Bytes betrachtet und einmal als Datenpaket mit interpretierbarem 
MAC-Header.

Das PHY/MAC-Gedöhns ist schon implementiert, funktioniert auch und kann 
3 Wochen vor Diplomarbeitsabgabe nicht mehr großartig geändert werden ;)

Es geht mir also nur um die Darstellung von denselben Daten aus 
unterschiedlichen Perspektiven. Es können natürlich zum gleichen 
Zeitpunkt mehrere Container/Mac-Objekte existieren, die aber in 
verschiedenen Speicherbereichen liegen, wobei aber zusammengehörender 
Container und MAC-Frame dieselben Datenbytes enthalten, also auch 
denselben Speicherbereuch nutzen.

Viele Pointer möchte ich nach Möglichkeit verhindern, denn dann habe ich 
ja nahezu keine Speicherersparnis, da die einzelnen Datenelemente nur 
1-4 Byte groß sind.

Autor: OliverSo (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn du tatsächlich die Daten nur einmal im Speicher haben willst, dann 
solltest du auch beachten, wie dein Compiler Daten im Speicher anordnet. 
Ein Compiler legt, abhängig von der Zielarchitektur, sowas wie
char data0; char data1; int data23;
 nicht in aufeinanderfolgende Bytes, sondern z.B. jede Variable auf eine 
gerade Adresse. Um man das zu verhindern, gibt es entsprechende 
Compilerdirectiven. Näheres sollte die Compiler-Doku enthalten.

Oliver

Autor: 6636 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alex,
wenn du den Speicher ein paar Pointer nicht hast, so ist C++ 
moeglicherweise uebertrieben. Wie hat man's frueher gemacht : Globaler 
Speicher, ein Array, und man uebergibt einen Index. Der Rest sind 
Schulbeispiele.

Autor: Unbekannter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist doch hier alles Murks.

> Es bleiben ja nach wie vor dieselben Daten, nur einmal als Menge an
> Bytes betrachtet und einmal als Datenpaket mit interpretierbarem
> MAC-Header.

Das ist der entscheidende Punkt:

  Verschiede Sichten auf ein und den selben Datenblock!


> Das PHY/MAC-Gedöhns ist schon implementiert, funktioniert auch und
> kann 3 Wochen vor Diplomarbeitsabgabe nicht mehr großartig geändert
> werden

Gut, dann gibt den Schrott eben ab. Aber nicht über die schlechte 
Bewertung jammern.

Autor: Alexander I. (daedalus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe die Sache jetzt gelöst wie Karl-Heinz es vorgeschlagen hat, 
funktioniert prima und verbraucht nur unwesentlich mehr ROM als meine 
vorherige Lösung.

@Unbekannter:
Ganz großes Kino! Mach es doch einfach besser und bring einen 
konstruktiven Vorschlag. Wer soll mit so einem sinnlosen Kommentar denn 
was anfangen?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.