Newsgroup: it.comp.lang.c++
Titolo: Referendum: é una porkata fare una struct dentro una classe?

Rispondete in tanti!

 Rispondete in tanti!
 ?????
no, non e' un "porcata" !
Alex

"Alex" <nom...@bow.wow> ha scritto nel messaggio
news:Y%H_6.6299$z11.4...@news.infostrada.it...

se si, perche'?
se no, perche'?
ad esempio il mio PM dice che non e' molto bello.
Myszka

 ad esempio il mio PM dice che non e' molto bello.
Il Pubblico Ministero? Non credevo che certe dispute finissero in
tribunale.
Ad ogni modo, sono curioso: non è bello perchè usi 'struct' invece di
'class' o non è bello perchè definisci una struct/class *dentro* una
classe?
Max

Non è bello scrivere come attributo di una class una satruct


Ciao Max,
la seconda che hai detto.
Non penso che sia una legge, cmq.
M

Rispondete in tanti!
c'č chi sostiene che l'uso delle STRUCT debba essere quanto piů
possibile evitato nell'uso del C++ in quanto ciň che si puň
incapsulare in una struct lo si puň benissimo incapsulare in una
classe.
cod

 classe.
guarda che struct e classe sono quasi la stessa cosa in C++ solo che una e'
di default public e l'altra private. Ad ogni modo non credo fosse questa la
risposta che si attendevano.
Leggi la domanda di Max M. e la relativa risposta e capirai a cosa si
riferivano (che e' poi quello che avevo capito io).
Alex

 Rispondete in tanti!
Non e' affatto una porcata. Fa parte del concetto di incapsulamento ed e' un
modo di fare piuttosto diffuso.
--
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 penso che sia una legge, cmq.
E allora? Dentro una classe ci posso definire dati, metodi, e altre classi. Cosa
ci sarebbe che non va?


 wrote in message
news:fqkmjt4q4vflh642o...@4ax.com...

C'e' anche chi si ostina a scrivere public: come prima cosa dopo l'aperta grafa
di una classe. Perche' mai non usare una struct?


 Non è bello scrivere come attributo di una class una satruct
In C++ standard (ovvero senza le estensioni di Microsoft) non esistono gli
attributi.


 ad esempio il mio PM dice che non e' molto bello.
Che e' un PM?


 Che e' un PM?
Personal manager?-)

ad esempio il mio PM dice che non e' molto bello.
Secondo me ci sono casi in cui e' un'ottima soluzione.
Se la struct e' dichiarata nella sezione "private"
della classe allora non ci sono problemi di visibilita'
e torna utile quando per implementare la classe si hanno
bisogno di oggetti sostanzialmente "stupidi" manipolati
dall'esterno.
Io spesso ho anche qualcosa come
  namespace {
     struct MyDummyStruct
     {
       ...
     };
  };
nei miei file .c di implementazione: in questo modo
posso creare queste strutture senza pormi il problema
di eventuali conflitti di nomi con l'esterno e senza
caricare il .h della classe di informazioni che non
interessano (e non devono interessare) i semplici
utilizzatori della classe.
L'unico motivo reale che vedo di mettere una struct
"privata" nidificata in una classe e' se questa viene
usata da qualche metodo inline.
Inoltre di solito mi capita di usare "struct" invece di
"class" in quei casi in cui mi servono solo costruttore
e distruttore o pochissimo in piu' e fare una
interfaccia con tutti i crismi non aggiungerebbe nulla
di reale al progetto (a parte costose linee di codice).
Su queste struct sono anche "pigro" e scrivo il minimo
possibile (ad esempio non mi preoccupo di scrivere il
costruttore di copia o l'operatore di assegnazione anche
se quelli sintetizzati dal compilatore so che non sarebbero
accettabili; e non aggiungo nemmeno le guardie di sicurezza
che ne impediscono la creazione). Di questo mi vergogno
un po'... ma la pigrizia e' pigrizia :DDD
Andrea
PS:
  Il mio ZQ dice che e' ok cosi' :-)
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

