Newsgroup: it.comp.lang.c++
Titolo: Manuali

Dunque.. io avrei una domanda...Io tempo fa (
c.ca
 3/4 anni) programmavo in
C++ ed ora mi ritrovo a dover recuperare velocemente tutti i paradigmi che
(ahime'...) ho perso in questo tempo... Qualcuno mi consiglia cosa potrei
leggermi (possibilmente qualcosa di free...)
Disgusting Angel

"Disgusting Angel" <i...@a.fake> ha scritto nel messaggio
news:WBASa.17800$sj6.3...@tornado.fastwebnet.it...

"Thinkning in C++" di Bruce Eckel ( 
www.bruceeckel.com
 )
Sono due volumi, del primo trovi una traduzione su 
www.umbertosorbo.it
Cosa intendi per "paradigmi" che dici di aver perso?
Ciao

> Cosa intendi per "paradigmi" che dici di aver perso?
Programmo da piu' di un anno in .NET... devo recuperarmi tutta la logica OOP
del C++ :))))
PS: FINALMENTE!!!!!!
Disgusting Angel


Praticamente ti devi "disintossicare"... :-)
Sini Andrea

 wrote in message
vUBSa.3693$t92.1...@news1.tin.it...

Ma il framework .net non era anche lui oo?

 Ma il framework .net non era anche lui oo?
