[C++] attributi di class che sono puntatori a funzioni membro della classe

[Zero-Giulio]

Allora, immaginiamo che io abbia una classe con 3 funzioni membro private e una funzione membro pubblica.
Immaginiamo che il costruttore di classe riceva in input un parametro.

Quello che io vorrei fare è questo: far si che la funzione pubblica sia una delle tre funzioni private; in particolare il costruttore, in base al parametro che riceve, deve decidere qualce delle tre funzioni usare.

Forse si chiarisce meglio con un esempio.

    class calendar {

        typedef bool (calendar:: * memberFunctionPtr) (const date &) const;

        public:

            calendar (const int & i) {
                switch (i) {
                    case 0:
                        isHolidayPtr = &calendar::target1;
                    break;
                    default:
                        isHolidayPtr = &calendar::target2;
                }
            }

            bool isHoliday (const date & d) const {
                return ((*this).*isHolidayPtr) (d);
            }

            memberFunctionPtr isHolidayPtr;

        private:

            bool target1 (const date & d) const {
                return false;
            }

            bool target2 (const date & d) const {
                return true;
            }

};

Non so se il codice è chiaro...
Cmq, la filosofia è questa: la classe calendar deve avere una funzione membro pubblica isHoliday. Questa funzione isHoliday, a seconda delle circostanze (nell'esempio di sopra lo switch ha solo due casi, ma in realtà a me ne servono circa una trentina), deve fare cose diverse.
Cioè in alcuni casi isHoliday deve fare quello che fa target1, in altri casi deve fare quello che fa target2 ecc...

Il nocciolo è che, per motivi di efficienza, NON voglio mettere lo switch dentro la funzione isHoliday (perchè altrimenti devo testare mille mila condizioni ogni volta che entro in isHoliday (cioè molto di frequente).
Io lo switch lo voglio fare SOLO una volta (nel costruttore).

Da un punto di vista teorico credo che i puntatori a funzioni siano la soluzione ideale per le mie esigenze.

Il problema nasce dal fatto che con le funzioni membro l'uso dei puntatori a funzione è più complicato.

Naturalmente ho googlato tanto in giro per riuscire a fare quello che avevo in mente, e il risultato è il codice che vi ho postato sopra.

Il codice compila e sembra funzionare a dovere.

Il motivo per cui posto qui è sostanzialmente dovuto al fatto che ho scritto diverse righe di codice che non comprendo. Non ho una conoscenza così buona del C++ e in particolare non mi è chiaro perchè:
1) il typedef sia necessario
2) perchè la riga dell'assegnamento del puntatore

isHolidayPtr = &calendar::target2

voglia il & e il risolutore dello scope calendar::
3) sopratutto non mi è chiara la riga:

((*this).*isHolidayPtr) (d);

perchè devo scirvere (*this).* ??? Io in una classe non sono abituato a scrivere cose tipo (*this).
In genere è sottointeso. Non so se mi sono spiegato.

Cmq, senza allungare troppo questo post.

Quello che vi chiedo è:
1) esiste secondo voi un modo più intelligente per raggiungere il mio scopo? (senza puntatori a funzioni membro)
2) esiste un modo più elegante e conciso di scrivere quello che io ho scritto sopra? (per esempio, come afccio a togliere il *this?)

Grazie :-)

Quello che io vi domando, a questo

[tomminno]

Hai appena cercato di riprodurre un comportamento tipico dell'ereditarietà. Secondo me la soluzione migliore è un Factory con le 2 classi che derivano da una interfaccia (o eventualmente da una classe base) ognuna che definisce il proprio isHoliday.

Per quanto riguarda i tuoi dubbi su (*this).*isHolidayPtr è decisamente un modo verboso per scrivere (this->*isHolidayPtr)

[Zero-Giulio]

Ah si, ci avevo pensato a creare una classe che ereditava da calendar le funzioni base.

