Newsgroup: it.comp.aiuto
Titolo: Classi in C++

Ho iniziato da poco a studiare il C++ e non ho ancora capito cosa sono
e a cosa servono le classi.C'e' qualcuno che puo' risolvere il mio
problema?

problema?
spiegare il C++ in poche righe e decisamente difficile, ti conviene
acquistare un buon libro e studiarlo a fondo. 
Comunque le classi servono per scrivere  programmi in c++ ;-)
Se hai domande piu' precise contattami pure via e-mail.
Ciao
Gianpaolo Bottin
Bruino (TO) - Italy
E-Mail: 
bott...@mbox.vol.it
-----------------------------------------

Se hai domande piu' precise contattami pure via e-mail.
Perchè invece non continuiamo a trattare di C++ tutti insieme in
questa sede in attesa di eventi futuri?

Ho iniziato da poco a studiare il C++, cosa sono le classi.?
Brevemente, con il rischio di essere impreciso.
In C con le strutture puoi raggruppare vari dati per definire un
qualcosa, (vedi la struttura "tm" in time.h che si casca a fagiolo).
In C++ alcune strutture prendono il nome di classi, perchè, attraverso
un'opportuna sintassi, permettono di inserire oltre ai dati anche
funzioni, che vengono definite proprietà dell'oggetto  in quanto
permettono di compiere azioni sull'oggetto.
Ad esempio in C++ si protrebbe definire la classe cronometro,
inserendo oltre che all'ora di inizio ed eventuali intertempi anche le
funzioni necessarie per agire sul cronometro, quali "start", "stop",
ecc.
Anchio studicchio, tempo permettendo, il C++, e non disdegnerei di
parlarne con altri.
Nella speranza di esserti stato utile, ti saluto e ti incoraggio.
Ciao.
*-- Fabio Richeri -- 
sin...@msoft.it
 --*
Fammi sapere se riesci a realizzare un cronometro in C++!!

questa sede in attesa di eventi futuri?
certo, perche' no ?
il C++ e' un linguaggio molto complesso e sarebbe interessante
scambiarsi opinioni. Io uso il Visual C++ e lavoro quotidianamente con
le MFC.


 Comunque le classi servono per scrivere  programmi in c++ ;-)
Ma spiegare la idea di classe e' di per se gia' piu' semplice.
Partiamo dal modo di operare senza classi.
Ci sono funzioni e procedure, e ci sono i dati. Tutto cio' che li lega
e` controllato dal programmatore che scrive il codice.
In alcuni  casi il linguaggio blocca  il programmatore impedendogli di
fare errori (ad  esempio sommare una   pera ed una banana,  oggetti di
tipo diverso).
Altre  volte  il linguaggio non e'  in  grado di farlo.  Ad esempio se
rappresentiamo con  numeri interi sia il codice  di un prodotto che il
prezzo,  nulla vieta al computer  di sommarli, anche se non chiedetemi
cosa voglia dire fare una cosa del genere. Ma ci sono differenze anche
piu' sottili (che so lire e sterline, gradi Celsius e Farenheit).
Con la classe si mette in gioco un meccanismo con cui si legano azioni
e dati con un vincolo molto forte.
Una classe  contiene sia i dati  da elaborare sia le operazioni lecite
su quei dati.
o   oooooo	Gian Uberto Lauri
      o    o	
sa...@maya.dei.unipd.it
     o o

 su quei dati.
[  Il post finiva  di brutto qui perche'  se  non me  ne andavo subito
scatenavo un concerto per antifurti da far paura... ]
Allora una  classe contiene sia i  dati da elaborare sia le operazioni
lecite su quei  dati. Lo scopo principale e`  nascondere i dettagli in
modo  da impedire un  uso non corretto  dei dati attraverso operazioni
assurde.
Se per esempio  si    realizza una  classe che  descrive   un semaforo
stradale (quello che cicla tra rosso->verde->giallo)  da un lato ad un
certo punto  ci  si  trovera' a dover   dire in  maniera piu' o   meno
elegante che il semaforo deve poter assumere quattro valori diversi (e
non  occorre il  meccanismo  delle classi  per impedire che  si faccia
diventare il semaforo "Turchese pallido screziato di lilla"), ma ci si
trovera'  a  voler impedire che un  furbacchione  cominci  a  usare il
semaforo   in  maniera strana, che  so  facendo  scattare i  colori in
maniera   casuale   ed  imprevedibile  (rosso...   giallo... spento...
rosso...  verde...  giallo... verde).  La  classe permette di  evitare
questo impedendo di dire "faccio diventare la luce di un certo colore"
ma permettendo di fare operazioni piu' controllate ("passa al prossimo
colore", "passa al modo notturno").
Le classi permettono  quindi  di arricchire il linguaggio  in  maniera
robusta. Il  meccanismo e' molto  piu'  potente di quanto  esposto, in
quanto  ci sono  poi  possibilita'  di  creare "prototipi" e   modelli
astratti dai quali derivare i modelli reali. E per fare questo occorre
un  libro  buono (consiglio  lo Stroustroup,   anche  perche' ha degli
esempi su come si scrive del buon codice C  quando c'e' bisogno di non
perdere tempo - l'esempio migliore e'  quel gioiellino chiamato Duff's
Device).
A proposito, il mio giudizio personale sulle MFC e' al momento 5--.