Si, molto OO. Non so a cosa si riferisce, ad esempio C# e' leggermente
diverso dal C++ per la OO. Al contrario di quello che dice Andrea
("Praticamente ti devi "disintossicare"... :-)") e' molto puro e pulito C#.
Non ci sono i tipi primitivi ma tutti i tipi sono oggetti e tutti derivano
da System.Object, il quale descrive persino una interfaccia. Quindi tutti
gli oggetti che si possono utilizzare derivano da una gerarchia con una sola
radice (e questo rende molto piu' potente il polimorfismo ad esempio!).
Forse l'unica cosa sporca e' il fatto di avere value-types e
reference-types, per quanto alla fine sia la scelta migliore, non e' del
tutto pulita (questo vale anche per cio' che ne deriva: boxing-unboxing).
Inoltre C#, come Java, al contrario di C++, non ha un paradigma misto, ....
la solita funzione main in una classe in pratica.... (ma anche questo, che
non mi piace molto... e' considerato pero' piu' OO).
C# poi introduce le "properties" che sono metodi che sembrano attributi. In
pratica c'e' ancora piu' astrazione, all'occhio dell'utente uno setta
direttamente gli attributi invece.... (beh, e' una soluzione piu' elegante
rispetto ai soliti get e set!).
In .NET e' persino OO il MSIL (Microsoft Intermediate Language) che e' poi
una specie di "assembly" object-oriented (non nel vero senso della parola)
creato per essere il linguaggio target di tutti i compilatori .NET (questo
aumenta la portabilita' e la facilita' di uso di linguaggi diversi nello
stesso progetto etc...).
In pratica sono convinto che dopo un anno di .NET uno abbia bisogno di
ripassare il C++. Non sono convinto che debba essere cosi' "disperato" e
nemmeno che debba disintossicarsi. (questo non vale per Visual Basic .NET
che non conosco, ma se uno parla di .NET senza specificare di solito parla
di C#).
Tommy

 stesso progetto etc...).
A scapito dell'efficienza, pero'. Se non devo portare il mio codice,
perche' non compilare direttamente in codice nativo?
 
Ciao,
Nicola

perche' non compilare direttamente in codice nativo?
Che io sappia, il codice è compilato Just In Time, quindi la sua
efficienza è pari a quella del codice nativo, con il vantaggio di
essere portabile.
-- 
Open Delphi Manual
http://groups.yahoo.com/group/delphi_open_manual/

 perche' non compilare direttamente in codice nativo?
Sull'efficienza non lo so. Rispetto al codice nativo e' sicuramente piu'
lento. Rispetto al bytecode di Java non lo so.
.NET e' stato creato come risposta a Java, quindi credo che, almeno non
abbiano perso tempo, diventera' piu' veloce di Java.
Rispetto al codice nativo e' certmante piu' lento, tranne quando le
ottimizzazioni dinamiche riescono a fare molto di piu' di quello statiche
(in fase di compilazione) nel qual caso il JIT compiler potrebbe,
stranamente, dare risultati migliori.
Il vantaggio di avere un codice intermedio e non quello nativo e':
windows presto girera' su:
alpha, x86, x86 64 bits, itanium 2, etc....
I codici nativi sono tutti diversi (tranne per x86 e x86-64 se si usa il
sotto-insieme a 32 bits). Usando il MSIL una applicazione puo' girare su
tutte queste macchine con windows.
Per finire, la piattaforma .NET verra' portata su altri OS. Ad esempio il
progetto mono, (
http://www.go-mono.com/
) la sta portando su linux (ed e'
opensource).
Microsoft non e' contrari ai vari port di .NET (c'e' anche un port simile,
meno maturo, della GNU, e micorsoft ne ha fatto uno di esempio per FreeBSD).
Anzi, tali port sono indispensabili per fare guerra a Java. Per questo sia
C# che MSIL sono standard ISO/ECMA.
Quindi compilare per MSIL invece che codice nativo potrebbe avere parecchi
vantaggi.
Se non ti interessa la portabilita', beh sono sicuro che quella su windows
non ti faccia schifo e comunque oggi giorno i JIT compilers non rallentano
tanto.
Poi quando vuoi codice nativo e programmi veramente veloci, o fare
programmazione di sistemi, allora userai il C++ o il C con il VC++.NET che
compila in codice nativo.
Credo che il C ed il C++ dureranno ancora a lungo, non sono sostituibili.
Tra le altre cose il codice in MSIL non deve sempre essre convertito in
codice nativo tutte le volte. Questo e' quello che accade in in modo
automatico:
Quando esegui in programma in MSIL, il JIT lo compila (un pezzo alla volta,
quello che serve) in CPU-specific (native code) e lo mette in una cache.
Quando riusi quel pezzo (ad esempio una funzione e' gia' compilato), quando
usi tutto il programma e poi lo riusi in un secondo momento e' gia'
compilato in native code..... Questa cache e' quasi permanente.
L'alternativa di cui parlavo e' usare il "Install-time code generation" che
e' un altro JITter che compila il codice MSIL in codice nativo quando il
programma viene installato!
Da dopo l'installazione in poi non si parlera' mai piu' di MSIL, quindi MSIL
in questo caso viene solo utilizzato per la distribuzione portabile di
codice.
Concludo dicendo che il C++ e' sempre il mio linguaggio preferito. Ci tengo
pero' a dire che ho sempre snobbato C#, pensavo fosse un linguaggio senza
carattere, l'ho ignorato per parecchio tempo. Poi ultimamente mi e' capitato
di studiarlo (da poco) e devo dire che mi piace; certamente molto piu' di
Java. Quindi prima avevo solo pregiudizi.
Quindi Nicola, io come te, penso che il C++ sia il linguaggio piu' bello del
mondo (altrimenti non starei qua, e su it.comp.lang.c), ma C# non e' poi
cosi' male, almeno non cosi' male come me lo immaginavo ;-)
Tommy

 multipla.
Si e' cosi', ci sono le "interface".
Tommy

 di C#).
dunque.. disperato nn sono (forse x esagerata fiducia in me stesso,
questo nn lo so...) ma cmq ti voglio solo dire che x quanto (giuro)
ammiro e adoro la piattaforma .NET il fatto di avere un Garbage
Collector mi da assolutamente fastidio. Un programmatore deve saper
programmare, deve saper controllare le reefrenze dei "SUOI"
puntatori... deve poter forzare un *void a *char ricordandosi di
quello che ha fatto, deve essere COSTRETTO a ricordarsi di deallocare
la memoria allocata. Una persona che nn lo sa fare (anzi, che nn e' in
grado di farlo), nn la reputerei un grande programmatore. Ricordo che
tutta la comodita' del .NET e' pagata (secondo me pesantemente) in
termini di prestazioni. Cmq da paret mia chiudo qui xche' nn voglio
andare troppo OT.

 perche' non compilare direttamente in codice nativo?
Perche' ci pensa il framework ^^;
L'idea e' che tu con una macchina, che so, BSD (c'e' il framework per BSD,
se non sbaglio), scarichi del codice MSIL fatto da un tizio da Internet, e
alla prima esecuzione viene compilato in BSD nativo, e poi eseguito. Io,
invece, con una macchina Windows, scarico lo stesso codice MSIL, e alla
prima esecuzione mi viene compilato in codice nativo Windows. Lo so, possono
essere entrambe piattaforme Intel (o compatibili), ma le syscall sono
diverse, e non sto a spiegarlo a chi ne sa di piu' (funzioni tipo la
"fopen", o altre dipendenti dal sistema).
Per quello che dentro il framework c'e' un compilatore, anche per chi non
sviluppa^^;
In realta', pero', rimane un po' teoria, nel senso che sta al programmatore
configurare il progetto per usare il JITter in questa maniera.
In questo modo, pero', si ha un po' "il meglio dei due mondi": portabilita'
(a livello MSIL) e prestazioni (dopo la prima compilazione "in loco", a
patto che il JITter sia stato configurato correttamente, non viene piu'
ricompilato).

 wrote in message
news:bfgdv5$kaf$1...@sparta.btinternet.com...

Beh, e' diverso.
Un'interfaccia consente, parlando in termini di OOP stretto, il polimorfismo
ma non l'ereditarieta'.
Poi boh, magari mi sbaglio e sto facendo casino io, ma da quel che ho
capito, puoi "ereditare" da una classe sola, in C#, ma puoi implementare n
interfacce, dove per interfaccia si intende "una serie di metodi virtuali di
una classe".
Ripeto, poi magari sbaglio.
Alcuni considerano utile l'ereditarieta' multipla, altri no, e fin qui va
bene. E' normale avere opinioni discordi, a volte.
Il punto e' che il C++ lascia la scelta, pero', mentre il C# no. E qui
smette di essere una questione di opinioni e diventa una cosa che... beh, te
la prendi e te la infili in saccoccia.
Elric

globale?
Se la classe ti consente di fare tutto ciò che fai con una funzione
globale, con la stessa comodità, per te l'uso dell'una o dell'altra è
indifferente.


