c++ static methoden

[Olaf (Gast)]

Ich glaube ich brauche mal etwas nachhilfe in C++. :-)

Es geht um diese Umgebung hier, aber ich denke das ist nicht so wichtig:
https://circle-rpi.readthedocs.io/en/44.3/

Ich will mir eine Klasse schreiben mit der ich ueber SPI ein Display
ansteuern kann. Das ist auch kein Problem, bekomme ich hin.

Dort werde ich je nach bedarf Pixel in einem Framebuffer setzen.

Dann will eine Methode haben die 100x pro Sekunde aufgerufen wird und 
eventuelle Aenderungen des Framebuffers an das Display rausschreibt.

Es gibt bereits eine Funktion die meine Methode aufrufen kann:
void CTimer::RegisterPeriodicHandler(TPeriodicTimerHandler *pHandler)

Der kann ich eine Methode uebergeben welche dann vom System aufgerufen 
wird.

Soweit so gut. Leider muss diese Methode aber static definiert sein. 
Damit hab ich in der Methode aber z.B keinen Zugriff mehr auf meine SPI 
Klasse.

Wie loest man sowas normalerweise?

Olaf

[Klaus W. (mfgkw)]

Du brauchst von der Klasse hoffentlich nur ein Objekt?
Dann muß die static-Methode dieses Objekt nehmen und darüber eine 
Methode aufrufen, die dann auf die Interna des Objekts zugreifen kann.
Evtl. muß die static-Methode vor dem Zugriff testen, ob das Objekt 
initialisiert ist und noch nicht wieder aufgelöst.


Wenn du mehrere Objekte brauchst, müsste man sich ein Handle oder sowas 
für jedes Objekt definieren (im einfachsten Fall ein Zeiger auf das 
Objekt), um die Objekte zu unterscheiden.


PS: evtl. wäre es ja aber auch eine Lösung, eine entsprechende Logik in 
deine Klasse einzubauen, also etwas wie 
CTimer::RegisterPeriodicHandler() in deiner Klasse.
Dann hätte sich das Problem erledigt.

[Olaf (Gast)]

> Dann muß die static-Methode dieses Objekt nehmen und darüber eine
> Methode aufrufen, die dann auf die Interna des Objekts zugreifen kann.

Das verstehe ich nicht. Ich kann ja aus der static methode nicht auf die 
anderen Methoden diese Klasse zugreifen. Das ist ja gerade mein Problem.

Olaf

[Programmierer (Gast)]

Von deinem Code heraus gibt es keine saubere Möglichkeit das zu lösen. 
Der Autor von Circle hat da gepennt, und halt nur einen Funktionszeiger 
vorgesehen, obwohl es eine C++-Library ist. Eine einfache und klassische 
Möglichkeit das zu lösen wäre es, den Funktionszeiger durch eine 
abstrakte Klasse mit Callback zu ersetzen. Im Anhang ein kleiner Patch, 
mit dem man das in Circle nachrüsten könnte.

Du kannst damit dann deine Display-Klasse von CPeriodicTimerHandler 
ableiten, eine Member-Funktion

virtual void onTimer () override;

 hinzufügen, und den Timer einfach mit

timer.RegisterPeriodicHandler(this);

 registrieren. Deine onTimer-Funktion wird dann als Callback verwendet.

[Klaus W. (mfgkw)]

Olaf schrieb:
> Das verstehe ich nicht. Ich kann ja aus der static methode nicht auf die
> anderen Methoden diese Klasse zugreifen. Das ist ja gerade mein Problem.

So etwa hatte ich das gemeint:

#include <iostream>


// Typ der callback-Funktion:
typedef void(TPeriodicTimerHandler)(void);

namespace CTimer
{
  void RegisterPeriodicHandler(TPeriodicTimerHandler *pHandler)
  {
    std::cout << "registriere irgendwas..., pHandler=" << (void*)pHandler << std::endl;
    // hier könnte ein Thread gestartet werden, der regelmäßig
    // pHandler() aufruft...

    // Testweise rufe ich die callback einmal auf:
    (*pHandler)();
  }
}


class MeineKlasse;
MeineKlasse     *p_globalesObjekt = nullptr;