A proposito, il mio giudizio personale sulle MFC e' al momento 5--.
Non sarei cosi' severo con le MFC. Probabilmente da un punto di vista
object oriented non sono un gran che, ma per lo sviluppo di
applicazioni windows le trovo ottime. Solo alcune classi, tipo
l'anteprima di stampa, sono strutturate in modo non proprio ottimale e
rendono difficile personalizzarne il comportamento. Il vero punto
debole secondo me, e' la documentazione che per certe parti e'
veramente carente, cosi' alla fine bisogna andarsi a vedere i sorgenti
per capire come funzionano veramente le classi.


 per capire come funzionano veramente le classi.
Sei gentile. Il libro Programmare in MFC e  Win32 del 1995 e' a tratti
una vera barzelletta.


 le MFC.
Appunto, io ho studiato un po' il C++, ho fatto qualche prova con il
buon vecchio DOS trovo che offra un sacco di vantaggi. Poi ho dato
un'occhiata alle MFC, troppo difficili, attualmente sto studiando le
API di Windows. Chissà un domani potrò riprendere le MFC con maggiore
congnizione.
Ti sembra correto o hai un percorso AUTO-didattico alternativo? Sarei
felice di conoscere i Vostri pareri. Il problema maggione è che il
tempo è poco, devo anche lavorare, e ci sono un sacco di nozioni da
apprendere, però io vorrei sapere... Non ci sono le iniezioni di
classi per endovena o comunque un sistema il più rapido possibile?
 Fabio Richeri   
sin...@msoft.it

cui si puo' intervenire per migliorare l'efficenza.
Ci fai il nome di questa collezione di classi ? Magari con qualche
informazione  in più? Grazie.
Fabio Richeri   
sin...@msoft.it

una vera barzelletta.
non lo conosco, uso la documentazione del Developer Network o i books
on line. Il problema della documentazione non e' tanto che sia
sbagliata ma quanto il fatto che certe cose proprio non ci sono,
giusto un esempio : la classe CSharedFile e' utilissima per gestire la
clipboard ma e' stata documentata solo con la versione 4.0