la prendi e te la infili in saccoccia.
Non si può ragionare in questo modo: se l'ereditarietà multipla
influenza il lavoro del 10% dei programmatori, allora è ancora una
questione di opinioni.


grado di farlo), nn la reputerei un grande programmatore. 
Saper programmare significa ben altro;  significa aver ben chiari dei
concetti teorici che vanno molto al di là del mero aspetto tecnico di
una deallocazione.  Significa conoscer questi aspetti e saperli
applicare.  E` chiaro che un programmatore che non sappia che, in
certi contesti, è necessario deallocare la memoria e che non sappia
tecnicamente come farlo abbia conseguito un apprendimento solo
parziale degli strumenti che utilizza, ma generalmente i programmatori
imparano a compiere tecnicamente queste operazioni.  Avere un garbage
collector può piacere o non piacere, ma non autorizza a definire chi
lo usa, implicitamente, un "deficiente" (nel senso di "deficere", si
intende).  Per quanto riguarda il discorso sui puntatori, ovviamente
non si può essere d'accordo: i puntatori sono pericolosi, i cast, per
carità, non lo diciamo neppure (i casini nascono proprio quando il
programmatore mette da parte il compilatore dicendogli "alt! fai fare
a me!");  un programmatore serio impara, prima o poi, ad evitarli come
la peste per quanto possibile.  Si è soliti cominciare a programmare
ritenendo chi non usa i puntatori un povero illuso, che non sa come si
programma veramente.  Ci si convince ben presto che è vero l'esatto
contrario.  Poi, ognuno rimane delle proprie idee, anche io non reputo
un degno conoscitore dell'italiano chi usa "nn" al posto di "non".


 andare troppo OT.
Non so quanto le prestazioni siano cosi' inferiori. In qualche caso saranno
inferiori, in qualche altro persino un tantino superiori..... Nella media
certamente un minimo inferiori lo saranno.
Pero' tieni conto che anche il C++ tende ad essere piu' lento del C, se si
usa molto la standard library e si usano funzioni virtuali etc.... Pero' sui
computer di oggi spesso conviene appesantire un poco il programma e renderne
molto piu' facile la scrittura (specialmente in tante persone e per progetti
grossi). Il primo linguaggio di programmazione il Fortran e' spesso piu'
veloce del C e del C++ e del Java etc.... Vuoi dire che il primo linguaggio
sia il migliore?! Vuoi dire che in 40 anni non sia sia fatto nulla di
meglio!? Certo che si e' fatto di meglio! E' che le prestazioni non sono
tutto. Se e' per questo l'assembly e' piu' veloce del C (a patto che chi
programma faccia un compito migliore dell'ottimizzatore del compilatore C).
Ma chi usa assembly per fare progetti grossi?! Nessuno! L'assembly lo usi
solo per piccole e critiche parti del codice (o per interfacciare
l'hardware). Insomma piu' c'e' astrazione piu' il linguaggio e' lento, ma e'
solo grazie alla astrazione che possiamo fare i programmi che facciamo oggi!
(scrivimi tutto office, per dirne uno, in assembly!)
Riguardo all'OT, forse siamo un pelo OT, ma credo che queste discussioni
siano interessanti.
E' appena stato postato il messaggio del gruppo di coordinamento e vedo:
- Confronto tra strumenti per quanto riguarda le funzionalita' o le
prestazioni intese in termini generali
Beh, forse intendono strumenti C++, ma a parte questo stiamo proprio
"parlando di funzionalita' e prestazioni in termini generali" di C++ e C# e
Java etc....
Credo che OT del genere non siano un problema, poi se continuano ad essere
vivi per settimane magari allora meglio fermarli e riprendere a parlare di
C++, visto che questo thread ha 24h .....
Ricordo che che il C++ e' un linguaggio in evoluzione e.... chi lo sa che la
prossima versione non suppori le properties ad esempio, *non credo proprio*,
ma cmq parlarne non credo sia male!
Ad esempio Borland nel 2002 ha proposto di aggiungere le poperties al C++:
http://std.dkuug.dk/JTC1/SC22/WG21/docs/papers/2002/n1384.pdf
Puoi guardare su: 
http://std.dkuug.dk/jtc1/sc22/wg21/
 per vedere questo tipo
di cose.
Tommy

 la prendi e te la infili in saccoccia.
No, ti sbagli! Guardati le interface del C#....... ( o a quanto pare anche
del Delphi).
Tommy

Se si vuole parlare di C# forse e'meglio cercersi un altro gruppo, questo si
chiama: it.comp.lang.c++
I paragoni tra i vari linguaggi credo siano fuori luogo, oltre che inutili.


 fuori luogo, oltre che inutili.
Io non ne sono del tuto convinto! Tanto meno che i paragoni siano unutili,
che sciocchezza e' questa!
Paragonare C++ a C# o a Java puo' essere interessante...
Forse ci sono NG piu' adatti, ma visto che la discussione e' nata qui non
vedo perche' terminarla subito....
Ci sono tanti OT, di tante forme diverse... francamente questa e' tra le
piu' tollerabili.
Se poi vuoi insegnare a postare sui NG, allora impara a quotare sopra e
rispondere sotto. E poi impara a quotare solo quanto inerente. Dopo che
avrai imparato a quotare, a rispettare la netiquette e le regole dei NG
allora ascoltero' un rimprovero del genere con orecchio migliore.
Tommy

 wrote in message
news:bfgogt$qoj$1...@hercules.btinternet.com...


 wrote in message
news:bfgogt$qoj$1...@hercules.btinternet.com...

"The interface keyword declares a reference type that has abstract
members." - MSDN, riguardo alle interfacce in C#.
A 'sto punto, con la keyword "Implements", pure VB6 ha l'ereditarieta'
multipla... ed anche Java (Delphi non lo conosco).
Sembrerebbe che un'interfaccia dichiari un tipo con membri *astratti*, cioe'
l'equivalente delle classi con funzioni virtuali (pure) in C++.
A parte le questioni di istanziazione, che sono un discorso, cmq rimane il
fatto che la classe derivata *deve* implementare di suo alcune funzioni,
cosa che nell'ereditarieta' in senso stretto non succede: io eredito da
"base" tutti i suoi membri (funzioni e variabili) senza doverne dare una mia
versione. Che le funzioni membro virtuali (non necessariamente pure) siano
un'ottima cosa non lo nega nessuno, pero' a me da' un'idea di polimorfismo
("un interfaccia, molti metodi") e non di ereditarieta'.
Poi in C++ in un certo senso c'e' un po' di confusione fra ereditarieta' e
polimorfismo, nel senso: se io "eredito" da una classe base senza funzioni
virtuali una serie di membri, e' ereditarieta'; se "eredito" da una classe
base con funzioni virtuali non pure e' ereditarieta' fino a che non ne
faccio una mia versione nella derivata, nel qual caso e' polimorfismo; se
"eredito" da una classe base con funzioni virtuali pure sto usando il
polimorfismo (cmq la versione base non esiste, e quindi ne usero' una nella
mia derivata).
Il punto e' che in C++ tutto passa dalla stessa forma "class
Derived::[public|private|protected]Base", a prescindere dal fatto che il mio
scopo sia modificare il comportamento di una classe mantenendo invariata
l'interfaccia (polimorfismo) oppure semplicemente descrivere una classe
"specializzata" ( un "sottotipo", per cosi' dire) a partire da una classe
base generica (ereditarieta').
Ho le idee confuse con ereditarieta' e polimorfismo, oppure mi son perso da
qualche altra parte?
Elric

chiama: it.comp.lang.c++
Impara a quotare, per cortesia.  Come si chiama questo gruppo lo so
bene.  A volte i confronti tra linguaggi possono essere tutt'altro che
inutili.


qualche altra parte?
Direi entrambe ;-)


Tommy wrote:

rispondo sotto come vuoi tu, imparando a quotare; 
mi sembra eccessivo postare circa 10 messaggi paragonando c++, Java e C#
tralasciando invece un ottimo spunto di discussione quale la copia
efficiente di oggetti, propria del c++ e sconosciuta dove la memoria viene
gestita in modo automatico.
la faccio breve perche'anche questo messaggio e'inutile.

Tommy wrote:

ragazzi scusate mi e'andato in palla il newsreader,  sembrava che questa
discussione fosse nata da un altro thread, invece no.

 oppure mi son perso da qualche altra parte?
Credo tu le abbia un pochino confuse ;-)
Da come parli sembra che ci possa essere o ereditarieta' o polimorfismo...
invece le due sono cose ben distinte che spesso convivono insieme.
Tommy

 essere portabile.
Intanto il compilatore JIT deve decidere se e quale codice compilare e
quindi compilarlo. Questo un'applicazione gia' compilata non deve
farlo. Se poi, come dicono, ottimizza solo dove serve e' perche' perde
tempo a raccogliere statistiche. Per processi che eseguono a lungo
task ripetitivi e' possibile che lo svantaggio sia ridotto
sensibilmente, per applicazioni interattive, meno.
Ciao,
Nicola

 Direi entrambe ;-)
Direi con l'italiano, piu' che altro ;_;
Elric

 Tommy
Questo lo so.
Altri linguaggi pero' hanno una distinzione molto piu' netta.
Elric

 cosi' male, almeno non cosi' male come me lo immaginavo ;-)
Meglio cosi'.
Ciao,
Nicola

sensibilmente, per applicazioni interattive, meno.
Sui limiti prestazionali, non posso pronunciarmi, non li conosco a
sufficienza.  Per ora mi limito al sentito dire ;-)
-- 
Andrea Laforgia


 sensibilmente, per applicazioni interattive, meno.
Si, sono d'accordo con te.... nella media dei casi un programma che viene
compilato con un just-in-time compiler e' svantaggiato!
Anche se come ho detto in un altro messaggio esiste un JITter che compila al
momento dell'installazione.
Inoltre in casi rari l'ottimizzazione dinamica (nel caso del JITter di
default) potrebbe dare risultati leggermente migliori di quella statica...
Poi ovvio, nella maggior parte dei casi un codice che usa un JIT compiler e'
svantaggiato rispetto ad uno che e' gia' in codice nativo.
Insomma, un JITter offre vantaggi (portabilita') e svantaggi (leggermente
piu' lento).... oggi giorno per la maggior parte delle applicazioni forse
vale la pena di rallentare un minimo a favore della portabilita'. Per altre
applicazioni ovviamente no!
Tommy

quello che in C++ si fa in un modo solo.
Tu ne fai un discorso di banale sintassi e pensi di distinguere le
cose in base ad essa.  Questo ti conduce a conclusioni errate.
Quanto sopra riportato č ovviamente tutto IMHO.
-- 
Andrea Laforgia


>> nella derivata, nel qual caso e' polimorfismo
NO, e' sempre ereditarieta' (o implementare una interfaccia).
Il polimorfismo lo hai solo quando "fai un uso polimorfico". E poi non e'
che quando hai polimorfismo non hai piu' ereditarieta'!
In altre parola CRect eredita sempre da CShape. E' ereditarieta' (non
polimorfismo), poi invece la lista che abbiamo creato e' polimorfica.
Come ho detto nel mio messaggio precedente:


 lunga perche' prenda in mano C# in tempi brevi
Credo sia cosi' per tutti gli appassionati di informatica....
Anche io vorrei impare *tutto* ma non e' possibile. Come ti ho detto
snobbavo C# fino a che mi e' capitato di studiarlo. C++ e' sempre il mio
preferito, ma C# non fa cosi' schifo ;-)
Tommy

 Tommy
Ciaooo!
Disgusting Angel

 
http://groups.yahoo.com/group/delphi_open_manual/
Ciaooo!
Disgusting Angel

La differenza, pour moi, che c'e' fra ereditarieta' multipla ed uso di
interfaccie si spiega bene con questo esempio (letto nn mi ricordo + dove,
non me ne si voglio!! :P) nel derivare da 2 classi (esempio classe badge e
classe codice a barre) si puo' avere gia' completamente funzionante una
classe che rappresenta un badge con codice a barre, mentre ereditando la
classe badge ed implementando l'interfaccia codice a barre sarebbe
necessario riscrivere il codice atto alla gestione del codice a barre nella
nuova classe derivata ( o viceversa...).
Il polimorfismo si ha in entrambi i casi, poiche' la chiamata a funzione nn
sara mai risolta in fase di compilazione, bensi' in fase di esecuzione...
D'altronde il compilatore nn puo' compiere il miracolo di sapere quale
derivazione della classe base stiamo usando! :PP
Sxo di nn aver fatto castronerie e di essere stato chiaro...
Ciaooo!
Disgusting Angel

 Se esistono le "interface", allora non si è del tutto persa.
La differenza fra le due cose e' notevole..
E' vero che in C++ spesso si definiscano classi puramente virtuali il cui
scopo e' solo definire appunto un'interfaccia... ma quando in queta classe
definiamo del codice superiamo il paradigma di interfacce proprio del.NET e,
se nn sbaglio, del Java (qui nn ci scommeto proprio :D)
Ciaooo!
Disgusting Angel

 classe base stiamo usando! :PP
Beh, pare che tu sita parlando di late-binding (detto anche
dynamic-binding). Questo in C++ avviene quando usi la keyword virtual.
Con una interfaccia (classe astratta in C++) la keyword virtual e'
obbligatoria, quindi il late-binding avviene sempre.
Nel caso invece di ereditarieta' multipla da classi non astratte non e'
detto. Se queste non hanno nessun metodo virtuale non si presentera' alcun
late-binding, e al contrario di quello che dici, si presentera' invece lo
static-binding.
Tommy

 ma 1a di tutto una soddisfazione...
Bene, sono contento per te!
Ma questo cosa ha a che fare con il garbage collection e .NET; uno che ha
dei gusti diversi dai tuoi potrebbe divertirsi molto di piu' con C#! Io
conosco tanta gente che trova Java divertente ed il C++ noioso (io
personalmente il contrario). Insomma e' questione di gusti, non capisco
l'utilita' della discussione!
Tommy

curare.
hai un problema di equivalente portata usando un gc (imo), perdi la
possibilità di usare un idioma raii, e quando le eccezioni risalgono
lo stack.. trovo alquanto errorprone dover wrappare tutti i metodi
attraversati dall'eccezione con un blocco try{}catch try{}finally solo
per dover fare un release() ( finalize() o che altro ) sulle risorse.
Onestamente in una situazione simile.. trovo ben più difficile scovare
un simile bug che un errore di allocazione.
sbirish

 pesante
scusami ma il dos e' mono processo ... win 95 no ... quindi avevi pezzi del
kernel che cmq andavano ad eseguirsi per time sharing ecc ...
che confronto e' un os mono processo vs una interfaccia grafica multi tread
???
ciao

 l'utilita' della discussione!
Questo e' ovvio--- io mi sono limitato ad esporre la Mia opinione.. se
qualcuno la pensa diversamente puo' esporla diversamente e se ne puo'
parlare... Sicuramente alla fine tutti avremo le idee piu' chiare!!
Si chiama 'relazionarsi'... :)
Ciaooo!
DisgustingAngel

 kernel che cmq andavano ad eseguirsi per time sharing ecc ...
Ore ce ne si aggiunge un altro.......

 un simile bug che un errore di allocazione.
Già. Alla fine la presenza di un GC introduce più problemi di quanti
dovrebbe risolverne, e causa una maggiore complessità del codice.
D'altra parte la sola necessità di dover introdurre una nuova keyword
(finally) nella gestione degli errori, per cercare di semplificarla un
po' dovrebbe fare pensare...
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 curare.
L'utilizzo dell'idioma raii ti elimina questo problema. Ma obbliga a
pensare. Il GC ti evita di pensare, ma ti complica la vita in altri
modi...


se nn sbaglio, del Java (qui nn ci scommeto proprio :D)
Se implementi del codice, in una classe, è OVVIO che stai andando
oltre il significato di interfaccia (anche con i linguaggi .NET,
analogamente al C++, d'altronde, puoi definire classi vere e proprie
che implementano i metodi).  Le interfacce servono proprio quando si
vuol creare, appunto, solo un'*interfaccia*.
-- 
Andrea Laforgia


 wrote
Si, come dicevo ha i suoi pro e contro....
Tommy

l'allarmismo.
Se sottoponi tutto al "se gestito bene", qualsiasi discorso diventa
inutile.
-- 
Andrea Laforgia


 Ore ce ne si aggiunge un altro.......
?!??
Mi pare abbia fatto una giusta osservazione. DOS dava tutte le risorse ad un
solo processo. Windows95 gestiva un mucchio di cose, tra cui piu' processi,
piu' threads, i servizi in background, le risorse (compresa la grafica)
vengono in qualche modo condivise etc...
Tommy

  ed un nemico per chi ne è capace...
Come ho gia' detto, nella maggior parte dei casi semplifica la vita. Quindi
e' ovviamente amico di chi non sa programmare, ma non credo sia stato
introdotto solo per loro e non credo sia utile solo a loro. Poi come tutte
le cose anch'esso introduce nuove problemi.
Tommy

po' dovrebbe fare pensare...
Che vuoi dire ?


 preferito, ma C# non fa cosi' schifo ;-)
Puo' darsi, ma per il momento preferisco approfondire C++ e Python,
nella speranza di trovare un po' di tempo per sbirciare Haskell e
Smalltalk. E se il progetto su cui lavoro dovesse chiudere, e' molto
facile che mi ritrovi a lavorare in Java.
Ciao,
Nicola

 default) potrebbe dare risultati leggermente migliori di quella statica...
Solo se viene compiuto profiling dell'esecuzione o se il JIT e' in
grado di generare codice specifico per il sistema su cui esegue.
Ciao,
Nicola

 indifferente.
No, non e' la stessa cosa, perche' sono costretto a scrivere
un'impalcatura inutile. E tutte le cose inutili sono, per quanto
magari poco, dannose.
Ciao,
Nicola

 le cose anch'esso introduce nuove problemi.
Utilizzando alcuni linguaggi dotati di GC ho riscontrato che, mentre in
C/C++ o altri linguaggi *senza* GC, se il programma si blocca č colpa
del programmatore, in quelli *con* GC questo non č detto e spesso
dipende, appunto, dal GC che non ha fatto bene il proprio lavoro e ha
permesso alle risorse di andare troppo giů. Insomma, il GC porta anche
problemi, non c'č dubbio, e spesso non risolvibili.
My two cents.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg

 disponibilie su altri sistemi?
Beh, vai a vedere 
www.go-mono.com
Tommy

 vengono in qualche modo condivise etc...
Oki.. sto andando sempre + ot. scusate, non lo faro' +! :DD
Cmq intendevo che continuando a creare controlli che si affiancano si toglie
sempre piu' respiro all'applicazione... solo quello... :)

 inutile.
No.. si torna all'inizio! :)

 sempre piu' respiro all'applicazione... solo quello... :)
se vuoi un'applicazione di respiro vai su sitemi realtime o mono processo
... ma poi non lamentarti se ti devi controllare la memoria ... devi avere
delle librerie apposta, se devi fare tread devi scriverti tu un sistema di
gestione ecc ...
questo nei nuovi so lo ha gia' ... che poi si mangino parte del tempo np ...
tanto mangiano meno dell'1% per sti controlli ... quindi meglio avere gia'
un sistema astratto che doversi ogni volta scriversi un mini so per far
andare un'applicazione ...
io mi ricordo vecchi giochi dos che i matti che li programmavano avevano
scritto mini so interni per memoria gestione overload ecc ... veramente
della gente con le palle che in 640k-1000mb di ram facevano i salti mortali.
ciao

...

Quante distro includono mono?
Quanti S.O. proprietari includono mono?
Quante applicazioni per mono/.net esistono?
Che percentuale delle applicazioni disponibili per windows/linux/ecc.
e' basata su .net?
Come dicevo, .net (e quindi mono) *non esiste*.
Ciao,
Nicola

 soluzione piu' elegante rispetto ai soliti get e set!).
IMHO le properties, unite alla distinzione tra value types e reference types
portano a dei seri problemi di leggibilita` del codice.
Se leggi la seguente riga in C#:
        a.x = b
