Vabbè, quell'errore era banale.
Il punto non era che il tuo codice non funziona. (a parte quello che secondo me è ub)
Il punto è che ha side effects.
Mantiene uno stato.
Il risultato non dipende solo dai parametri passati
Esempio:
Supponiamo di trovarci in ambiente concorrente (questo ovviamente non è c++, ma un pseudolinguaggio):
Supponendo di conoscere p1, p2 e che cout sia sincronizzato in modo da dare un output prevedibile (al più si scambia l'ordine delle righe),codice:double zero = 0.0; spawn {cout << media(p1, 4, zero) << endl;} spawn {cout << media(p2, 4, zero) << endl;}
sai dirmi l'output?
Il tuo codice è antieducativo. Inoltre mantenere uno stato esterno già di per sé va contro i principi della programmazione "funzionale".
Aggiungo che mentre le mie due implementazioni (corrette a meno di un .voto) sono ottimizzabili in un ciclo in quanto ricorsive in coda (tail recursive), la tua non lo è e si mangerà lo stack.
Insomma, ci sono molti buoni motivi per evitare un implementazione simile. Sicuramente un professore che cerca di insegnare a pensare ricorsivamente la considererebbe errata (a livello pratico).
In sostanza la tua implementazione non da nessun vantaggio ma da molti problemi.
La mia di certo non da vantaggi rispetto a un'implementazione nativa con un for, ma non da neanche problemi. (sarebbe trascurabile anche il "mangiarsi lo stack" a livello educativo, ma non il resto)
Rispondi quotando