Rispondete in tanti!
Fatto proprio ieri:
class CPlatesCtrl : public CPopupCtrl {
  CEditorialSQL& SQL;
 
  /*.....*/
  struct drag {
    short idx;
    short n;
    bool right;
  };
 
  drag m_Mat[CPlateDesc::MAX][32];
  drag Start;
  /*.....*/
}
Molto comodo ed 'incapsulato'.

Personalmente trovo *molto* peggio scrivere "k" al posto di "ch"...
Ciao,
Nicola

 Personalmente trovo *molto* peggio scrivere "k" al posto di "ch"...
Porchata ?!?
Cmq ho capito quello che intendevi e condivido ;-)
Alex

 Porchata ?!?
Come no:
Porchata: s.f. Colpo o urto inflitto con vettura sportiva tedesca.
Ciao,
Nicola

 attributi.
E' solo un altro modo di chiamare i dati membro.
EMG

 di una classe. Perche' mai non usare una struct?
Io scrivo sempre public: e private: e non mi sembra affatto un cattivo
stile.
EMG

stile.
Class CPippo {
public:
/*......*/
}
E' cattivo stile!
Luc.

Rispondete in tanti!
contando che è la libreria standard ne fa uso e che è una tecnica
usata diverse volte sullo Stroustrup direi prorpio di no.
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

 E' cattivo stile!
Luc:
La tua conclusione mi sembra un tantino esagerata !
E' vero che normalmente si iniazia con (nelle class) il private implicito e
poi si mette dopo il public esplicito, ma .... da qui a dire cattivo stile
!!!
Andrea metteva invece peso soprattutto su un altro fatto: che DOVER evitare
struct in C++ e' stupido (cosa che alcuni sostenevano). Infatti Andrea dice,
c'e' anche chi scrive prima public (quindi di fatto emula una struct c++)
allora perche' mai non usare direttamente la keyword struct ?!?
Io personalmente inizione sempre con la parte private (spesso esplicita per
essere appunto piu' esplicito !), e molto raramente quando ritengo piu'
leggibile fare il contrario uso, di solito, la keyword struct.
E' vero anche che c'e' il gorsso pregiudizio di considerare le struct in C++
SOLO come le struct del C, ma questo e' un pregiudizio di chi ancora non e'
troppo familiare con il C++.
Alex

allora perche' mai non usare direttamente la keyword struct ?!?
E' chiaro, io infatti la penso come lui. Decido a seconda del tipo di
dati/funzioni contenute se deve essere definita class o struct.
Intendevo solo dire che a volte si vedono definite classi con tutti i
membri public... orrore!
Luc.

"Luc" <TOGL...@katamail.com-TOGLI> ha scritto nel messaggio
news:b16pjtkbdutt7rqhp...@4ax.com...

A meno che non sia una classe astratta  con  funzioni virtuali pure.
----
Sergio Bianchi          Tech-Pro s.n.c.
bia...@tech-pro.it

 membri public... orrore!
Allora ti ho frainteso....
Classi con SOLI membri public sono abbastanza bruttine (nella maggior parte
die casi).
E' vero ;-)
Alex

 membri public... orrore!
Io non ci trovo niente di cosě spaventoso.
EMG

 !!!
Io preferisco mettere per prime le informazioni che servono all'utente
della mia classe (e anche a me stesso) e alla fine la sezione private
(che, se le cose fossero fatte per bene, non dovrebbe neanche essere
visibile).
EMG

 E' cattivo stile!
Si? E quale "autorità superiore" l'ha stabilito?
EMG

 ha scritto


Infatti ho scritto "normalmente" ed ho anche detto che NON e' cattivo stile.
E' questione di gusti.  In sostanza credo che riguardo a queste cose si
possa fare piu' o meno quello che si vuole (a patto di mettersi d'accordo in
azienda ;-) per maggior semplicita').
Alex