come fai a sapere cosa succede? Potrebbe essere fatta una copia by-value di
'b', potrebbe essere copiato solo il reference, potrebbe essere chiamata
una procedura per gestire la property, a seconda del tipo di a.x.
Sembra un'aspetto secondario, ma per quella che e` la mia esperienza non lo
e`: gia` in Java questa "feature" crea non pochi problemi, soprattutto ai
principianti.
Personalmente penso che l'ideale sia un linguaggio in cui l'uguale
corrisponde ad un solo significato: ad esempio in Python il segno '='
denota sempre un assegnamento by reference.
Gia` in C++ le cose si complicano: se lo usiamo in una dichiarazione di
variabile puo` denotare il richiamo di un costruttore o di un
costruttore+costruttore per copia; se lo usiamo in una istruzione denota
sempre (per fortuna!) una copia by-value.
In C# ha almeno quattro significati diversi: oltre ai gia` citati
copia-by-value, copia-by-ref e property-set c'e` anche l'inizializzazione
di variabili.
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 d'altronde il polimorfismo non può esistere se non c'è ereditarietà.
non necessariamente. Tra i linguaggi che conosco ce ne sono almeno due che
supportano il polimorfismo anche senza ereditarieta`: uno a tipizzazione
statica, O'Caml, e uno a tipizzazione dinamica, Python.
Inoltre anche Smalltalk rientra nella categoria di cui sopra, anche se devo
ammettere di non conoscerlo.


 troviamo.
se parliamo della "maggioranza dei casi" probabilmente hai ragione. Ma ci
sono casi in cui l'ereditarieta` multipla puo` avere una sua ragione di
esistere: in alcuni casi come utile principio di progettazione OO
(personalmente mi e` capitato qualche caso in cui l'ho trovata utile), in
altri come potente "artificio tecnico" (ad esempio basta guardare quello
che e` riuscito a combinarci Alexandrescu in "Modern C++ Design").


 C++ ne agili come il Python.
condivido in pieno.
Purtroppo nella mia facolta` hanno deciso di puntare molto su Java e quindi
me lo trovo molte volte tra i piedi: sino ad ora la mia opinione e` che
Java (ma anche C#) riesce nell'incredibile intento di combinare gli
svantaggi di entrambi i mondi: la rigitida` della tipizzazione statica e la
scarsa efficienza di quella dinamica.


 fece fuori IBM...
puoi approfondire il discorso? Con il fallimento di IBM di riferisci a OS/2?


 sottostante? 
da quel che ho letto nel thread mi sembra che ci siamo tutti un po'
dimenticati quale e` il vero punto di forza sia della piattaforma Java che
della piattaforma .NET: l'enorme quantita` di librerie standard.
Dal punto di vista del programmatore "poco lungimirante" e ancora di piu` da
quello del management, Java e .NET consentono di ridurre drasticamente i
tempi di sviluppo proprio grazie alla quantita` di "cose gia` fatte" (a
volte bene, altre meno bene).
La mia opinione e` che purtroppo Java e .NET sono due ottime piattaforme
che, per questioni IMHO piu` di marketing che tecniche, sono supportate da
linguaggi mediocri. Ho trovato il *linguaggio Java* (che e` diverso dalla
*piattaforma Java*) decisamente irritante, dato che spesso obbliga il
programmatore ad inutili acrobazie per fare anche le cose piu` semplici;
inoltre alcune scelte IMHO lo hanno reso poco leggibile.
C# forse e` un poco meglio, ma non certo anni luce avanti a Java.
La mediocrita` dei due linguaggi fa si che parte dei vantaggi derivanti
dalla piattaforma vengano "persi per strada", producendo codice poco
leggibile e/o manutenibile.
Se la piattaforma Java supportasse un linguaggio migliore IMHO sarebbe
eccezionale: purtroppo per come e` stata pensata la JVM e` difficile
portare un altro linguaggio su di essa: ci sono riusciti con Jython (che e`
una implementazione di Python per Java), ma e` ancora troppo di nicchia per
essere conosciuto tra il "grande pubblico"; in ogni caso IMHO la
semplicita`, potenza e leggibilita` di Python, unita alla grande quantita`
di librerie di Java lo rendono un linguaggio *estremamente* interessante.
.NET forse e` stato piu` lungimirante, dato che fin da subito si pone come
obbiettivo il supportare piu` linguaggi: pero` quelli disponibili al
momento attuale non sono granche`: C#, 
VB.NET
, managed-C++ (che conosco
poco) IMHO non consentono di fare il salto di qualita`.


 puntatori
puo` anche darsi.
Quel che e` sicuro e` che un buon programmatore deve anche sapere quando e`
utile farlo e quando e` meglio affidarsi alla macchina che lo fa al posto
suo. Nella mia esperienza nella maggior parte dei casi e` meglio affidarsi
alla macchina...


 Come dicevo, .net (e quindi mono) *non esiste*.
Beh, a breve un nostro grosso cliente vedrà pubblicato il suo database 
editoriale tramite un complesso sistema web .net based (C#)... 
-- 
Luc.

...

Per quel che ne so penso che siate l'esempio tipo di chi adottera'
.NET: software house gia' focalizzate su tecnologie Microsoft, magari
con prodotti corposi, per i quali l'aggiornamento tecnologico e' un
elemento importante nel mantenerli all'avanguardia.
Sbaglio?
Ciao,
Nicola

 inoltre alcune scelte IMHO lo hanno reso poco leggibile.
Io continuo a restare perplesso circa la scelta della macchina
virtuale, perlomeno come soluzione universale. Per quanto riguarda
Java sono d'accordo: e' decisamente piu' scomodo del C++ per scrivere
codice con tipizzazione statica, ed e' infinitamente piu' scomodo di
Python per scrivere codice a tipizzazione dinamica.
Ciao,
Nicola

 puoi approfondire il discorso? Con il fallimento di IBM di riferisci a OS/2?
Non so se voi giovani :-) potete ricordare, ma il passaggio al 386 e'
coinciso con l'estremo tentativo di IBM di mantenere il controllo
dell'architettura hardware dei PC, con l'introduzione della
piattaforma PS/2 e del bus Microchannel. In realta' questo si e'
rivelato un errore, perche' il resto dell'industria e' andato da
un'altra parte. Ai tempi IBM era vista come "il grande fratello", ne
piu' ne meno della fama attuale di Microsoft (chi parla piu' di "Big
Blue"?) Piu' o meno nello stesso periodo Microsoft ha abbandonato OS/2
per lanciare Windows 3.x e dare l'avvio al filone NT, che in pochi
anni, approfittando anche delle miopi guerre dei consorzi Unix, si e'
imposto come S.O. per piccoli server.
Ciao,
Nicola

 Sbaglio?
No.
E' un nostro errore? 
-- 
Luc.

 Come dicevo, .net (e quindi mono) *non esiste*.
Le domande sono retoriche...
Quello che penso e' che non puoi essere cosi' convinto che non andra'
mai.... potrebbe essere un fallimento potrebbe non esserlo.
Java esiste da parecchio tempo; .NET no....  Solo il tempo ci dira' la
verita'! Per ora apprezzo la tua opinione, ma come la mia del resto, e' solo
una opinione.
Tommy

 wrote


Ah, Nicola, se hai 2 minuti leggiti questo articolo:
http://www.ondotnet.com/pub/a/dotnet/2001/07/09/icaza.html
(in due pagine).
Con questo non voglio dire nulla. Come ho detto solo il tempo decidera'.
Ci sono persone a cui .NET e C# piacciono, persone a cui non piacciono.
Questo vale anche per tutto il resto ;-) Io non escludo a priori nessuna
delle due possibilita'.....
Tommy

