Newsgroup: it.comp.lang.c++
Titolo: protected (era: Re: Quale linguaggio? x programmare?)

 l'inventore del linguaggio.
A dire il vero non e' che lo abbia mai usato granchč...
...ma perche' dovrebbe essere un errore l' aver inserito
il protected?
Quali svantaggi comporta?
x-post e follow up su it.comp.lang.c++
--
Gerolamo

 Quali svantaggi comporta?
Probabilmente gli stessi apportati dai costrutti che un linguaggio presenta
per motivi apparentemente utili, ma praticamente superflui...
ciao
--
Luigi
Web Site: 
http://web.tiscali.it/luigi_web
E-mail: 
cybe...@email.it
ICQ #46240443

 Quali svantaggi comporta?
A mio avviso il problema non e' tanto il protected in quanto tale,
quanto il fatto che e' un sintomo dell'abuso dell'ereditarieta' che
viene spesso compiuto in C++, anche quando esistono costrutti piu'
adatti.
Ciao,
Nicola

il protected?
Secondo Stroustrup l'uso di protected rende troppo facile accedere
tramite derivazione ai dettagli di una classe che dovrebbero invece
essere nascosti, ed il suo uso non é quindi ritenuto da lui sicuro.
Il Ghenio
---------
// TODO: Place your ass here

 adatti.
concordo. Io non sono un "tifoso" di protected (si vive anche senza) ma 
non sono neppure sulla posizione di chi dice che sarebbe meglio non 
averlo a disposizione.
In generale si dice che protected e` inutile perche` "se ha senso dare 
l'accesso alle classi derivate allora dovrebbe avere senso anche darlo a 
tutti", o, viceversa, "se non vuoi dare l'accesso al pubblico allora non 
devi darlo neppure alle derivate".
Bisogna pero` considerare che in alcuni casi il programmatore potrebbe 
preferire non "inquinare" troppo l'interfaccia pubblica inserendo dei 
metodi che agli utenti "normali" non sono utili.
Senza contare che la presenza di protected permette di implementare 
alcuni utili idiomi; ad esempio:
class Base {
protected:
        Base();
        ~Base();
};
class Derived: public Base {
...
};
nell'esempio sopra Base e` una finta-astratta: non e` possibile 
utilizzarla se non come classe base ma non si deve portare dietro il 
"peso" della VTABLE (e il distruttore protected garantisce di non 
cozzare contro l'undefined behaviour per la mancanza di un distruttore 
virtuale). Un comportamento del genere puo` essere utile in varie 
situazioni e non c'e` modo di ottenerlo senza protected.
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.73, higher than 99% of all previous test takers.
C Language: 3.79, higher than 92% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

 essere nascosti, ed il suo uso non é quindi ritenuto da lui sicuro.
Questo mi fa venire in mente una cosa: io non ho obbiezioni al
dichiarare funzioni membro protected; quello che secondo me non bisogna
mai fare e' dichiarare protected i membri dato.
Ciao,
Nicola

mai fare e' dichiarare protected i membri dato.
Non sono completamente d'accordo: il tutto deriva da scelte
progettuali,e sinceramente ci sono dei casi in cui alcuni dati membro
possono essere tranquillamente resi protected per permettere alle
classi derivate di poterli liberamente utilizzare.
A mio avviso le critiche di Stroustrup, a volte un pň esagerate,
riguardano soprattutto i possibili abusi dell'uso di protected da
parte di progettisti di classi che principalmente vogliono rendersi la
vita piů facile quando derivano una classe da un altra, ma in tal modo
finiscono per violare i principi della programmazione ad oggetti, che
vuole che certi dettagli debbano restare nascosti.


 classi derivate di poterli liberamente utilizzare.
Su questo non sono d'accordo, o perlomeno sono convinto che nella
stragrande maggioranza dei casi siano errori progettuali, derivati
dall'approccio "derivare per riusare" che mi pare tendenzialmente
fragile.
Ciao,
Nicola