leggibile fare il contrario uso, di solito, la keyword struct.
logico che queste sono più opinioni che altro, però secondo me è
meglio mettere prima la parte public, almeno è subito evidente quale è
i'interfaccia della classe; quali vantaggi porta mettere prima la
parte private?


E' cattivo stile!
Ma può tornare comodo nel caso si volesse contenere una classe in
un'altra senza perdere tempo a scriversi funzioni di forwarding.
Ad esempio..
class alunno
    {
    public:
        std::string nome;
        std::string cognome;
        alunno(std::string nome_,std::string cognome_) :
nome(nome_),cognome(cognome_) {}
    /*codice*/		
    };
class classe
    {
    private:
        std::vector<alunno>alunni;
    /*codice*/
    };
In questo modo le funzioni membro di classe possono liberamente
accedere ai dati dei vari alunni senza bisogno di doversi scrivere i
vari getnome() o getcognome() nella classe alunno.
A me capita molto spesso di dover scrivere classi il cui scopo é solo
quello di essere contenute da altre classi, ed in questo caso penso
che dichiarare public i membri della classe contenuta sia la soluzione
migliore.
Il Ghenio
-----
ZIO : Fun and games are over with. Anyone who dares
get in my way shall perish.
DIO ci salvi dagli ocx del Viral Basic.
-----

 parte private?
Forse non e' il caso di aprire un dibattito su questo, visto che e' solo
questione di gusti ;-)
Compilando spesso con VC++6 di usare prima public per vedere l'interfaccia
me ne faccio poco, visto che mi si apre un bel popup !!! (e poi anche avere
i public dopo non mi pare molto piu' scomodo anche senza l'ausilio del popup
!)
Iniziare con private mi pare piu' naturale in molti casi e quando mi pare
piu' naturale il contrario faccio il contrario (non mi pongo limiti
insomma).
Credo, lo ripeto, che sia solo questione di gusti !
Alex

"Luc" <TOGL...@katamail.com-TOGLI> wrote in message
news:3p3pjtciod8mj7vro...@4ax.com...

No. Sono due errori di sintassi: la maiuscola di Class e il punto e virgola
mancante alla fine!


 wrote in message
news:3B3C44E4...@flashnet.it...

Infatti non lo e'. Ma non lo e' neppure usare struct invece che class.


 wrote in message
news:3B3C44B4...@flashnet.it...

In tal caso, la frase "Non è bello scrivere come attributo di una class una
struct" non ha senso.
Infatti o stai parlando della dichiarazione della struct nestata in una classe,
e quindi non e' un membro dati e non e' un attributo e la frase non ha senso,
oppure parli di membri dati di tipo non predefinito (struct o class) e direi che
la maggior parte dei membri dati in un sistema non banale sono di fatto di tipo
non predefinito.


"Luc" <TOGL...@katamail.com-TOGLI> wrote in message
news:b16pjtkbdutt7rqhp...@4ax.com...