...

No, perche'? Intanto si presume che quelli nella vostra posizione
siano anche quelli per i quali il passaggio a .NET e' meno doloroso e
in secondo luogo avrete valutato che nel passare a .NET avete dei
vantaggi, no?
Ciao,
Nicola

...

Ho letto, ma resto della mia opinione. Se il punto e' che .NET ha
dentro delle cose bellissime, allora e' solo una questione di
opinioni. Io non cambierei i linguaggi che uso con C#, altri si.
Se invece il punto e' che per avere tutte queste bellissime e'
*indispensabile* tecnicamente avere tutta l'infrastruttura allora la
risposta e' no. Si poteva fare tutto senza l'infrastruttura e sono
secondo me in pochissimi, a parte Microsoft, a trarre vantaggio
dall'infrastruttura stessa.
Certo che se nessuno fa cose analoghe senza infrastruttura, chi le
vuole deve prendersi tutto .NET.
Tra parentesi, Icaza si e' accorto che il fatto di andare ciascuno per
la sua strada non e' sempre un vantaggio, cosi' come non e' sempre un
vantaggio dipendere sempre da gente che fa solo quello che gli gira di
fare o quello che gli serve nell'immediato. Che scoperte! D'altro
canto non e' un vantaggio nemeno essere in balia di un unico
fornitore; il punto sara' vedere se la standardizzazione costituira'
un baluardo sufficiente a garantire gli utenti e gli altri fornitori
dall'ingombro di Microsoft.
Ciao,
Nicola

 vantaggi, no?