Il motivo per cui non l'ho fatto è questo: in realtà di puntatori a funzioni me ne servono tre: uno deve scegliere la funzione da puntare tra 5, uno deve sceglierla tra 8 e infine l'ultimo deve sceglierla tra circa una trentina.

Sono tre funzioni che fanno cose diverse e che tutte dovrei inizializzarle in fase di costruzione dell'oggetto.

Se mi dessi all'ereditarietà, correggimi se sbaglio, dovrei creare 5*8*30 classi.

Una alternativa sarebbe stata l'ereditarietà unita con la composizione, cioè creare 3 classi distinte (ognuno con 5, 8 o 30 sottoclassi) e poi fare il calendario come unione di questi.

Non so, all'inizio mi sembrava poco elegante come soluzione, perchè i tre oggetti sono intimamente collegati tra loro e sono collegati anche ad altre classi (tipo la date).

Dovrei quindi riempire il codice di friend (la relazione friend non viene ereditata dai figli, vero?). Ma proprio tante. Sia tra di loro che con date e affini.

Cmq, il punto è che credevo più diretto l'uso di puntatori a funzione.

In C li usavo spesso ed erano comodi ed eleganti.
Non sapevo che per usarli con metodi di una classe le cose si complicassero.

A questo punto potrei rivalutare la scelta.
Boh, tu cosa mi consigli di fare?

Il codice vorrei che fosse leggibile. Le performance rimangono la priorità assoluta, ma siccome su questo codice dovrebbero lavorarci anche altri (non informatici però), dovrebbe eanche essere un minimo chiaro.

Cmq, ipotizzando di non cambiare idea e di continuare a usare i puntatori a funzioni membro (come il codice che ho postato), noti qualche imperfezione? Qualche riga scritta in modo pedante?

this->

è più veloce di

(*this).

?
Oppure sono solo due modi diversi di dire la stessa cosa al compilatore e poi in codice macchina si equivalgono?

[tomminno]

Originariamente inviato da Zero-Giulio

Ah si, ci avevo pensato a creare una classe che ereditava da calendar le funzioni base.

Il motivo per cui non l'ho fatto è questo: in realtà di puntatori a funzioni me ne servono tre: uno deve scegliere la funzione da puntare tra 5, uno deve sceglierla tra 8 e infine l'ultimo deve sceglierla tra circa una trentina.

Io mi riferivo al codice che hai postato.
Altri casi vanno visti in dettaglio, forse rivedendo il design più che l'implementazione.

A questo punto potrei rivalutare la scelta.
Boh, tu cosa mi consigli di fare?

Nel caso che hai postato è più "elegante" la soluzione con ereditarietà.

Il codice vorrei che fosse leggibile. Le performance rimangono la priorità assoluta, ma siccome su questo codice dovrebbero lavorarci anche altri (non informatici però), dovrebbe eanche essere un minimo chiaro.

Parli di performance, ma per quale architettura stai sviuppando?
Il design che hai approntato te è molto stile C, poi è facile che a forza di metterci le mani tutto si riconduca più a codice procedurale che altro, insomma il solito C con le classi (vedo tutti i giorni codice C# che viene scritto come se fosse C, da gente che il C non sa neanche cosa sia )

Cmq, ipotizzando di non cambiare idea e di continuare a usare i puntatori a funzioni membro (come il codice che ho postato), noti qualche imperfezione? Qualche riga scritta in modo pedante?

this->

è più veloce di

(*this).

?

Oppure sono solo due modi diversi di dire la stessa cosa al compilatore e poi in codice macchina si equivalgono?

Sono assolutamente identiche, il compilatore li traduce nello stesso codice, sono solo 2 modi per scrivere la stessa cosa.
Se stai guardando i puntatori a metodo e non vuoi sobbarcarti librerie come Boost, io darei un'occhiata a FastDelegate, sono 2 header che ti consentono di utilizzare in maniera molto semplice i puntatori a metodo.