mikrocontroller.net

Forum: Compiler & IDEs Spezialistenfrage: C++ Downcast


Autor: Janos B. (janos)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin nun schon einige Zeit dabei eine C++ Library zur umfassenden 
MIDI-Fernsteuerung eines Kemper Profiling Amps (ein digitaler E-Gitarren 
Verstärker mit massig Funktionen die man steuern kann) zu entwickeln. 
Ich hole ganz kurz zu den Hintergründen aus bevor ich zur eigentlichen 
Programmierungsfrage komme um meine Überlegung verständlicher zu machen. 
Wer mag darf den Abschnitt auch überspringen ;)


--------- Die Hintergründe -----------------------

Die Library, welche ich programmiere ist so ausgelegt, dass sie mit 
nahezu vollständig gleicher API und gleichen Funktionen sowohl auf 
PC-Architekturen als auch auf Mikrocontrollern (aktuell nur mit dem 
Arduino-Framework - prinzipiell aber alles an Hardware mit UART-Port 
wofür es einen C++ Compiler gibt) läuft. Das erreiche ich, indem ich 
eine Cross-Plattform-fähige MIDI-Library entwickelt habe, welche 
wiederum mit vollständig gleicher API die MIDI-Kommunikation über die 
jeweilige Hardwareschnittstelle der Wahl realisiert, das ist z.B. für 
Arduino ein HardareSerial oder SofwareSerial, für MacOS ein 
CoreMIDI-basiertes USB-MIDI-Inferface, diverse weitere Implementierungen 
sind in Planung.

Das hat den Vorteil, dass die Arbeit von mir und vllt auch. der 
Community für mehrere Projekte auf völlig verschiedenen Plattformen 
genutzt werden kann und dass ich entspannt die Ansteuerung einzelner 
Features auf dem PC entwickeln und debuggen kann und diese durch den 
hübschen Hardware Abstraction Layer nahezu ohne Probleme auf Anhieb auch 
auf dem Mikrocontroller laufen.

Nebenbei ist die ganze Geschichte Header-Only gehalten, so dass ein 
einziges #include-Statement reicht um alles zum laufen und kompilieren 
zu bekommen!

Dabei achte ich stets auf möglichst mikrocontroller-freundlich 
gestalteten Code und muss relativ wenig Performance-Einbußen in Kauf 
nehmen.

Nun hat der Amp einen Haufen ansprechbarer Parameter, welche Funktionen 
von Effekten Steuern, die abhängig vom aktuell geladenen Preset sich 
möglicherweise in den 8 virtuellen Effektslots befinden. Ist nun aber 
ein bestimmter Effekt nicht geladen, geht ein Steuerbefehl an diesen 
Effekt in diesem Slot ins leere.

Da dies so viele Parameter sind, würde ich ungern in der Hauptklasse 
dafür jeweils eine eigene setter- und getter-Methode implementieren. 
Stattdessen fände ich es sehr angenehm, mir eine weitere 
Effekt-Basisklasse zu erstellen und viele Klassen für die jeweiligen 
spezifischen Effekttypen, welche von der Basisklasse erben und die 
Ansprache der jeweils relevanten Parameter abstrahieren. Dazu würde ich 
dann gerne in der Hauptklasse jeweils Methoden implementieren nach der 
Art
StompTypeA *getStompTypeAInstance()
welche mir in dem Fall, dass ein solcher Effekt im aktuellen Setup 
geladen ist einen Pointer auf die passende Instanz geben um diesen 
Effekt zu kontrollieren oder falls ein solcher Effekt nicht geladen ist, 
einen Nullpointer zurück geben.

Nach jeden Preset-Wechsel scanne ich eh einmal die Effekt-Slots durch, 
weiß also welche Effekte jeweils vorhanden sind. Wäre ich nun 
ausschließlich auf dem PC unterwegs, würde ich mir dann jeweils auf dem 
Heap eine Instanz der passenden Effekt-Klasse anlegen und gut wäre es. 
Nun will ich aber Mikrocontoller-kompatibel völlig ohne Heap auskommen, 
also möchte ich die Infos über die geladenen Effekte gerne in einem 8 
Felder großem Stack-Array ablegen. Dies hat mich nach längerem hin- und 
her überlegen zu folgender Idee getrieben:


--------------- Die eigentliche Frage: ------------------------

Ich habe eine Basisklasse und eine gewisse Anzahl an Klassen die davon 
erben. Konkret in dieser Art:
class StompBase {

public:

    /**
     * Will be called once in the constructor of the Amp class
     */
    void setFixedPropertiesPtr (NRPNPage slotPage, KemperProfilingAmp *amp) {
        this->slotPage = slotPage;
        this->amp = amp;
    }
    
    /**
     * Will be called after each rig update to set the stomp type in that stomp slot
     */
    void setStompType (StompType stompType) {
        this->stompType = stompType;
    }
    
    StompType getStompType() {
        return stompType;
    }

    /**
     * Should be overriden by derived class to determine if the assumed stomp is still present in that slot
     * @return 
     */
    virtual bool isStillValid() {return false; };

protected:
    StompType stompType = Empty;
    NRPNPage slotPage = PageUninitialized;
    KemperProfilingAmp *amp;
};


class WahStomp : public StompBase {

public:

    /**
     * Checks if there still is a Wah stomp in this slot
     */
    bool isStillValid() override {
        if ((stompType == StompType::Wah) && (slotPage != PageUninitialized)) {
            return true;
        }
        return false;
    }

    /**
     * Sets the Wah range parameter
     */
    void setRange (uint8_t range) {

        if ((amp->lastNRPNPage != slotPage) || (amp->lastNRPNParameter != WahRange)) {
            amp->setNewNRPNParameter (slotPage, WahRange);
        }

        amp->sendControlChange (119, range);
    }

    // ... and a lot more...
};

class PhaserVibeStomp : public StompBase {

public:

    /**
     * Checks if there still is a PhaserVibe stomp in this slot
     */
    bool isStillValid() override {
        if ((stompType == VintageChorus) && (slotPage != PageUninitialized)) {
            return true;
        }
        return false;
    }

    /**
     * Sets the PhaserVibe modPahserStages parameter
     */
    void setModPhaserStages (uint8_t modPhaserStages) {

        if ((amp->lastNRPNPage != slotPage) || (amp->lastNRPNParameter != ModPhaserStages)) {
            amp->setNewNRPNParameter (slotPage, ModPhaserStages);
        }

        amp->sendControlChange (119, modPhaserStages);
    }

    // ... and a lot more...
};

Nun bestehen alle Klassen die davon erben immer ausschließlich aus 
Member Funktionen und fügen der Klasse keine einzige Member Variable 
hinzu. Wenn ich mir das vorstelle, müsste doch nun das Speicher-Layout 
von StompBase und beliebigen davon abgeleiteten Klassen nach der oben 
beschriebenen Machart exakt gleich aussehen. Demnach müsste ein Downcast 
von
StompBase*
 z.B. zu
WahStomp*
 doch problemlos funktionieren. ODER? Genau an diesem Punkt bin ich mir 
nicht ganz sicher und hätte gerne etwas einblick von jemanden der ganz 
tief im Compiler-Thema drin sitzt und mir sagen kann ob das immer 
funktionieren wird.

Falls das nämlich funktioniert, würde ich in der Hauptklasse so etwas 
implementieren:
/**
 * This array gets updated with the stomp types after each rig change
 */
 StompBase stompsInCurrentRig[8];

/**
 * Returns a pointer to a WahStomp instance if one exists, returns a nullptr otherwise
 */
 WahStomp *getWahStompInstance() {
    for (int i = 0; i < 8; i++) {
        if (stompsInCurrentRig[i].getStompType() == StompType::Wah) {
           return (WahStomp*) &stompsInCurrentRig[i];
        }
    }

    return nullptr;
 }

Damit könnte ich das im oberen abschnitt beschriebene Ziel hübsch 
(zumindest nach Außen hin :D) erreichen und dabei völlig 
Mikrocontroller-kompatibel ausschließlich auf dem Stack unterwegs 
sein...