class MeineKlasse
{
public:
  MeineKlasse( int wert )
    : wert( wert )
    , initialisiert( false )
  {
    // alles intialisieren, was nötig ist...

    // zum Schluß markieren, daß ich ein vollwertiges Mitglied der
    // Gesellschaft bin:
    initialisiert = true;
  }

  ~MeineKlasse()
  {
    initialisiert = false;
  }

  // Methode, die internes Zeug braucht:
  void tuwas()
  {
    std::cout << "tuwas(): wert ist " << wert << std::endl;
  }

  // statische Methode, die als callback funktioniert, aber nicht
  // internes kennt (weil static):
  // Muß TPeriodicTimerHandler entsprechen.
  static void staticTuwas()
  {
    // Weil tuwas() nur mit einem Objekt aufgerufen werden kann, muß
    // die static-Methode dieses globale Objekt kennen.

    if( p_globalesObjekt && p_globalesObjekt->istInitialisiert() )
    {
      p_globalesObjekt->tuwas();
    }
    else
    {
      std::cerr << "staticTuwas(): kein globales Objekt..." << std::endl;
    }
  }

  bool istInitialisiert()
  {
    return initialisiert;
  }

private:

  int      wert;

  bool     initialisiert;
};


int main( int nargs, char **args )
{
  // Objekt erzeugen:
  p_globalesObjekt = new MeineKlasse( 42 );

  // call back registrieren:
  CTimer::RegisterPeriodicHandler( &MeineKlasse::staticTuwas );

  // irgendwas fleißig arbeiten...

  // Aufräumen:
  delete p_globalesObjekt; p_globalesObjekt = nullptr;
}

MeineKlasse::staticTuwas() ist eine statische Methode, die man an 
CTimer::RegisterPeriodicHandler() übergeben kann.
Die kennt nicht die Interna eines Objekts.
Sie kann aber über den Zeiger auf ein Objekt zugreifen, und darüber dann 
tuwas() aufrufen - das macht wiederum die eigentliche Arbeit.

Das Gedöns mit initialisiert braucht man nur, wenn wegen Multithreading 
oder Interrupts der Ablauf unklar wird.
Weiß man, daß die callback nur aufgerufen wird, solange das Objekt 
vollständig ist, kann man sich das natürlich sparen.

Das ist bei mir kompilierbar und tut, was ich erwarte:

registriere irgendwas..., pHandler=0x55c7495053ee
tuwas(): wert ist 42

[Programmierer (Gast)]

Wenn "MeineKlasse" aber auf diese globale Variable zugreift, kann man 
sich auch gleich sparen hier eine Klasse umzusetzen, man kann dann 
sowieso nicht mehrere Instanzen davon anlegen. Wenn schon kann man eine 
freie Hilfsfunktion anlegen welche den Aufruf an die globale Instanz 
weiterleitet, sodass wenigstens die Klasse selbst von diesem Hack 
unberührt bleibt.

[Tom (Gast)]

Weniger gruselig-javaesk als der TPeriodicTimerHandler aus dem diff und 
viel flexibler wäre std::function, wenn man nicht auf antike 
C++-Standards angewiesen ist.

Wenn CTimer unverändert bleiben muss, wird es hässlich.

Wenn die eine statische Methode nicht ausreicht (bei mehreren Instanzen) 
und die Gesamtanzahl der Callbacks überschaubar und begrenzt ist, wäre 
die Variante im Anhang mit einer Adapter-Klasse, die einen Vorrat an 
statischen Methoden hat, eine Möglichkeit.

[Programmierer (Gast)]

Tom schrieb:
> Weniger gruselig-javaesk als der TPeriodicTimerHandler aus dem diff und
> viel flexibler wäre std::function, wenn man nicht auf antike
> C++-Standards angewiesen ist.

Naja, Java hat das von C++ übernommen, also ist das eher 
Oldschool-C++-esk. std::function hat den Nachteil, dynamischen Speicher 
zu brauchen. Es gibt auch Embedded-kompatible Varianten mit begrenztem 
fixem Speicher. Das benutzt intern allerdings auch virtuelle Funktionen 
;-)

[Klaus W. (mfgkw)]

Programmierer schrieb:
> Wenn "MeineKlasse" aber auf diese globale Variable zugreift, kann man
> sich auch gleich sparen hier eine Klasse umzusetzen, man kann dann
> sowieso nicht mehrere Instanzen davon anlegen.

