Newsgroup: it.comp.lang.c++
Titolo: dichiarazione dei memri di dati

Linguaggio di programmazione: Visual C++ 6.0
Libreria: M.F.C.
S.O. Windows 98 SE
-------------------------------------------------------
Spettabile NG,
pensavo di aver capito tutto a riguardo della dichiarazione dei membri di
dati di una classe, ma un errore di questi giorni mi ha fatto rimettere
tutto in discussione. Potreste dirmi quali sono le differenze che
intercorrono fra la dichiarazione di un mebro di dati (all'interno di una
qualsiasi classe) come public, private, protected, friend ed extern? Per le
funzioni membro vale lo stesso discorso? Come si fa, inoltre, a dichiarare
un membro di dati globale per tutte le classi in modo tale che, modificando
il suo valore, tutte le funzioni di qualsiasi classe del workspace
riasalgano al suo effettivo valore?
Grazie mille
Sergio Mola
Sergio Mola

 wrote in message
news:3a7fd5ce.0@inetnews...

public: accedibile ovunque
private: accedibile solo da altri metodi della stessa classe o da
classi/funzioni friend
protected: come private ma accedibile anche da classi derivate
friend: vedi private e protected
extern: non si usa per i membri, solo per dati a livello di namespace
(intrinseco per le funzioni a livello namespace non statiche)
Per il tuo membro globale, se e' globale non e' un membro. Dichiara un oggetto
globale oppure dichiara un membro statico di una classe e deriva tutte le classi
da questa.
Andrea Ferro
---------
Brainbench C++ Master. Scored higher than 97% of previous takers
Scores: Overall 4.46, Conceptual 5.0, Problem-Solving 5.0
More info 
http://www.brainbench.com/transcript.jsp?pid=2522556

 Sergio
Saluti
/fabio
Sent via Deja.com
http://www.deja.com/

 puramente sintattico) dall'uso del C++ rispetto al C.
non sono del tutto d'accordo... non mi ricordo su quale numero di C++
Informer veniva fatto un esempio di utilizzo delle funzioni membro per
migliorare il data - hiding. Potresti ad esempio dichiarare una classe
con costruttore privato e permettere la creazione di istanze di quella
classe soltanto tramite una funzione o un'altra classe. Mi pareva anzi
che l'esempio fosse proprio una cosa simile.

 che l'esempio fosse proprio una cosa simile.
Si. Infatti i friend del C++, se usati nel modo corretto, possono permettere un
hiding ancora piu' potente di quello nativo al C++ stesso.
Ma, IMHO, stiamo facendo dei ragionamenti "al limite". Ovvero, se spingiamo
l'hiding al suo estremo, quasi nessun linguaggio o paradigma ci permette poi una
rappresentazione "chiara e lineare" di quello che vogliamo fare. Pero' un
linguaggio abbastanza potente (o un paradigma abbastaza flessibile) ci
permettono di "ottenere lo stesso risultato in un altro modo".
In ogni caso "l'altro modo" probabilmente risultera', per un motivo o per
l'altro, "macchinoso" rispetto alla struttura generale.
Nel caso del C++ questo significa "aggirare il meccanismo di hiding principale"
(anche se con lo scopo di ottenere un maggior hiding). Ed e' corretto dire che
questo specifico "aggiramento" (friends) non e' OO.
Just MHO (mi sa che sto diventando prudente dopo la scivolata del const :-)


 che l'esempio fosse proprio una cosa simile.
Si, mi pare di ricordare il numero al quale ti riferisci. In effetti non mi
sembra questo il caso (almeno dal modo in cui è stato esposto da Sergio)
quanto invece come minimo un errore di design, dato che le due classi
vengono accoppiate addirittura sulla conoscenza dell'implementazione della
struttura dati (array di stringhe), mentre al limite delle funzioni di
accesso avrebbero risolto il problema. (ma ripeto qui ci deve essere un
errore di design).
--
----------
Lello Mele
HOMEPAGE:
http://www.lellomele.supereva.it
eMAIL:
v...@libero.it

 errore di design).