Si, anche se non sono direttamente coinvolto, ma ho visto che 
programmare server web in C# è molto comodo e molto vicino alla 
programmazione standard che facciamo in VC++. 
-- 
Luc.

 Come ho gia' detto, nella maggior parte dei casi semplifica la vita. 
Il punto è questo. A me pare semplifichino la vita solo a che scrive
codice poco "serio"...
Pensa a come dovresti scrivere questa funzione in Java:
void f()
{
    fstream fs("pippo.txt");
    //codice che fa qualcosa con fs
}   
Ciao.
-- 
BSD is for UNIX lovers -- linux is for Windows haters.

 Che vuoi dire ?
Intendevo dire che la presenza del GC ha reso più complessa la gestione
degli errori, tanto da diventare necessaria l'introduzione di finally
per semplificarla (in particolare per evitare codice ripetuto).


 Purtroppo nella mia facolta` hanno deciso di puntare molto su Java
Scusa il messaggio personale, posso contattarti in privato per farti
alcune domande sulla tua facoltà (informatica a GE, se non erro)?


 alcune domande sulla tua facoltà (informatica a GE, se non erro)?
ehm... avevo provato a scriverti io ma non mi ero accorto che il tuo
indirizzo fosse chiaramente un fake ;-)
Cmq si, contattami pure.


 radice (e questo rende molto piu' potente il polimorfismo ad esempio!).
"A me me pare na strunzata..." - diceva quel comico napoletano -
"Complimenti!".