War die Vorgabe des TO:
Klasse und eine statische Methode, die registriert werden kann.

Ich sagte oben schon: wenn man mehrere Objekte braucht, müsste man sie 
mit Handles o.ä. auseinanderhalten.
Aber er will ein Display ansteuern damit. EIN Display.

Programmierer schrieb:
> Wenn schon kann man eine
> freie Hilfsfunktion anlegen welche den Aufruf an die globale Instanz
> weiterleitet, sodass wenigstens die Klasse selbst von diesem Hack
> unberührt bleibt.

Kann man, ja.
Ob man eine statische Methode macht oder stattdessen eine Funktion 
außerhalb, ist technisch dasselbe. Er wollte eine statische Methode 
haben...

[Olaf (Gast)]

Okay, anstatt hier zu lesen, hab ich die letzte Stunde mein Gehirn
angestrengt und selber was gemacht. Allerdings qualmt jetzt mein Gehirn. 
:-)

Ich stell es mal zur diskussion:

st7735.h

  void Ticker(void);
  static void WrapTicker(void);

st7735.cpp

void *ST7735Pointer;

void ST7735::Initialize(void)
{                                                        
  my_Timer->RegisterPeriodicHandler(WrapTicker);
}

void ST7735::WrapTicker(void)
{
    ST7735 *ich = (ST7735*) ST7735Pointer;
    ich->Ticker();
}

void ST7735::Ticker(void)
{
  static u8 TxData[10];
  u8 RxBuffer[10];

  TxData[0] = TxData[0] +1;

  //Übertragen eines Bytes                                                             
  my_SPIMaster->WriteRead (SPI_CHIP_SELECT, TxData, RxBuffer, 1);

}

kernel.cpp

  extern void *ST7735Pointer;
  lowlcd  = new ST7735(&m_Logger, &m_Timer);  ST7735Pointer = (void*) lowlcd;

Fühlt sich ein bisschen so an als würde man die Idee von c++ ermorden,
aber funktioniert. :-D
Die Idee den Source von circle zu ueberarbeiten war mir auch schon 
gekommen,
ist aber bloed wenn man dann irgendwann auf eine neuere Version updatet
und alles wieder kaputt ist.

Olaf

[Oliver S. (oliverso)]

Olaf schrieb:
> Fühlt sich ein bisschen so an als würde man die Idee von c++ ermorden,
> aber funktioniert. :-D

Na ja, das ist halt der Preis, den man für ein Legacy C-Style-Interface 
beim Timer zahlt. Wäre das ein anständiges templatebasiertes 
C++-Callback-Interface, wärs halt mehr C++.

Oliver

[Klaus W. (mfgkw)]

Olaf schrieb:
> (void*)

Darf man gerne vermeiden, wenn möglich.

[tut nix zur Sache (Gast)]

Mein Vorschlag (kombiniert mehrere obige Vorschläge + P-IMPL):

///////
// Timer.h

class ITimer
{
public:
   virtual ~ITimer() {}
   virtual void onUpdate() = 0;
};


class Timer : public ITimer
{
   class Timer_Private* m_private;

public:
   Timer();
   ~Timer();

   void onUpdate() override;
}


////////
// Timer.cpp

// static adapter class
static class Timer_Private
{
  ITimer* m_timer;
public:
  Timer_Private( ITimer & timer )
  : m_timer( &timer )
  {
    CTimer::RegisterPeriodicHandler( &Timer_Private::onUpdate );
  }

  static void onUpdate()
  {
    if( nullptr != m_timer )
    {
      m_timer.onUpdate();
    }
  }

} sTimerPrivate;


//
Timer::Timer()
: m_private( &sTimerPrivate )
{
}


-> ist zwar aktuell auf 1 Timer-Objekt beschränkt, lässt sich aber mit 
nem ITimer*-Array in Timer_Private erweitern bzw. darin auch 
hinsichtlich Update-Raten filtern. z.B. dass der bei

CTimer::RegisterPeriodicHandler( &Timer_Private::onUpdate );

registriete statische Handler alle 100ms gepollt wird und dort noch mal 
auf x Sekunden erweitert werden kann.