Eventhandler

[RolfD]

@roy-sam
nicht ganz...dazu schaust Du dir am besten aus den RP6Libs die Funktion:

void BUMPERS_stateChanged_DUMMY(void){}
static void (*BUMPERS_stateChangedHandler)(void) = BUMPERS_stateChanged_DUMMY;
/**
 * Use this function to set the Bumpers state change handler. 
 * 
 */
void BUMPERS_setStateChangedHandler(void (*bumperHandler)(void)) 
{
    BUMPERS_stateChangedHandler = bumperHandler;
}

an. Dort wird der Zeiger der übergebenden Funktion bumpersStateChanged als Sprungziel eingetragen so das diese später in:

void task_Bumpers(void)
{
    if(bumper_timer > 50) { // 50ms
        uint8_t left = getBumperLeft();
        uint8_t right = getBumperRight();
        if(bumper_left != left || bumper_right != right) {
            bumper_left = left;
            bumper_right = right;
            BUMPERS_stateChangedHandler();
        }
        bumper_timer = 0;
    }
}

angesprungen werden kann. Denn bumpersStateChanged wird ja vorher als Sprungziel gesetzt und dann angesprungen. Man könnte so wärend des Programmlaufes auch eine andere Funktion als Sprungziel ersetzen (Zeiger verbiegen sagt man dann), es ist damit quasi ein "dynamisches" Sprungziel und kein statisches wie es fest eincompiliert wäre. Das Konzept kann ansich weit mehr, so kann man z.B. Sprungtabellen und verschachtelte Eventhandler usw. anlegen, Eventhandler in Listen zu Laufzeit hinzufügen und löschen, das geht bis hin zu komplexer mehrdimensionaler Zeigerarithmetik was in der RP6 Software jedoch alles kaum bis garnicht genutzt wird. In Windows und Unix, also eigentlich in allen Multitasking Umgebungen wird dies z.B. recht excessiv z.B. beim Taskswitch genutzt und geht schon fast in Richtung "selbstmodifizierender Code".
Siehe auch: http://de.wikipedia.org/wiki/Selbstmodifizierender_Code
Umgangssprachlich stimmt deine Aussage so aber die Kompexität dahinter ist doch etwas umfangreicher. Wobei es eigentlich nicht mal komplex ist - die sich damit bietenden Möglichkeiten machen die Kompexizität und Leistungsfähigkeit aus. Das will ich mit dem Beitrag auch aufzeigen. Das Anspringen von Zeigern bzw. Zeigerarithmetik macht eines der wichtigsten Sprachkonstrukte von C aus bzw. hebt C deutlich von (ursprünglichen) Basic Dialekten und anderen Sprachen ab weshalb es zuweilen auch als "mächtig" und "systemnah" bezeichnet wird.
Man muss halt nur höllisch aufpassen das man nicht irgendwo in die Pampa springt/greift, weil man z.B. vergessen hat ein Zeiger zu initialisieren. Da es falsch verwendet aber sehr fehlerträchtig und extrem schlecht zu debuggen (Laufzeit) ist, überantwortet man Zeigerarithmetik auch gern der Programmiersprache (z.B. C++), was oft zu suboptimalen Ergebnissen und aufgeblasenem Code im Vergleich zu C führt. In manchen Fällen nimmt man es aber auch einfach als selbstverständlich hin, z.B. bei char Arrays .. besser bekannt als Strings, C kennt allerdings auch so komplexe Dinge wie Zeiger auf mehrdimensionale Zeigerarrays... z.B. als Binärbäume in komplexen Funktionen wie huffman/lzw, Hash-, Such- und Sortierfunktionen, Kryptographie...
Hier z.B. ein sehr interssantes Script zum Lernen von Zeigern in allen Variationen.
http://www2.hs-fulda.de/~klingebiel/c-vorlesung/teil7/index.htm
Das Wissen um Zeiger betrifft auch Aspekte wie Stack- und Speicherverbrauch, "call by reference" im Gegensatz zu "call by Value" und daraus resultierendes Laufzeitverhalten/Problemen usw. usw. usw. bis hin zu "überladen von Funktionen" aus C++ was man damit auch in C nachbilden kann, aber eben nicht zwangsläufig zu besserem Code führt...
Compilerwarnings betreffen oft Fehler in der Zeigerhandhabung weshalb man sie auch wirklich ernst nehmen sollte. Schreibt man auf ein fehlerhaften Zeiger und liest wieder ein, kann durchaus ein korrekter Wert dabei raus kommen, evtl. hat man sich bei der Aktion aber was anderes überschrieben, es kann aber auch von anderen Programmteilen überschrieben worden sein. Überschriebene Sprungadressen sind natürlich besonders gemein weil im Gegensatz zu großen Prozessoren keine MMU und/oder Supervisor Modi im Prozessor vorhanden sind, die sowas abfangen/verhindern.

Auf Maschinenebene sind einfache Zeiger eine Form der indirekten Addressierung in 2 Schritten, also quasi "lade Register A mit Zeiger" und "lade in Register B den _Inhalt_ der Speicherzelle, auf die Register A damit _zeigt_". Das erlaubt auch ein einfaches incrementieren des Zeigers A und damit ein durchlaufen des Speichers z.B. bei Strings. Anderes Beispiel, man kann ein String als "by Value" übergeben, dann läge der String aber im Stack was je nach Länge garnicht gut wäre. Übergibt man ihn "by Reference" als Zeiger wie üblich, wird lediglich der _Zeiger_ auf String im Stack übergeben, der String selbst liegt dazu irgendwo unbeweglich im Speicher. Zeiger haben eine feste Größe egal wie komplex die Datenstruktur ist, auf die sie zeigen. Das macht ein call by ref meist deutlich schneller als ein call by val, allerdings wird bei by val eine Copie der Var auf dem Stack angelegt was ggf. ausdrücklich gewünscht ist (z.B. Recursion), schutz vor Seiteneffekten. Es gibt dabei also kein "besser" oder "schlechter" sondern es kommt auf die richtige und durchdachte Verwendung an.
Eine praxisnahe Anwendung des Wissens ist z.B. neben Strings auch writeString_P und writeString aus den RP6Libs wobei das z.B. eher in Richtung von Neumann/Harvard Architektur geht. http://de.wikipedia.org/wiki/Harvard-Architektur

Grundwissen über Zeiger ist in C essentiell wichtig, allerdings auch nicht ganz einfach.

LG Rolf