In realtà non la pensiamo esattamente allo stesso modo. E non trovo un orrore in
se avere classsi (o struct che e' lo stesso) con tutti i membri pubblici.
Io stesso mi trovo spessissimo a scrivere class e poi dichiarare public subito
dopo.
Ma tutto dipende dallo stile e da cosa vuoi "comunicare". Preso atto che class e
struct sono equivalenti salvo la visibilità di default e preso atto che lo scopo
del sorgente e' di comunicare il massimo a chi lo legge (e non solo al
compilatore) ciascuno puo' sviluppare un suo stile. L'importante e' usare sempre
lo stesso stile all'interno dello stesso programma e possibilmente documentarlo
(soprattutto se e' diverso da quello "comune"). Vale lo stesso per l'ident e la
posizione delle graffe.
Una cosa che faccio spesso e' usare class per tutto cio' che e' esportato
all'esterno del modulo (cio' che e' negli include, ovvero l'interfaccia pubblica
del modulo. Di solito si tratta ci classi complete con i costruttori e i
distruttori necessari, ben cocumentate etc. E sempre di solito non hanno una
parte "private" o l'hanno molto ridotta. La parte protected c'e' se e solo se
sono intese per essere derivate ma non tutte le funzionalità sono destinate agli
utenti (ma alcune solo a chi deriva). Caso piuttosto raro, in realtà.
Invece all'interno del modulo, ovvero cose non facenti parte dell'interfaccia
pubblica, uso piu' spesso delle classi non complete. In teoria e' pericoloso. Ma
a volte non c'e' il tempo per completarle fino in fondo e dato che eventuali
danni sono sempre e solo all'interno del modulo i problemi relativi saltano
fuori a livello di unit testing del modulo e non a livello di intgration testing
(salvo quando gli unit test non sono fatti bene). Per segnalare quali classi non
hanno una interfaccia "solida" e vanno usate con cautela anche all'interno del
modulo io le dichiaro con struct.
Se e quando c'e' tempo anche queste classi diventano complete e la dichiarazione
passa da struct a class e vengono magari spostate da un .cpp a un .h interno al
modulo.
Eccezione: in alcuni casi ho usato delle struct per indicare anche a livello
"extra modulo" dei "buchi d'interfaccia" intenzionali. Per esempio mi e'
capitato di avere un libreria "fatta in casa" che comprendeva alcune delle
strutture per elaborazione di coordinate 2D di Windows. Classi che
rappresnetavano punti, distanze, velocita' etc. Ovvero varie grandezze composte
da due interi con segno, alcune dimenzionamente scalari altre vettoriali etc.
Intenzionalmente le ho derivate tutte da:
struct XY {
    int x,y;
};
il che da un lato ha aperto un grosso buco, dall'altro non e' piu' grosso di
quello che avresti avuto comunque con il meccanismo dello static_cast di
puntatori o di reference. Se non altro resta "documentato".


 wrote in message
news:3B3CB092...@flashnet.it...

Anche io faccio così. Pero' in alcuni casi e' consigliabile "non fare le cose
bene" e lasciare i membri privati nella classe e avere i costruttori pubblici. O
per motivi di velocità di sviluppo o per motivi di prestazioni o per motivi di
consumo di memoria.


 wrote in message
news:3B3C8651...@divalsim.it...

ROTFL


consumo di memoria.
Lakos consiglia di mettere questi membri private in testa alla classe
proprio perche' normalmente non dovrebbero essere presenti e quindi
se ci sono e' meglio che la cosa sia ben evidente.
Ovviamente in "Large Scale C++ Software Design" l'accetto e' proprio
sull'individuare le dipendenze fisiche e una dichiarazione di classe
che ti obbliga a ricompilare tutti gli utilizzatori quando devi
fare interventi sulla parte "interna" e' in quel contesto
particolarmente discutibile.
Se c'e' il problema meglio che sia evidente: sostanzialmente Lakos
contesta l'utilita' di cercare di "nascondere" i membri privati
mettendoli in fondo ... sono comunque parte della dichiarazione
e questo avra' delle conseguenze spiacevoli.
Insomma... secondo lui e' un po' come fare le pulizie scopando
la sporcizia sotto i tappeti :D. Non sono un esperto di progetti
"grandi" in C++ ... ma come posizione mi sembra sensata.
Andrea
--
Andrea Griffini, Programmer
http://www.netservers.com/~agriff

Credo, lo ripeto, che sia solo questione di gusti !
Anche io... ma non ho mai lavorato con altre persone a progetti di
grandi dimensioni (dove per "grandi dimensioni" intendo qualcosa che
non riesca ad entrare nella testa di un solo programmatore).
In quel caso credo che, almeno per i .h, sia abbastanza importante
darsi regole precise.


membri public... orrore!
Veramente c'e' chi pensa che *tutte* le classi che tu vedi in un .h
dovrebbero avere *solo* membri public e (al piu') un piccolo puntatore
privato a una classe non descritta in nessun .h


parte private?
Ad esempio rende evidente che esiste una parte "private"
e in cosa consiste (quindi sai quali sono le rogne a cui rischi
di andare incontro -- tocca qualcosa anche solo nella parte
private e ricompili tutti quelli che usano la classe).


di una classe. Perche' mai non usare una struct?
E se quella classe derivasse privatamente da altre 8 ?
Nei miei programmi quando metto "struct" significa che i membri
sono manipolati "dall'esterno" (mi sembra di sentire le urla di
orrore dei puristi -- ebbene si' ... ogni tanto lo faccio e
credo che sia la cosa giusta).
"class" invece significa che l'oggetto e' accessibile tramite
dei metodi di interfaccia... anche se potrebbero benissimo
essere tutti public (non e' qualcosa di cosi' infrequente...
pensa alle ABC).


 darsi regole precise.
Certo !!!
In un altro post precedente, in risposta ad EMG ho scritto:
<QUOTE>
E' questione di gusti.  In sostanza credo che riguardo a queste cose si
possa fare piu' o meno quello che si vuole (a patto di mettersi d'accordo in
azienda ;-) per maggior semplicita').
</QUOTE>
Quello che dici, intendo per i progetti di dimensioni ragguardevoli e'
ancora piu' vero ovviamente !!! Purtroppo non ho ancora lavorato a progetto
cosi' grandi, intendo "qualcosa che non riesca ad entrare nella testa di un
solo programmatore" ma e' vero che esistono !!!)
Alex

 "grandi" in C++ ... ma come posizione mi sembra sensata.
E' sensata se sono valide le premesse. Come tutte la filosofie di questo genere.
Se l'accento e' sul fatto che l'uso di quella classe ti crea possibili problemi
di dipendenza a causa della (eventualmente parziale) "implementazione pubblica"
sono perfettamente d'accordo che la cosa deve essere segnalata. Il fatto che per
segnalarla metti i privati all'inizio e' una scelta filosofica.
Io per esempio seguirei una filosofia diversa. Il file include ha molte piu'
probabilita' di essere letto per capire l'interfaccia pubblica della classe che
per indovinare o capire l'implementazione. L'unico fatto "interessante" dal lato
di chi usa quella classe e' il sapere a priori che parte della sua
implementazione sta nell'include e conseguantemente il suo uso e' a rischio
dependency.
Io risolverei in modo diverso a seconda se la documentazione e' inline o
offline. Per i casi inline tendo a fare cosi':
// commenti su MyHeader
// WARNING: includes class declarations with
// implementations partially exposed. Use at
// risk of implementation change dependency
...
class NomeClasse : // WARNING: Includes Parts of Implementation
    // mezza riga (comunque non piu' di due righe) per dire
    // a colpo d'occhio a cosa serve
  public NomeBase
      // perche' derivo in max due righe
{
public:
...
  void foo();
  // mezza riga (comunque non piu' di due righe) per dire
  // a colpo d'occhio a cosa serve
  int bar( float f, char c );
  // mezza riga (comunque non piu' di due righe) per dire
  // a colpo d'occhio a cosa serve
...
/*****
    Questo e' il posto giusto per tutti i commenti approfonditi e la descrizione
    classe, del suo uso etc. Inoltre ripeto anche qui:
    WARNING: l'uso di questo include (e specificatamente di questa classe)
    puo' esporre a ricompilazioni per dipendenza dall'implementazione poiche'
    parte di questa e' pubblicata nell'header stesso
...
    void foo()
        riportare lo stesso commento che e' inlinea nel codice
      foo
        descrizione approfondita di foo e del suo uso
    int bar( float f, char c )
        riportare lo stesso commento che e' inlinea nel codice
      f
        descrizione approfondita del parametro
      c
        descrizione approfondita del parametro
      returns
        descrizione approfondita del valore di ritorno
      bar
        descrizione approfondita di e del suo uso
...
*****/
private:
  // implementation details and comments in "NomeClasse.cpp"
  int i;
  float vf;
...
};
Ovvero tendo a mettere in evidenza all'inizio le informazioni che servono piu'
spesso: il cosiddetto "cross reference" con l'elenco delle funzioni e un
brevissimo commento poiche' questo e' cio' che viene consultato piu' spesso.
Un commento piu' approfondito viene di solito usato solo una volta o solo dopo
parecchio tempo e pertanto viene subito dopo. La parte privata non viene MAI
usata e quindi sta alla fine. Pero' e' importante sapere che c'e'. E questo
infatti e' ben visibile.
Mei progetti in cui la documentazione e' offline, tanto vale usare le url in un
modo simile a questo caso:
// Docs: file://docserver/projShare/libname/MyHeader.htm#MyHeader
// WARNING: This header includes class declarations with
// Implementations partially exposed. Use at risk of
// implementation change dependency
...
class NomeClasse : public NomeBase {
    // Docs: file://docserver/projShare/libname/NomeClasse.htm#NomeClasse
    // WARNING: Includes Parts of Implementation
    // mezza riga (comunque non piu' di due righe) per dire
    // a colpo d'occhio a cosa serve
public:
...
  void foo();
  // Docs: file://docserver/projShare/libname/NomeClasse.htm#foo
  // mezza riga (comunque non piu' di due righe) per dire
  // a colpo d'occhio a cosa serve
  int bar( float f, char c );
  // Docs: file://docserver/projShare/libname/NomeClasse.htm#bar
  // mezza riga (comunque non piu' di due righe) per dire
  // a colpo d'occhio a cosa serve
private:
  // Docs: file://docserver/projShare/libname/implementation/NomeClasse.htm
  int i;
  // Docs: file://docserver/projShare/libname/implementation/NomeClasse.htm#i
  float vf;
  // Docs: file://docserver/projShare/libname/implementation/NomeClasse.htm#vf
...
};
Comunque ripeto: sono tutte solo e soltanto filosofie. L'importante e' sapere
quale problema vogliamo risolvere, mettersi d'accordo e documentare il modo in
cui lo risolviamo.


 privato a una classe non descritta in nessun .h
Infatti. Io penso che questo sarebbe l'ideale. Salvo naturalmente il fatto che
e' un ideale "generico". Ci sono casi in cui nascondere completamente
l'implementazione porta piu' danni che vantaggi. E in questi casi la regola,
come piu' o meno tutte le regole, deve essere infranta (documentando il
perche'!!!).


 solo programmatore" ma e' vero che esistono !!!)
In realtà il problema esiste anche senza arrivare a progetti fatti da milioni di
righe di codice.
Basta che il progetto non entri tutto nella testa di un programmatore ...
perche' cosi' si e' deciso.
Pensa ad un progetto che e' stato suddiviso in 8 diverse parti e queste
assegnate a otto diverse aziende che lavorano in maniera totalmente
indipendente. Anche se ciascuna aziena ci mette un solo programmatore e anche se
il progetto potrebbe essere gestito da 2 o 3 persone in tutto e le dimensioni
sono tali che anche una sola persona puo' tenerlo in testa tutto, ci sono a
volte motivazioni "politiche" o di competenza o di qualunque altro motivo tu
voglia tali per cui il progetto e' in realtà suddiviso.
Le dipendenze fra moduli diventano improvvisamente importanti. E' ovvio che, se
non vuoi avere un costo di coordinamento che supera quello del progetto, devi
per forza definire molto bene a livello di design ad alto livello quali sono le
intefacce e le dipendenze fra i moduli e far preparare gli unit-test come si
deve.


 wrote in message
news:3b3e4cb5...@news.interbusiness.it...

Come ho scritto in un altro post. Di fatto e' quello che faccio anche io (+
o -). Le due righe da me scritte e da te citate erano in risposta a qualcuno che
diceva che secondo una certa filosofia le struct vanno evitate perche' esistono
le class che fanno la stessa cosa. E io rispondevo che se il fatto che class
puo' sostituire struct e' un motivo per evitare di usare struct mi sembra piu'
sostenibile che fra
class Nome: public Base {
public:
    ...
};
e l'equivalente
struct Nome: Base {
    ...
};
sia meglio la seconda.
Nota: non sto dicendo che e' meglio. Sto dicendo che e' meglio se l'unico
criterio e' di usare una sola delle due in quanto fanno lo stesso servizio.
Ovvio che se per te (come per me) l'usare struct assume una 'semantica mentale'
(ovvero un significato non sintattico o semantico in senso stretto ma un
atteggiamento psicologico verso l'oggetto dichiarato che deriva dal tuo vissuto
come programmatore che ha conosciuto il C prima del C++) che indica "questa cosa
e' sostanzialmente 'aperta' a chiunque" mentre l'usare class ha una semantica
mentale che indica "questa cosa ha una gestione dell'accesso ai membri che tiene
nascosta l'implementazione e pubblica solo cio' che serve all'utente" allora
l'uso di struct e di class non sono equivalenti (mentalmente) e ci sceglieremo
una filosofia d'uso delle stesse che tenga conto di questo e non del fatto che
sono in realta' interscambiabili (e tanto meno del fatto che spesso negli header
"pubblici" l'uso di struct puo' portare a scrivere meno tokens!).


