Newsgroup: it.comp.lang.c++
Titolo: Accesso a membri privati

Ciao a tutti!
Un'altra domandina a bruciapelo:
class MyClass {
  int a;  
  class MyNestedClass1 { /* accede a MyClass::a */ };
public:
  class MyNestedClass2 { /* accede a MyClass::a */ };
};
Che io sappia... o almeno cosi' sapevo e cosi' ho letto nella presentazione di
gcc3.0, MyNestedClass1 e MyNestedClass2 possono accedere liberamente
ai membri di MyClass (MyClass::a), in quanto essi stessi membri di MyClass,
giusto?
Invece gcc2.95.2 mi dice che provo ad accedere illegalmente a dati privati...
ricordo che il fatto che gcc3.0 accettasse tale tipo di accesso fu segnalato
come bug al team di sviluppo, il quale controbatte', standard alla mano,
segnalando che si trattava invece di una cosa perfettamente legale...
Purtroppo (maledetta la carta di credito che non ho!) come sapete non ho
una copia dello standard... voi vi trovate in linea col team di gcc3.0,
o con i segnalatori di bug ;-) ?
Ciao e grazie!!
Domenico
-- 
Domenico Barra, Brainbench C++ Master
ba...@programmazione.it
domb...@studenti.unina.it
dob...@iol.it

 o con i segnalatori di bug ;-) ?
Ti stava arrivando un regalo ma babbo natale dice che non riesce
a trovare il tuo indirizzo.... 
Ciao
Gaetano
-- 
Posted from 
nts-03.mm.eutelsat.org
 [194.214.173.15] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 stessi membri di MyClass, giusto?
per quel che so io non e' vero. Il fatto che le classi sia nested e' 
solo una questione di visibilita', ma non implica che esse siano anche 
friend della classe "madre".
ciao Anto
-- 
Antonio Cuni, 19 anni, studente
Brainbench C++ Master: 4.6, higher than 98% of all previous test takers.
C Language: 3.32, higher than 79% of all previous test takers.
Guida C/C++ di Programmazione.it: 
http://cpp.programmazione.it

friend della classe "madre".
[da 
gcc.gnu.org/bugs.html#known
 ]
Non Bugs
Nested classes can access private types of the containing
class.
G++ now implements type access control on member types. Defect
report 45 clarifies that nested classes are members of the class they
are nested in, and so are granted access to private members of that
class.
[end]
purtroppo non sono ancora riuscito a beccare quel benedetto
Defect Report... non so piu' a chi prestare fede... nel frattempo
continuo a cercare, faro' avere mie notizie :-)
Ciao


 Domenico
http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/cwg_defects.html#45
Non e' ancora ufficialmente parte dello standard, ma da sicuramente ragione 
al team di GCC.
Ciao, 
Alberto Griggio

a trovare il tuo indirizzo.... 
E se a Babbo Natale dicessi: "What about me?" :-)
P.
-- 
   	 ___      ___  __       ___       ___ ___  ___
	/__/ /	 /__/ /   //_/ /__  /__/ /__ /__  /__/
       /__/ /__ /  / /__ // / ___/ /  / /__ /__  /
 
 
http://theunixplace.com/~entropia/index.html
 
Obviously welcome removing Anti-spam filters to contact me in email :-)

 a trovare il tuo indirizzo....
Azz. Il mio funziona. Mandala a me la carta di credito :-)
--
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

 non so piu' a chi prestare fede...
allo standard:
  11.8  Nested classes                               [class.access.nest]
1 The  members of a nested class have no special access to members of an
  enclosing class, nor to classes or functions that have granted friend-
  ship   to   an   enclosing  class;  the  usual  access  rules  (clause
  _class.access_) shall be obeyed.  The members of  an  enclosing  class
  have  no special access to members of a nested class; the usual access
  rules (clause _class.access_) shall be obeyed.


 wrote in message
news:6a8dcd75.01122...@posting.google.com...

Non è ancora stato discusso e NON da affatto ragione al team di GCC se
questo sostiene che una classe nestata può accedere ai membri della
classe che la contiene. Lo standard parla molto chiaro nel dire
esattamente l'opposto e il defect report parla semplicemente di un'altra
cosa.


 dall'ereditarietà fra le due.
Sì, è come dici... anche se la soluzione proposta (se adottata dallo 
standard) darebbe pienamente ragione a gcc3.0.
Ciao
Domenico
-- 
Domenico Barra
Brainbench C++ Master
ba...@programmazione.it

della classe contenuta da parte della classe contenente.
E questa cosa chi dovrebbe facilitare ?
Questo e' secondo me un punto su cui riflettere.
Io sono convinto che una nested class spesso esiste
come dettaglio implementativo della classe che la
dichiara oppure ne integra comunque l'interfaccia.
Chi scrive il codice della nested class sicuramente
conosce tutti gli internals della classe base e
spesso ha anche bisogno di accedervi.
Io troverei perfettamente sensato anche l'eliminazione di
questa barriera tuttosommato artificiosa che semplicemente
obbliga spesso ad aggiungere una friendship.
Andrea

 wrote in message
3c31f6f...@news.interbusiness.it...

Mi dispiace ma non sono affatto d'accordo. Lo stesso Stroustrup nel suo
libro afferma che le classi sono utili soprattutto per realizzare tipi
snelli ed efficaci. Cioè si ha spesso a che fare con classi che non
implementano magari nulla di complesso ma che comunque sfruttano da un punto
di vista logico l'incapsulamento dei dati. Perchè rompere questo
incapsulamento? Hai bisogno di accedere ai dettagli implementativi?
Benissimo: usa una struct... è stata messa apposta!!!!! :)