Falls jemand einen Vorschlag hat nach außen hin das gleiche zu erreichen 
ohne solch einen fiesen Downcast-Hack freue ich mich auch!

: Bearbeitet durch User
Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nein, das geht nicht, da die Klasse einen vtable-Pointer enthält, der 
nach deinem fiesen Cast aber nicht angepasst wurde. Es werden also immer 
nur die Basisklassen-Implementationen aller virtuellen Memberfunktionen 
aufgerufen.

Du könntest dir aber mal placement new ansehen. Damit kannst du aus 
einem bereits vorhandenen "rohen" Speicherblock (mit passendem 
Alignment) auf offiziellem Weg ein Objekt machen.

: Bearbeitet durch User
Autor: Janos B. (janos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antwort.

Rolf M. schrieb:
> Es werden also immer
> nur die Basisklassen-Implementationen aller virtuellen Memberfunktionen
> aufgerufen.

Bedeutet im Umkehrschluss, dass das gut ginge wenn ich mir in der 
Basisklasse die virtuelle Memberfunktion sparen würde und diese als 
gewöhnliche Member-Funktion in allen abgeleiteten Klassen nutzen würde?

Rolf M. schrieb:
> Du könntest dir aber mal placement new ansehen. Damit kannst du aus
> einem bereits vorhandenen "rohen" Speicherblock (mit passendem
> Alignment) auf offiziellem Weg ein Objekt machen.

Ah, das ist auch interessant, kannte ich noch nicht. Hab mir gerade mal 
oberflächlich ein paar Beispielcodeschnipsel angeschaut. Säh damit die 
Lösung vllt irgendwie so aus?
// Array to hold all stomps
StompBase stompMemory[8];

// I got the information that there is a Wah in stomp slot 5 so I add a Wah to stomp slot 5
WahStomp *newWahStomp = new ((void*) &stompMemory[4]) WahStomp;

/**
 * Returns a pointer to a WahStomp instance if one exists, returns a nullptr otherwise
 */
WahStomp *getWahStompInstance() {
    for (int i = 0; i < 8; i++) {
        if (stompsInCurrentRig[i].getStompType() == StompType::Wah) {
            return (WahStomp*) &stompsInCurrentRig[i];
        }
    }

    return nullptr;
}

Ich seh es richtig, dass es keinen Grund gibt delete aufzurufen bevor 
ich an den Platz ein neues Objekt anlege?

: Bearbeitet durch User
Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Janos B. schrieb:

> Ich seh es richtig, dass es keinen Grund gibt delete aufzurufen bevor
> ich an den Platz ein neues Objekt anlege?

Der Dtor sollte immer aufgerufen werden, könnte ja sein, dass er was 
tut.

Autor: Wilhelm M. (wimalopaan)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du nutzt ja das dynamische Binden gar nicht aus und machst keinen 
dynamic_cast, sondern einen pre-check anhand eines Members und dann 
einen static_cast.

Dann kannst Du einfach ein Array der immergleichen PODs anlegen (mit dem 
tag-Member) und dann damit ein Menge von überladenen Funktionen 
aufrufen. Das wäre m.E. einfacher.

Autor: BobbyX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anhand von dem was du schreibst und dem Code sehe ich, dass das was du 
machst ein sehr gutes Beispiel für Overengineering ist... ICh empfehle 
dir sich eine alte Version von SoundDiver von Emagic zu besorgen und zu 
sehen wie dort solche Dine gemacht wurden. In reinem C, aber 
mutliplatformfähig. Falls Du es nicht weisst: Emagic gehört heute zu 
Apple und die Leute von Emagic waren massgeblich an Entwicklung von 
CoreAudio beteiligt. Meiner Meinung nach die beste Audio/MIDI API die es 
gibt.

Mit deinem Ansatz kommen solche Monster wie der Editor vom Roland GR-55. 
Ich habe es mir mal angesehen. Ein Programm, dass ein bisschen MIDI hin 
ind her schiebt und im Idle-Zustand 10% Prozessorlast auf einem modernen 
PC eryeugt muss einfach schrott sein....

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.

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