probabilmente (anzi, sicuramente) nel caso particolare hai ragione tu.
Il punto è che non è il fatto che ci sia friend o meno a rovinare il
meccanismo di data hiding, ma è l'errato design che forza una
soluzione anomala. Io penso non ci sia niente di male nel meccanismo
delle classi e funzioni friend, tutto lì. Dal tuo post mi sembrava di
leggere una affermazione del tipo: "friend è male", ed è secondo me
una affermazione errata.
i miei 0,02 euro.

 questo specifico "aggiramento" (friends) non e' OO.
per me no, non lo aggiro ma lo rafforzo. Non penso ci sia un
meccanismo di hiding principale ed uno secondario truffaldino, ci sono
un insieme di costrutti che mi permettono il data hiding, uno, quello
delle classi, che se vogliamo č quello piů semplice da utilizzare, ma
anche friend, che deve essere usato con accortezza, ma puň permettere
di rafforzare il meccanismo di data hiding.
i miei 0,02 euro

 lineare, non ci vedo niente di molto macchinoso.
In OO, dichiari pubblicamente solo l'interfaccia di Fumo, ma non la sua
implementazione. E nell'interfaccia (che tra l'altro e' una classe astratta) NON
metti i costruttori.
L'implementazione di Fumo poi la metti nel .cpp che implementa motore e la vedi
solo ed esclusivamente li.


 una affermazione errata.
Come dire "goto e' male" o "break e' male" o "continue e' male".
O anche come dire "la polvere da sparo e' male".
Sono strumenti. Dipende tutto da come li usi.


 una affermazione errata.
Impossibile! avrei detto un stro**ata enorme. friend non solo *non* è male,
ma addirittura è *necessario* in molti contesti (p.e. per implementare
l'overloading degli operatori + o -, ecc.). Poi sono stato io a suggerire
l'uso di una classe friend al Sergio Mola (leggi bene i miei post prima :-).
Io parlavo dello strano motivo per il quale gli serve violare l'information
hiding fra le classi X e Y.


 solo ed esclusivamente li.
non ho capito una mazza.. ci penso un po' su e poi ti rispondo ;o)

 hiding fra le classi X e Y.
è vero, scusami. Prometto che d'ora in poi prima mi leggerò bene tutti
i post, è che avevo poco tempo. Non si ripeterà =o)

 Come dire "goto e' male" o "break e' male" o "continue e' male".
aahh, finalmente un altro non-integralista anti-goto! Mi č capitato
spesso di sentire gente che appena vedevano un goto in un sorgente c++
automaticamente classificava il codice 'm***a'. Anche su questo NG, x
essere onesti.

Gia'. Per contro in quasi vent'anni di informatica non ho mai sentito il
bisogno di usare un goto in un linguaggio strutturato e mi e' stato
presentato un solo esempio nel quale il goto era indispensabile per
garantire prestazioni ragionevoli ad una funzione. Ed anche in quel caso
piu' che di un vero goto si trattava di un "break" (secondo l'autore del
codice non vi e' differenza sostanziale). 
Il punto non e' "goto non si deve usare", quanto rendersi conto che
l'impulso di usarlo e' un probabile sintomo che qualcosa non va. E'
opportuno esaminare la situazione con particolare attenzione, e se e' il
caso procedere col goto.
In ogni caso mi pare difficile che questo avvenga, se non in fase di
ottimizzazione.
Ciao,
Nicola

 ottimizzazione.
se io fossi davvero in fase di ottimizzazione spinta, farei produrre
al compilatore il codice assembly, e poi modificherei quello.
Purtroppo, finora non ne ho ancora avuto bisogno.

 ottimizzazione.
se io fossi davvero in fase di ottimizzazione spinta, farei produrre