perche'!!!).
Quando si devono scrivere classi il cui scopo é solo quello di essere
contenute in altre classi, dichiarare tutti i membri private é solo
un' inutile complicazione che ti obbliga a scrivere un mucchio di
funzioni aggiuntive per accedere ai dati membro.
Questa é la conclusione a cui sono arrivato io dopo aver dato retta
per un pò di tempo ai famosi "integralisti" della OOP che vorrebbero
che tutti i dati membro di una classe fossero privati.


 non predefinito.
Si, ho capito cosa intendi. Però io intervenivo solo sul significato
tecnico del termine "attributo" non sull'utilizzo eventualmente
improprio fatto da chi lo ha introdotto nel primo messaggio.
EMG

 Infatti non lo e'. Ma non lo e' neppure usare struct invece che class.
Vero. Sono praticamente sinonimi. Immagino che sia solo una questione di
gusti personali.
EMG

 e questo avra' delle conseguenze spiacevoli.
Si, ma io mettendoli alla fine non cerco di nasconderli. Semplicemente
preferisco vedere prima la parte che mi serve. Comunque il mio stile č
ancora immaturo, e pertanto soggetto ad evoluzione, in quanto il C++ non
č il linguaggio che uso di piů e quindi non ho ancora avuto modo di
perfezionarne l'impostazione stilistica (per non parlare di quella
tecnica).
EMG