congnizione.
be' non saprei dirti io lavoro in windows ormai da ... boh, non mi
ricordo comunque era appena uscito Windows 3.0. Poi ho iniziato ad
usare le MFC con il Visual C++ 1.5 per cui gia' conoscevo abbastanza
bene l'ambiente windows e mi sono subito trovato a mio agio, anche se
comunque quelle 3-4 settimane di rodaggio ci sono comunque volute.
Dovessi comunque iniziare oggi direi di partire subito con un
framework di classi tipo MFC o analoghe. E' vero che ci sono cose in
piu' da imparare ma il lavoro di routine di riduce di un decimo, nel
senso che ci si concentra di piu' sullo scopo dell'applicazione e
molto ma molto di meno sulla gestione di finestre, controlli, oggetti
grafici e cosi' via.


 
sin...@msoft.it
 (Fabio Richeri) writes:
 
sa...@sonia.dei.unipd.it
 (Gian Uberto Lauri) dice:
   >Ho  avuto la possibilita' di  provare un'altra collezione di classi ed
   >il relativo  ambiente di  programmazione visuale.  Mi e' bastato  solo
   >conoscere il C++ per capire immediatamente come ed  in che  modo il
   >codice viene collegato a quest'altro framework e quali sono i punti in
   >cui si puo' intervenire per migliorare l'efficenza.
   Ci fai il nome di questa collezione di classi ? Magari con qualche
   informazione  in piů? Grazie.
Allora la  collezione    di classi si  chiama   Open  Class ed  e'  di
IBM. Contiene classi container,  per l'iterfaccia utente e l'accesso a
dati.
il documento "IBM Open Class Library" dice testualmente :
"Classes in the IBM Open Class  Library support consistent programming
interfaces across the entire range of platforms supported by VisualAge
for C++:  OS/2, AIX, MVS/ESA, OS/400,  Sun Solaris** and Windows. This
makes cross-platform   porting faster, easier,  and  less error-prone.
Following the documented  guidelines,  an application written  to  the
core classes in Open Class can be easily ported to the other operating
system environments. Use  the powerful programming abstractions in the
IBM Open Class Library rather than the low-level system-specific APIs.
This can   help reduce the   amount of platform-specific  code in your
application.
 
Because the C/C++ language standard and  class libraries were designed
for portability,  programs written for VisualAge  for C++ for OS/2 can
be  recompiled  with  minimal  system-specific  coding  required.  The
resulting  application  will have the  "look  and  feel"  of a  native
Windows application.  Optionally, applications  can  have the IBM  CUA
look and feel through the use of style options."
Avendo a disposizione  il generatore di codice Visual  Age C++  non e'
quasi necessario conoscere le classi (apparentemente, e' invece sempre
necessario sapere cosa combina il computer :) ).   Un text editor puo'
essere   creato in  maniera   totalmente visuale, idem    un CD player
minimale.



   NNTP-Posting-Host: 
to-b-15.intelnet.vol.it
   X-Newsreader: Forte Agent .99e/32.227
 
sa...@sonia.dei.unipd.it
 (Gian Uberto Lauri) ha scritto:
   >Non e' tanto la ottica OO che metto in discussione  (C++ ha le classi,
   >non  gli  oggetti),   quanto la  qualita'  globale   del  prodotto.  A
   >cominciare  dai meccanismi di collegamento   del codice al framework (
   >molto  "esoterici" ).  Per  passare  poi ad  alcune violazioni del C++
   >(meccanismo di throw & catch, diventato standard solo con Win32).
   quali meccanismi "esoterici" di collegamento al framework ? non ho
   capito. 
 
Mi spiego subito. Il   modo in cui  (realizzazione pratica)  viene  il
flusso del programma  arriva ad un certo metodo  non e' chiaro e puzza
di sporco trucco. Ci sono modi piu' eleganti e chiari.
   Non direi proprio che il meccanismo throw/catch non sia standard C++,
   anzi  ! 
Esatto, lo ha definito B.S. . Che  bisogno c'era di rifarlo in maniera
non standard ???
   Ed e' comunque una cosa ben diversa dal meccanismo "structured
   exception handling" di Win32. Semmai erano i compilatori VC prima
   della v2.0 a non supportare throw e catch per cui gli sviluppatori
