La conversione di un metodo C ++ in una funzione C con un argomento puntatore è un modello accettabile?

Uso C ++ su ESP-32. Quando si registra un timer devo fare questo:

timer_args.callback = reinterpret_cast<esp_timer_cb_t>(&SoundMixer::soundCallback);
timer_args.arg = this;

Qui il timer chiama soundCallback.

E la stessa cosa quando si registra un'attività:

xTaskCreate(reinterpret_cast<TaskFunction_t>(&SoundProviderTask::taskProviderCode), "SProvTask", stackSize, this, 10, &taskHandle);

Quindi il metodo viene avviato in un'attività separata.

GCC mi avvisa sempre di queste conversioni, ma funziona esattamente come previsto.

È accettabile nel codice di produzione? C'è un modo migliore per farlo?

A reinterpret_castè sempre sospetto a meno che tu non sappia esattamente cosa stai facendo. Qui, il tuo codice funziona solo a causa della convenzione di chiamata di GCC per i metodi C ++, ma questo ha un forte odore di comportamento indefinito. In particolare, non si deve supporre che le funzioni membro siano in alcun modo compatibili con i normali puntatori a funzioni.

L'approccio usuale sarebbe invece definire una funzione C-compatibile con la firma appropriata, che chiama internamente il metodo C ++. Per esempio:

extern "C" static void my_timer_callback(void* arg) {
  static_cast<SoundMixer*>(arg)->soundCallback();
}

Questo cast va bene perché stiamo eseguendo il backback da void*a al tipo di oggetto puntato.

Dettagli:

• extern "C"specifica il collegamento linguistico di questa funzione. Il collegamento linguistico influisce sulla modifica del nome e sulla convenzione di chiamata della funzione. Le funzioni membro non possono avere un collegamento in linguaggio C. Il collegamento linguistico è in gran parte ortogonale al collegamento interno / esterno.

• Per un callback la funzione può essere "privata", ovvero avere un collegamento interno. Il codice C non fa mai riferimento al callback per nome. Lo snippet di codice sopra specificato specifica il collegamento interno tramite la staticparola chiave (non un metodo statico!). In alternativa, la funzione potrebbe essere stata inserita in uno spazio dei nomi anonimo.

  Non sono del tutto sicuro delle interazioni tra extern "C"e static(collegamento interno). Ad esempio, [dcl.link]afferma che "Tutti i tipi di funzione, i nomi delle funzioni con collegamento esterno e i nomi delle variabili con collegamento esterno hanno un collegamento di linguaggio". Interpreto questo in modo che il tipo di my_timer_callbackabbia un collegamento di linguaggio C, ma il suo nome di funzione no.

• A static_castè appropriato qui perché conosciamo il tipo reale di argma non possiamo esprimerlo all'interno del sistema dei tipi. Al contrario, a reinterpret_castè appropriato quando vogliamo reinterpretare un modello di bit, ad esempio un puntatore a un tipo numerico.

• Le funzioni non sono oggetti ordinari e le funzioni membro lo sono ancora meno. È possibile reinterpretare il cast tra i tipi di puntatori a funzione purché la funzione sia invocata solo attraverso il suo tipo reale (e analogamente per i puntatori a funzioni membro). Se è possibile eseguire il cast di puntatori di funzioni ad altri tipi (ad es. Puntatori di oggetti o puntatori vuoti) è definito dall'implementazione ( sfondo ). Su POSIX esegue il cast tra i puntatori a funzione e void*sono consentiti in modo che dlsym()possano funzionare. Gli altri cast che coinvolgono i puntatori di funzione (membro) non sono definiti. In particolare, i cast tra le funzioni membro e i puntatori a funzione non sono possibili.

Personalmente, l'approccio più compatibile, facile da implementare e da capire che ho trovato è quello di fornire una funzione "wrapper", compatibile con l'interfaccia C prevista, che chiama internamente il metodo (e, nel caso in cui non sia statico, creare un'istanza o utilizzare un'istanza esistente per farlo). Potrebbe essere visto come una sorta di variazione del modello di progettazione dell'adattatore.