l'impostazione stilistica (per non parlare di quella tecnica).
A chi lo dici... dopo molti anni di uso assiduo io ho cambiato
il mio stile di indentare il codice C.
Non so se mi spiego !!! :DDD


Si? E quale "autorità superiore" l'ha stabilito?
La presenza di "struct".
Luc.

Io non ci trovo niente di cosě spaventoso.
Si, allora mettiamo tutti i dati in strutture globali cosi tutto č piů
semplice... 8)
Luc.

nascosta l'implementazione e pubblica solo cio' che serve all'utente" 
però è interessante notare che questa "semantica mentale" non credo
che derivi solo dal fatto che avete programmato prima in C. Anche io,
pur essendo approdato direttamente al C++, associo l'idea di struct
alla manipolazione "dall'esterno" e l'idea di class alla manipolazione
tramite una interfaccia.
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


Non e' la stessa cosa. Ci sono situazioni in cui e' comodo raccogliere
in un'unica struttura un insieme di dati, anche se non concorrono a
formare uno stato unitario (ad es. un insieme di flag dal significato
disgiunto). In questo caso tendo a ricorrere ad una struct dotata magari
di un costruttore di default, che mi garantisca di partire da uno stato
iniziale noto.
Ciao,
Nicola

 privato a una classe non descritta in nessun .h