Ah ecco,   come avevo  immaginato,  non   erano riusciti a   fare   un
compilatore decente. Hai presente da  quanti anni il GCC (presto anche
con IDE per WIN) e' un compilatore serio ?
   delle MFC si sono dovuti adattare utilizzando altri mezzi e quindi
   nelle MFC si trovano le macro THROW e CATCH che ora comunque vengono
   tradotte nelle equivalenti throw/catch del C++ (e non di WIN32 che
   sono cosa ben diversa).
Non esattamente vero. I due meccanismi sono simili ma non identici.
   >Ho  avuto la possibilita' di  provare un'altra collezione di classi ed
   >il relativo  ambiente di  programmazione visuale.  Mi e' bastato  solo
   >conoscere il C++ per   capire immediatamente come  ed  in che  modo il
   >codice viene collegato a quest'altro framework e quali sono i punti in
   >cui si puo' intervenire per migliorare l'efficenza.
   ho sempre solo usato le MFC, prima usavo l'SDK direttamente, per cui
   non posso esprimere un giudizio. A me sembra che il punto di forza
   delle MFC sia proprio il loro stretto legame a windows, per me che
   gia' conoscevo l'SDK il passaggio alle classi e' stato abbastanza
   indolore.
Ripeto, con questa altra collezione di classi basta lo Stroustroup per
capire tutto in minuti...


capire tutto in minuti...
probabilmente hai ragione, non lo metto in dubbio, ho letto anche
nell'altro tuo post cosa permette di fare questa libreria. Mi
rimangono comuque dei dubbi sul fatto che uno che conosce bene windows
possa trarre dei vantaggi da un sistema che fa di tutto per nascondere
(o astrarre, se preferisci)  windows. Inoltre come vengono gestite
tutte quelle caratteristiche perticolari di windows tipo
l'architettura MDI, OLE2, i controlli OCX,  le interfacce COM,  tutti
i vari gadget di windows tipo i nuovi list control ? E le altre
caratteristiche comuni a tutti i programmi windows piu' "alla moda"
tipo dockable toolbars, tooltips, print preview ?
Faccio queste domande non per pura polemica (lungi da me l'idea di
accendere una polemica del tipo "il mio e' meglio del tuo") ma per
curiosita' di sapere come vengono gestite in un ambiente che vuole
astrarre il piu' possibile l'API sottostante.
Personalmente preferisco sempre sapere quale legame c'e' tra le classi
e l'API sottostante, faccio un esempio se con l'SDK per disegnare su
una finestra dovevo fare:
dc=GetDC(hWnd);
MoveTo(0,0);
LineTo(100,100);
ReleaseDC(hWnd,dc);
per me diventa semplice scrivere con le MFC:
CClientDC dc(this);
dc.MoveTo(0,0);
dc.LineTo(100,100);


 <SAINT.96May29154741@jole>
   NNTP-Posting-Host: 
to-a-4.intelnet.vol.it
   X-Newsreader: Forte Agent .99e/32.227
 
sa...@dei.unipd.it
 (Gian Uberto Lauri) ha scritto:
   >Mi spiego subito. Il   modo in cui  (realizzazione pratica)  viene  il
   >flusso del programma  arriva ad un certo metodo  non e' chiaro e puzza
   >di sporco trucco. Ci sono modi piu' eleganti e chiari.
   dipende probabilmente dai punti di vista e dalla conoscenza del
   funzionamento del sistema operativo. Ripeto, per me che conosco come
   funziona windows il meccanismo con cui il flusso di programma arriva
   ad un certo metodo e' chiarissimo anche con le MFC, non c'e' nessuno
   sporco trucco, solo un po' di macro e qualche mappa. Il meccanismo dei
   messaggi e' insito in windows stesso, le MFC utilizzano poi delle
   mappe e delle macro per farli arrivare ai vari metodi delle classi, il
   fatto che un sistema sia piu' o meno elegante e chiaro dipende da
   quanto codice c'e' sotto per gestire tutto il marchingegno.
   Personalmente preferisco un sistema meno elegante ma piu' efficiente.
