Devo smettere di usare classi/interfacce di base astratte e usare invece boost :: function/std :: function?

Question

Ho appena saputo cosa è veramente la std :: function e per cosa è usata e ho una domanda: ora che abbiamo essenzialmente delegati, dove e quando dovremmo usare Abstract Base Classes e quando, invece, dovrebbe implementare il polimorfismo tramite gli oggetti std :: function inseriti in una classe generica? ABC ha avuto un colpo fatale in C++ 11?

Personalmente la mia esperienza fino ad ora è che il passaggio di delegati è molto più semplice da programmare rispetto alla creazione di più classi ereditate ognuna per un comportamento particolare ... quindi sono un po 'confuso quanto utile saranno le basi astratte d'ora in poi.

Answer 1

Preferisco ben interfacce definite nel corso callback

Il problema con std::function (precedentemente boost::function) è che la maggior parte del tempo è necessario disporre di un callback a un metodo di classe, e quindi hanno bisogno di legarsi this per l'oggetto funzione. Tuttavia nel codice chiamante, non hai modo di sapere se this è ancora in circolazione. In effetti, non si ha idea che ci sia anche un this perché bind ha modellato la firma della funzione chiamante in ciò che richiede il chiamante.

Ciò può causare naturalmente arresti anomali quando il callback tenta di attivare metodi per classi che non esistono più.

È possibile, naturalmente, utilizzare shared_from_this e associare un shared_ptr a un callback, ma l'istanza potrebbe non andare mai via. La persona che ha una richiamata ora partecipa alla tua proprietà senza che nemmeno loro ne siano a conoscenza. Probabilmente vuoi una proprietà e una distruzione più prevedibili.

Un altro problema, anche se è possibile ottenere il callback per funzionare correttamente, è con callback, il codice può essere troppo disaccoppiato. Le relazioni tra gli oggetti possono essere così difficili da accertare che la leggibilità del codice diminuisca. Le interfacce, tuttavia, forniscono un buon compromesso tra un livello appropriato di disaccoppiamento con un rapporto chiaramente specificato come definito dal contratto dell'interfaccia. Puoi anche specificare più chiaramente, in questa relazione, problemi come chi possiede chi, ordine di distruzione, ecc.

Un ulteriore problema con std::function è che molti debugger non li supportano bene. In VS2008 e potenzia le funzioni, devi passare circa 7 livelli per arrivare alla tua funzione. Anche se tutte le altre cose sono uguali, una callback è stata la scelta migliore, la semplice seccatura e il tempo sprecato accidentalmente a scavalcare l'obiettivo di std::function è una ragione sufficiente per evitarlo. L'ereditarietà è una caratteristica fondamentale del linguaggio e il passaggio a un metodo sovrascritto di un'interfaccia è istantaneo.

Infine aggiungerò solo non abbiamo delegati in C++. I delegati in C# sono una parte fondamentale del linguaggio, proprio come l'ereditarietà è in C++ e C#. Abbiamo una funzionalità di libreria std che IMO è un livello rimosso da una funzionalità di base del linguaggio. Quindi non sarà così strettamente integrato con altre caratteristiche fondamentali del linguaggio. Aiuta invece a formalizzare l'idea di oggetti funzione che sono stati un linguaggio C++ per un bel po 'di tempo.

Answer 2

Non vedo come si possa giungere alla conclusione che i puntatori di funzione rendono obsolete le classi base astratte.

Una classe, incapsula metodi e dati che si riferiscono ad esso.

Un puntatore a funzione è un puntatore a funzione. Non ha idea di un oggetto incapsulante, conosce solo i parametri passati ad esso.

Quando scriviamo le classi, stiamo descrivendo oggetti ben definiti.

I puntatori di funzione sono ottimi per un buon numero di cose, ma cambiare il comportamento di un oggetto non è necessariamente il pubblico di destinazione (anche se ammetto che potrebbero esserci delle volte in cui si vorrebbe farlo, ad esempio richiamate, come Doug.T cita).

Si prega di non confondere i due.