...anche se in generale si riferisce a funzioni membro e non a membri
dati.
Ciao,
Nicola

iniziale noto.
Si, anche io uso spesso cosi le struct. Molti programmatori (?), però,
non sanno neanche che è possibile (e molto elegante) farlo...
Luc.

 La presenza di "struct".
Come si è detto più volte, class e struct non hanno differenze tali da
giustificare un'affermazione del genere e quindi l'uso dell'una o
dell'altra dipende solamente dal gusto personale.
EMG

 semplice... 8)
La cosa mi sembra molto diversa. Una "classe con tutti i membri public"
può essere anche semplicemente una classe astratta che serve da base per
la derivazione.
EMG


Per quel poco che faccio io cerco di seguire lo stesso stile. Questo perchč
quando io (o un'altra persona come me non MOLTO avvezza alla programmazione)
guardo l'header per ricordarmi che membri son disponibili o cosa l'insieme
dei membri dovrebbe fare, č molto piů comodo vedere subito ciň che č
disponibile per le altre classi e eventualmente cosa č accessibile dai
membri della classe stessa. Non ho mai letto manuali di stile (me ne
vergogno, ma non ho molto tempo) ma credo che non sia un grande errore. O se
lo č almeno ditemi perchč :)
P.S. All'uni a Bologna non ci hanno mai parlato di queste "decisioni" di
stile, ma ci hanno presentato questo modus operandi e stop.
Bruno

 tramite una interfaccia.