Non   devi venire a parlare  a  me di codice  efficente,  visto che di
solito mando a  quel paese il C++  perche' ha degli overhead impliciti
(in un laboratorio di ricerca  sul supercalcolo C++ e' considerato una
parolaccia alla  stregua di Windows  e Solaris.  Il perche'  e'  anche
comprensibile, se uno spende cifre superiori al milione di dollari per
aver una macchina da qualche centinaio di  MEGAFLOP, sprecare anche un
ciclo macchina scoccia :) ).
Quando parlo di  sporco trucco con  connotazione negativa parlo  di un
meccanismo non standard del linguaggio  nel quale e' pericoloso per il
programmatore mettere le mani.
Non  ci  vuole molto  a capire che  in qualche  maniera si compila una
struttura che  visita quando fa il  recapito dei messaggi. E da quello
che   si   evince dalla documentazione     l'instradamento non pare un
gioiello di efficenza.
   >Ripeto, con questa altra collezione di classi basta lo Stroustroup per
   >capire tutto in minuti...
   probabilmente hai ragione, non lo metto in dubbio, ho letto anche
   nell'altro tuo post cosa permette di fare questa libreria. Mi
   rimangono comuque dei dubbi sul fatto che uno che conosce bene windows
   possa trarre dei vantaggi da un sistema che fa di tutto per nascondere
   (o astrarre, se preferisci)  windows. Inoltre come vengono gestite
   tutte quelle caratteristiche perticolari di windows tipo
   l'architettura MDI, OLE2, i controlli OCX,  le interfacce COM,  tutti
   i vari gadget di windows tipo i nuovi list control ? E le altre
   caratteristiche comuni a tutti i programmi windows piu' "alla moda"
   tipo dockable toolbars, tooltips, print preview ?
