avr-g++: Zugriff auf Pseudoobjekt per extern

[A. N. (netbandit)]

Hallo,

ich habe in C++ einige Hardwarezugriffe auf einen AtMega128 in Klassen 
verteilt. Diese Klassen enthalten nur Methoden und keine Daten. Leider 
ist es so, dass unter C++ jede Klasse, auch dann wenn Sie praktisch 
keine Daten enthält, mindestens 1 Byte im Speicher belegt (um Objekte 
dieser Klasse in einem Array unterscheiden zu können).

Das mag auf einem PC sicher weniger schlimm sein, aber auf einem µC sehe 
ich es absolut nicht ein, pro Klasse ein Byte spendieren zu müssen, 
obwohl die Klasse nur Methoden zur besseren Strukturierung und 
Abstraktion der Hardware enthalten. Vor allem bei einer etwas größeren 
Verschachtelung dieser führt das schnell zu viel Speicherverbrauch der 
theoretisch gar nicht nötig ist.

Also habe ich ausprobiert, anstatt ein Objekt dieser Hardware-Klasse 
anzulegen einfach ein Objekt über "extern" zu deklarieren. Dieses Objekt 
wird allerdings in keiner anderen später gelinkten Datei wirklich 
definiert. Ich sage dem Compiler also: "Hey da gibt es ein Objekt, ich 
weiß nicht wo, aber es sieht so und so aus."

Siehe da, ich habe auf alle Methoden dieser Klasse Zugriff und auch auf 
die Methoden der Unterklassen und das ohne, dass Speicherplatz dafür 
reserviert werden muss.

Die Frage die sich nun stellt: Ist dies eher ein schmutziger Workaround 
im avr-g++ oder, der womöglich in späteren Versionen nicht mehr 
funktionieren wird oder ist so etwas in C++ grundsätzlich zulässig und 
kann dann auch so verwendet werden?

Beispielcode:

class CTest {
  public:
    void tudies (void) {
      return;
    }
};

extern CTest T;

void main(void) {

  T.tudies();

  while (1) {
  }
  return;
}

[P. S. (Gast)]

Du koenntest auch NULL auf den Klassentyp casten und darueber zugreifen 
- aber das ist genauso Pfusch ;-)

Was du eigentlich willst, ist, die Methoden als static deklarieren und 
sie dann per KlassenName::MethodenName( ) aufrufen.

Oder du machst das mit Namespaces und Funktionen - so viele Namespaces, 
wie du dann braeuchtest, wuerde ich aber nicht einsetzen wollen.

Btw, geschweifte Klammern gehoeren IMO uebereinander - sie markieren 
Anfang und Ende eines Blocks und sollten den Block leicht erkennbar 
machen.

[A. N. (netbandit)]

Hallo Peter,

die Idee mit dem Pointer ist eigentlich super. Das dürfte auch auf 
andere Compiler übertragbar sein und ist absolut kein Problem solange 
eben kein Speicherzugriff stattfindet.
Bei dem "extern" Trick besteht halt noch der Vorteil, dass der Linker 
meckert sobald ein Speicherzugriff stattfindet, weil er dann die 
dazugehörige Speicherstelle nicht finden kann.

Ich habe das gerade mal beim Visual C++ 2008 Compiler ausprobiert: Die 
extern-Variante nimmt er nicht (Linker kann das Symbol nicht finden), 
die mit dem Null-Pointer schon.

Die Variante mit dem static geht nicht, da in der Klasse weitere Klassen 
(ohne Daten-Member)geschachtelt sind. Diese "objekte" müssten dann auch 
static sein und würden in diesem Moment ebenfalls ja 1 Byte belegen. Ich 
hätte also nur das eine Byte der obersten Klasse gespart.

Namespace funktioniert nicht, da es sich um Templateklassen handelt und 
eine solche Funktionalität meiner Meinung nach nicht mit Namespaces 
nachgestellt werden kann.

Und das mit den Klammern ist eben Ansichtssache ;-)

[P. S. (Gast)]

Ich denke ich habe dich verstanden - aber so richtig begeistern tut es 
mich nicht ;-)

[A. N. (netbandit)]

Ja begeistern tun mich beide Lösungen auch nicht. Die eine scheint nicht 
portierbar zu sein und wer weiß wie es mit der nächsten Version des 
avr-g++ aussieht. Die andere ist zwar portierbar birgt aber das Risiko 
auf einen ungewollten Speicherzugriff (falls man aus Versehen doch mal 
ein Datenelement in einer der Klassen definiert).

Das leere Klassen immer ein Byte groß sind ist ja eine reine 
Definitionssache des Compilers um eventuelle andere Probleme umgehen zu 
können.

Mir wäre es am liebsten, wenn man den Compiler anweisen könnte für 
solche Klassen keinen sinnlosen Speicher zu reservieren. Das sind 
immerhin einige etliche Byte die effektiv nicht genutzt werden... *Kopf 
schüttel*

[yalu (Gast)]

Peter Stegemann schrieb:
> Was du eigentlich willst, ist, die Methoden als static deklarieren und
> sie dann per KlassenName::MethodenName( ) aufrufen.