Mi domando quanto questo sia indotto dai testi che hai letto e che sono a loro
volta affetti da questa impostazione.
Per esempio se tu avessi letto testi sul C++ in cui gli esempi erano scritti
usando struct o class in eguale percentuale e in cui il testo ripeteva sempre
struct/class invece che scrivere solo class avresti avuto lo stesso
atteggiamento?


 semplice... 8)
Si. Facciamolo. Ma solo nei casi in cui il tutto e' veramente piu' semplice. E
sono molto pochi. Nella quasi totalità dei casi il tutto diventa molto piu'
complicato.


 wrote in message
news:3B4061EB...@divalsim.it...

La filosofia di cui parla Griffini in realtą vuole che in un header pubblicato
ci sia solo cio' che e' pubblico. Nessun membro dati e nessun metodo privato.


 ci sia solo cio' che e' pubblico. Nessun membro dati e nessun metodo privato.
Ma non per questo va intesa nel senso di riempire gli header pubblicati
di membri dati pubblici.
Ciao,
Nicola

 di membri dati pubblici.
No di certo!!! Al contrario! Tutto quello che no fa parte dell'interfaccia
pubblica della classe viene reso talmente privato ... che viene del tutto
rimosso dalla dichiarazione pubblica.
L'idea non e' affatto quella di rendere pubblico tutto. Ma quella di non mettere
nell'header pubblico cio' che non e' pubblico.


atteggiamento?
sinceramente non sono in grado di risponderti; il mio approccio con il
C++ č stato molto tortuoso: avevo cominciato a leggere qualcosa quando
avevo 13 anni e non ci avevo capito niente, poi avevo sempre
costantemente cercato di riprenderlo a intervalli piů o meno regolari
(2-3 anni), sino a che non ho iniziato a seguire questo ng (dove č
diffusa questa "semantica mentale". Anche sullo Stroustrup (l'unico
testo decente che ho letto) si segue questa convenzione.
Forse un'altra causa č da attribuire all'esperienza che ho avuto con
il Turbo Pascal 7 with objects: in TP la differenza tra Record e
Object č molto marcata e probabilmente l'ho trasposta sull'accopiata
struct/class.


di membri dati pubblici.
In effetti avrei fatto meglio a precisare che intedevo metodi...
come diceva sempre il mio prof di Analisi ai tempi dell'uni
e' meglio evitare espressioni ambigue... non si usa "positivo"
ma solamente "non negativo" oppure "strettamente positivo" ...
in modo da non lasciare ambiguita' su cosa si intenda di preciso.
Parlando di C++ si dovrebbero usare come termini "membro dati"
e "metodo". Il termine "membro" e' vago (e leggermente osceno ;) ).