Allora, iniziamo subito col dire che se  uno sceglie la programmazione
ad oggetti,  sceglie di   pagare  un certo costo   con lo  overhead ma
dall'altro vuole in  cambio astrazione dai dettagli implementativi, in
modo tale che quando questi  cambiano, la struttura sovrastante non se
ne accorge. 
Vantaggio delle classi di IBM ? Scrivo  una applicazione con Warp e la
porto subito su Windows, AIX, Solaris,  AS400, MVS...  HP=UX o e' gia'
supportato   o e'  previsto. Certo  pensare  che  qualcuno  voglia una
applicazione home su un 3090  e' assurdo, ma  ci sono applicazioni che
hanno utenza almeno sui primi 4 S.O.  citati, visto che Sun continua a
offrire support Mac OS e Win3.1 per le sue macchine.
E  visto che  almeno fino  ad  ora la  Intel non   ha fatto processori
altrettanto efficenti   dello Sparc  o del  Power  PC (la   cui scarsa
diffusione sul mercato personal e'  legata solo alla disponibilita' di
software "alla moda", visto che fino ad ora Windows non mi offre tutti
gli  strumenti  che mi offrono   Warp e Unix,  allora preferisco poter
lavorare su piu' piattaforme prevedendo anche Windows come target.
Coi soldi che pompo dagli utenti Windows magari ci finanzio la GNU.
MDI. Niente di piu' facile. Fai un  subclassing e cambi lo stile della
finestra. 
Commento su MDI e' supportato solo da Microsoft, il resto del mondo lo
ha abbandonato 2 anni dopo la  definizione (MDI e' del  CUA 89, SDI e'
nel  CUA  91).  Sinceramente non lo  apprezzo.   Spreca molti  pixel a
video.   La cosa non si  nota forse con  Excel  o con Word.  Quando un
wordprocessor mostra 15 righe di  testo mostra una quantita' di parole
tali da contenere una buona qualita' di informazioni.  Credo che ci si
possa mettere dentro il tema di greco/latino della maturita' classica.
Quindici righe  di codice C spesso  e volentieri sono troppo poche per
avere una visione  di insieme  del codice  su  cui si lavora.  Non  e`
polemica.  E'  voler mostrare   che    non esiste mai  la    soluzione
definitiva. Ad  esempio Watcom ha  fatto  una IDE  molto sveglia sotto
Warp che gestisce alcune cose  in MDI e altre  (gli editor ad esempio)
in SDI. E in questo ha usato la cosa migliore nel momento migliore.
Altri controlli :  Ci sono tutti. Compresi  dei controlli sfiziosi che
hanno   ragione   di  essere      in applicazioni   multimediali    (o
particolarmente idiote     come l'editor che     mi   son divertito  a
costruire).
   Faccio queste domande non per pura polemica (lungi da me l'idea di
   accendere una polemica del tipo "il mio e' meglio del tuo") ma per
   curiosita' di sapere come vengono gestite in un ambiente che vuole
   astrarre il piu' possibile l'API sottostante.
Il concetto  e' abbastanza  facile da spiegare.   Con queste classi si
"firma implicitamente un contratto" con  il programmatore. Il quale ha
diritto di pretendere che le  classi sottostanti si presentino con una
certa  interfaccia di   cui  e` definita   non solo la  sintassi  e la
tipologia dei dati, ma anche la semantica delle operazioni.
L'obiettivo di questo approccio  e'  permettere la riuscita di  grossi
progetti di codice.   Dove con grossi  progetti  si intende  quelli da
centinaia di migliaia di righe di codice.
   Personalmente preferisco sempre sapere quale legame c'e' tra le classi
   e l'API sottostante, faccio un esempio se con l'SDK per disegnare su
   una finestra dovevo fare:
   dc=GetDC(hWnd);
   MoveTo(0,0);
   LineTo(100,100);
   ReleaseDC(hWnd,dc);
   per me diventa semplice scrivere con le MFC:
   CClientDC dc(this);
   dc.MoveTo(0,0);
   dc.LineTo(100,100);
Qui c'e' solo un cambio sintattico, e meno  codice da scrivere. Non e'
mica una cosa  poi stupida, ad esempio e'  notorio che per disegnare a
video con Windows devi richiedere un display context e poi rilasciarlo
appena hai finito di usarlo perche' che ne sono solo 5, quindi mettere
le operazioni  di GetDC  nel costruttore  e ReleaseDC nel  distruttore
semplifica la vita al programmatore e assicura che le operazioni siano
fatte  al momento opportuno.
Ma il vantaggio e' un'altro.
Supponiamo che   la Deluxe Computers   per il suo DLX560  sviluppi, in
accordo con Microsoft, delle classi MFC compatibili per il suo sistema
operativo  propietario. Con  l'uso  della classi  il  programmatore si
interessa solo di mandare i messaggi MoveTo e LineTo all'oggetto dc.
Non gli interessa che usando le api grafiche del DLX Graphic ToolKit
la cosa si faccia con un
/* Questo e' C ! */
swithc(QueryGraphicHW)
{
	case raster: BresenhamLine(Color, 0, 0, 100, 100);
			break;
	case vector: {
			vector *a;
 
			a=(vector *)malloc(sizeof(vector))
			a->x1=a->y1=0, a->x2=a->y2=0;
			AddVectorToBuffer(a);
			break;
		     }
}
gli basta solo che l'oggetto dc risponda in un certo modo ai messaggi
MoveTo e LineTo. 
Guardare a cosa viene fatto va  benissimo nel momento  in cui si vuole
ottimizzare l'efficenza del programma. Ma e' l'ultima cosa da fare. Se
no tanto vale non usare nemmeno il C  e andare a lavorare direttamente
in Assembler...


in Assembler...
secondo me invece e' fondamentale sapere non solo cosa fa il framework
quando processa i messaggi e li invia alle mie classi ma anche cosa fa
il C++, quale overhead aggiunge alle funzioni che hanno classi
dichiarate sullo stack, l'overhead aggiunto quando si usano
throw/catch. Queste ed altre cose le analizzo sempre a fondo prima di
scegliere come implementare funzioni critiche. Non e' la prima che mi
faccio generare il listato assembler dal compilatore per vedere come
ottimizza determinati costrutti in modo da scegliere quello migliore.
Ad esempio nel mio progetto ho ridotto al minimo l'uso delle SEH
(Structured Exception Handling) di Win32 perche' sebbene utili con il
costrutto __try/__finally impongono un overhead esagerato specie per
funzioni di poche righe.
Non ci penso nemmeno a tornare al C, la versione precedente del
software di cui ti ho detto prima era scritta in C per dos + dos
extender (compilata con Watcom) e sebbene molto piu' semlice di quella
attuale era un casino da gestire.
Per progetti di una certa dimensione il C++ e' una benedizione. Si
tratta solo di sapere cosa si nasconde dietro la facciata e di
utilizzarlo con giudizio.


Mi unisco volentieri a voi ... ho iniziato a studiare il c++ da un po'
di giorni... ancora sono un po' pivellino ma in c me la cavo
abbastanza bene ... sarebbe interessante fare un newsgroup. che ne
dite??
                                      ```
                                     (o o)
+--------------------------------oOO--(_)--OOo----------------------------+
| Bruschi Tiziano                    | Office:  +39-071-2802131-2802130   |
| Sw-Project                         |    FAX:  
+39-071-2802125
           |
| Via F.Corridoni 1                  |   Home:  
+39-071-9170845
           |
| Falconara M.ma (AN)60015 ITALY     |  EMAIL: 
tiz...@cirano.cpr.it
      |
|-------------------------------------------------------------------------|
 

 questa sede in attesa di eventi futuri?
D'accordo per la discussione circa il C++ su questo group.
Aggiungo qualcosa, con modestia...
Le classi, inoltre (ma la stessa cosa vale per le strutture, che non sono che 
delle classi un po' particolari) possono essere ereditate.
Ad esempio, per la classe cronometro, 
class TCronometro
{
private:
	int time_start;		// Tempo inizio
	int inter_time;		// Intertempo
public:
	time	Start();	// Funzione che memorizza l'istante iniziale 												
// 	e lo ritorna in uscita
	time	Partial();	// Funzione che memorizza il tempo parziale 												
// 	trascorso e lo ritorna in uscita
	time	Stop();		// Funzione che calcola il tempo complessivo 												
// 	passato e lo ritorna in uscita
}
potrebbe essere utile una classe che ne consente la visualizzazione, ma che 
eredita tutte le caratteristiche:
class TShow_cronometro : public TCronometro
{
public:
	void	Show();		// Stampa sul video il tempo trascorso
}
Quest'ultima classe può utilizzare funzioni e dati che appartengono a 
TCronometro senza doverle ricreare.
Ma il C++ e' comunque ben di piu'...
Bye.
	Leonardo
	========

Ma il C++ e' comunque ben di piu'...
certamente !


dite??
sarebbe interesante, ma penso che siamo un po' troppo pochi :-(


sarebbe interesante, ma penso che siamo un po' troppo pochi :-(
Hai ragione, ma aumentiamo di giorno in giorno, teniamo acceso
l'argomento quě, poi matureranno i tempi. Non c'č fretta.
 *--Fabio Richeri - 
sin...@msoft.it
 --*
P.S.: Grazie a tutti per le ottime esposizioni.

Ma il C++ e' comunque ben di piu'...
Un vivo e sincero pubblico applauso al contributo portato al thread.


delle classi un po' particolari) possono essere ereditate.
Unico appunto, sono le classi ad  essere strutture un po' particolari.
Stroustroup e' partito dalla struct del C  per creare la class del C++
(all'inizio il C++ veniva tradotto in ansi C  da un preprocessore). La
classe non fa altro che formalizzare  delle tecniche di programmazione
possibili anche  in C, e  permettere al  compilatore  di esercitare un
controllo piu' forte.