Benissimo: usa una struct... è stata messa apposta!!!!! :)
Punti di vista. Io credo che nello specifico caso delle
nested class (non si parlava delle classi in genere) la cosa
sia di solo impaccio e crea problemi invece di risolverli.
Fra l'altro esiste un altro problema... Supponi che esista
la classe A che dichiara una classe B come friend. Se nella
classe B mi trovo a dover definire delle nested class per
dettagli implementativi non ho modo di trasferire i permessi
di accesso ad A a queste nested class.
Anche in questo caso, visto che le nested class si assumono
essere sotto il diretto controllo di chi realizza la classe
in cui sono definite, le regole di protezione sono solo di
impaccio visto che neanche con friend si riesce a risolvere
il problema. Se infatti A dichiara che B e' sua friend e B
dichiara che la nested class B::B2 e' sua friend la nested
class B::B2 non potra' accedere ai membri privati di A.
Lo stesso accade se si considera anche la protezione
"protected"; non ci sara' modo di accedere a membri protected
di A da B::B2 a meno di dire che anche B::B2 deriva da A
(cosa priva di senso).
Io credo che per le nested class le regole andrebbero
cambiate. Fra l'altro sarebbe anche un cambiamento
relativamente indolore... il codice che prima compilava
continuerebbe a compilare senza problemi...
Andrea
PS:
  Perche' usare solo 'R:' per la risposta ???

   Perche' usare solo 'R:' per la risposta ???
Perchè Emiliano usa una vecchia versione di Outlook che non genera
automaticamente messaggi conformi allo standard delle News. Quindi o
Emiliano si ricorda di correggere a mano tutte le volte la R: in Re:
oppure installa la patch per Outlook che lo fa automaticamente.


 Basta una ulteriore friend.
Ma dal momento che esiste gia' una relazione stretta tra B e le sue
classi innestate, perche' non sfruttarle?
 
Ciao,
Nicola

 soluzione inferiore a far convivere classi in un namespace comune.
Stai mettendo in discussione una decisione che è ben chiara nello
standard. Come facevo rilevare lo standard va bene come è (nel senso che
non è errato o ambiguo) anche se una differente decisione in tal senso
potrebbe essere eventualmente discussa per una successiva versione dello
standard.
In altre parole: allo stato attuale lo standard esiste ed è pubblicato.
Può essere modificato durante la mantainance per risolvere ambiguità e/o
correggere errori. Questo non significa "cambiare lo standard" ma solo
"mantenerlo". Non voglio entrare più di tanto nel merito dell'utilità o
meno di una modifica come quella proposta. Mi limito a dire che la
decisione presa dal comitao a suo tempo non è quella. Discutibile?
Forse. Ma non lo è. E stando a come è definito ora il linguaggio una
classe nestata non è un membro. Stando così le cose i due principali
casi in cui nestare una classe ha un qualche senso sono perfettamente
gestibili. Che poi, cambiando la filosofia soggiacente a questa
decisione, si possano aprire delle strade all'uso di classi nestate
anche in altre situazioni, è anche possibile. Ma non stiamo più parlando
di C++ (inteso per come è definito ora il linguaggio).


ora il linguaggio).
E chi dice nulla ? Io ho solo detto che, secondo me, togliere
questa "privatezza" rispetto alle nested class non sarebbe
un problema, anzi semplificherebbe l'uso senza danneggiare
nessuno ed eviterebbe alcune delle rogne di questo tipo di
coerenza formale del linguaggio.
Credo fra l'altro che sia un punto discusso spesso quando
si parla di C++0x. Forse quelli di g++ 3.0 sono effettivamente
solo un po' in anticipo sui tempi.
Andrea

 solo un po' in anticipo sui tempi.
Parlarne in ambito C++0x è appropriato. Implementare un compilatore nel
presupposto che una data feature sia presente in C++0x non è appropriato
se questa feature contrasta con l'attuale definizione del linguaggio (a
meno che non la rendi opzionale via switch, ma a questo punto il tuo
compilatore opportunamente istruito via switch di compilazione può anche
compilarti il fortran).


compilarti il fortran).
Nel caso specifico io trovo anche decisamente meno
grave il compilare cose che non si dovrebbero
compilare piuttosto che il contrario.
Chiaro che il massimo e' compilare *tutto e solo*
il compilabile ma in questo caso evidentemente
quelli del gruppo del g++ hanno deciso che le
regole fossero troppo assurde (e forse esiste anche
uno switch del tipo --strict-pedantic-and-brain-damaged
che permette anche di rispettare le regole del
documento quando queste sono senza senso...)
Andrea

dati statici o implementazioni non inline).
Il mio livello di attenzione e' troppo basso alla
mattina per potermi permettere il lusso di rispondere
in un newsgroup ... La mia frase voleva essere:
  Forse ti riferisci al passaggio in cui si dice
  che una classe nested in una classe locale e'
  una classe locale. Questo pero' significa solo
  che quella classe e' *anche* locale e che quindi
  ha tutte le limitazioni delle classi locali (ad
  esempio rispetto ai template e alla possibilita'
  di definire dati statici o implementazioni non
  inline).
Mi scuso di questo e degli altri strafalcioni
sintattici ... spero pero' che il resto del
messaggio fosse comprensibile.
Da parte mia prometto di non rispondere piu' in
un newsgroup prima di aver bevuto il caffe'
della mattina... :)
Andrea