Genau, so hätte ich's auch gemacht. Ein Objekt von einer leeren Klasse
zu instanziieren verwirrt doch mehr als es nützt. Der Compiler sollte
das nicht mit 1 Byte bestrafen, sondern mit 1 GByte ;-)

A. N. schrieb:
> Die Variante mit dem static geht nicht, da in der Klasse weitere
> Klassen (ohne Daten-Member)geschachtelt sind.

Das verstehe ich nicht. Man kann doch wunderbar Methoden auch in
verschachtelten Klassen aufrufen:

class A {
  public:
    class B {
      public:
        static void mb() {}
    };
    static void ma() { B::mb(); }
};

int main() {
  A::ma();
  A::B::mb();
  return 0;
}

[A. N. (netbandit)]

Naja, ganz so simpel ist die Struktur dahinter nicht. Das ganze 
entspricht eher diesem Beispiel hier und da sehe ich keine Möglichkeit 
ohne "Pseudoobjekt" sinnvoll auf die Methoden zugreifen zu können.

template<uint8_t N>
class A {
  public:
    static void ma() {
      // mach was mit N
      return;
    }
};

class B {
  public:
    A<0> a0;
    A<1> a1;
    A<2> a2;
    A<3> a3;
    A<4> a4;
    A<5> a5;
    static void mb() {
      return;
    }
};

[yalu (Gast)]

Also möchtest du eher so etwas:

#include <iostream>
#include <stdint.h>

template<uint8_t N>
class A {
  public:
    static void ma() {
      std::cout << "Ich gehöre zur Klasse A<" <<(int)N << ">." << std::endl;
      return;
    }
};

class B {
  public:
    typedef A<0> A0;
    typedef A<1> A1;
    typedef A<2> A2;
    typedef A<3> A3;
    typedef A<4> A4;
    typedef A<5> A5;
    static void mb() {
      A4::ma();
      // oder gleich so, dann können die obigen Typedefs enfallen:
      A<4>::ma();
      return;
    }
};

int main() {
  B::mb();
  A<5>::ma();
  B::A5::ma();
  return 0;
}

Nicht? Wie sieht denn ein typischer Methodenaufruf bei dir aus? Ich kann
mir im Moment keinen Fall vorstellen, wo man leere Objekte wirklich
bräuchte.

[A. N. (netbandit)]

Die Idee mit den typedefs ist sehr gut, so werde ich es wohl machen... 
Danke yalu!

Nun zu deiner Frage: Wenn die eigentliche Variation der Klassen nicht in 
Datenobjekten stecken sondern im Templateparameter N, dann besitzt die 
Klasse keine Datenobjekte sondern nur Methoden, es ist also eine leere 
Klasse.

[yalu (Gast)]

> ... es ist also eine leere Klasse.

Dass Klassen ohne Datenelemente sinnvoll sein können, ist schon klar.
Ich kann mir nur nicht vorstellen, dass es Fälle gibt, wo es sinnvoll
oder sogar notwendig ist, von solchen Klassen Objekte zu instanziieren,
da ein Objekt ohne Daten meiner Meinung nach nicht mehr ist/kann als
seine Klasse.

Nachdem du die "Wegoptimierung" der Objekte a0 bis a5 durch die Typedefs
akzeptiert hast, hat sich das Thema aber wohl weitgehend erledigt.

[A. N. (netbandit)]

Naja, es ist eben der nächste logische Schritt: Man programmiert eine 
Klasse mit all seinen Methoden und um diese zu benutzen legt man eben 
ein Objekt dieser an. Der einzige Grund, warum man das nicht machen kann 
ist doch die Definition in den C++ Standard, dass jedes Objekt 
mindestens ein Byte groß ist, auch wenn dieses gar nicht im Speicher 
existiert da es keinen Speicher belegt. Wäre das nicht so definiert, 
dann spräche doch nichts dagegen mit leeren Klassen genauso zu verfahren 
als wie mit vollen Klassen.

Ich meine das sieht ja auch im Quellcode komisch aus, wenn man auf die 
einen Methoden über den "." Operator zugreift und auf andere Methoden 
über ein "::". Dem Programmierer, der am Ende mit den Klassen umgehen 
muss, ist es doch egal ob da Daten drin gespeichert werden und daher 
Objekte angelegt werden müssen oder ob es leere Klassen sind, die daher 
ohne Objekte verwendet werden.

Das verletzt ja auch das Prinzip der Kapselung: Einmal ein Projekt mit 
solchen Klassen realisiert, kann ich mich nicht mehr im Nachhinein 
entscheiden doch noch ein Datenobjekt in eine der Klassen zu 
integrieren, dann müsste man nämlich doch wieder ein Objekt dieser einen 
Klasse anlegen und damit den ganzen Quellcode umbauen. Könnte man 
ungestraft ein Objekt einer leeren Klasse anlegen, dann wäre das gar 
kein Thema. Aber was soll man machen... Standard ist Standard.

Danke nochmal für deine Lösung... manchmal sind die einfachsten 
Varianten die auf die man gar nicht kommt.

[A. N. (netbandit)]

Oh, ich merke gerade, dass ich das doch nicht so realisieren kann. Ich 
nutze in den Klassen sehr massiv überladene Operatoren und die dürfen 
nicht static sein.

Also bleibt nichts anderes übrig als doch mit einem Pseudoobjekt zu 
arbeiten.