Newsgroup: it.comp.programmare.win32
Titolo: .NET

Chi mi puo dire cosa ne pensa di .net e cosa nn lo convince ???
Non vorrei un flame bensi una discussione costruttiva.
Tnk
--
Kleidemos

 Chi mi puo dire cosa ne pensa di .net e cosa nn lo convince ???
Perche` ogni settimana posti per chiedere impressioni su C#, poi
C++.Net, ora .NET :P ? E` una curiosita`. Ma dato che la tua e` una domanda
lecita provo a risponderti: a me piace e lo uso quasi tutti i giorni
-- 
Lawrence

 
Sono un tipo curioso e polimorfico( :P ).
Cmq tnk x la tua impressione.
Cose negative ??? Pro???
Tnk
--
Kleidemos

 Cose negative ??? Pro???
Ti ho risposto sul NG microsoft ;-)
-- 
Lawrence



Pro:
la gerarchizzazione degli oggetti, lavoro notevolissimo.
Contro:
Le risorse richieste
Commento finale:
I contro superano x me i pro, uso (vb).net sono su esplicita richiesta del
committente, altrimenti VB6 o C++ (con il mio framework :-))
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) 
despammed.com

Kleidemos ha scritto:

Ciao.
Premetto che anch'io sviluppo, quando necessario, con .NET. Inoltre 
programmo in C++, VB 6, PHP, Lisp, e in passato ho utilizzato anche Delphi.
L'unico Pro che vedo in .NET sta nel fatto che la maggior parte delle 
funzionalità di Windows sono state incapsulate in una gerarchia di classi.
Purtroppo non riesco a trovare altri lati positivi, anche perchè :
- Qualsiasi applicazione di un certo livello (Word, Excel, AutoCAD, 
ecc...), dovrà comunque essere scritta con compilatori C o C++ puro 
(senza framework). Questo ovviamente a causa delle scarse prestazioni 
del framework rispetto ai compilati veri;
- .NET non introduce nulla che non sia possibile realizzare con altri 
linguaggi, con la medesima semplicità;
- .NET non è multipiattaforma. L'unio tentativo di porting è Mono 
(
http://www.go-mono.org
), ma se lo provi ti renderai conto che è 
inutilizzabile per lavori seri;
- la piattaforma .NET è più una politica che non un'innovazione e un 
vero aiuto allo sviluppo di software (per avere un'idea considera 
http://rsoftware.altervista.org/index.php?pagina=articoli/nonet
).
Se poi volessimo addentrarci nello specifico dei maggiori linguaggi 
supportati :
- Il linguaggio C++ è forse quello che ha tratto da .NET i vantaggi 
maggiori. Il linguaggio è sempre quello (ottimo), con lo stesso 
compilatore (ottimo), e con in più la possibilità di utilizzare tutto il 
framework;
- Il linguaggio C# è bello, ma in pratica esiste solo per far 
concorrenza a Java senza fornire effettivi vantaggi rispetto a 
quest'ultimo.(personalmente ritengo C# superfluo);
- Il linguaggio Visual Basic è stato, da un lato potenziato dalla 
gerarchia di classi di .NET, da un'altro è stato complicato proprio 
dalla complessità di queste classi. In poche parole VB ha perso molta 
della semplicità che lo distingueva dagli altri e che lo ha portato ad 
essere uno dei linguaggi più utilizzati. Adesso è un linguaggio 
normalmente complesso (ecco alcuni, piccoli esempi di ciò che intendo 
http://rsoftware.altervista.org/index.php?pagina=articoli/vbnetch
).
In poche parole, ti dirò, avrei preferito il potenziamento dei 
precedenti sistemi (VC, VB), piuttosto che questa finta rivoluzione 
combinata da MS.
Ovviamente, queste sono considerazioni strettamente personali, scaturite 
dalla mia quotidiana esperienza lavorativa.
Ciao.
Roberto Rossi
Web   : 
http://rsoftware.altervista.org

 committente, altrimenti VB6 o C++ (con il mio framework :-))
Potresti illustrarmi perche`? Io non sono molto daccordo... di contro
te ne posso illustrare tanti ma i pro vincono cmq.
-- 
Lawrence



Certamente: dipende tutto dalla tipologia di clienti che hai, nel mio caso
ho aziende con un parco macchine che va dal Pentium 233 con 48 MB di RAM a
PIII e PIV piů carrozzati. Una soluzione .Net sui primi pc per i miei test
e' da scartare viste le risorse richieste.
Ho scritto dei post in passato dove ho riassunto alcuni semplici test fatti
con 
vb.net
: in sintesi un programma .Net che apre un form *vuoto*, senza
fare altro, consuma quasi 10 MB di memoria. Un'altra instanza dello stesso
programma => altri 10 MB.
Il mio cliente medio non ha intenzione di rinnovare il parco macchine
perche' i programmi che usano (Outlook Express, Word e un gestionale)
girano benissimo. Se arrivassi io e dicessi che devono cambiare n pc perché
i miei programmi .Net sono esosi in termini di richieste rischierei di
perdere le commesse.
Questo mi sembra il "contro" piu' potente di tutti :-/
Ripeto, non critico l'idea in se di .Net, ma come č stata implementata...
Tutto un altro discorso invece su ASP.net, che ritengo mooolto piů
praticabile.
Anche se forse č un po' OT elenca i pro che hai riscontrato tu sul campo, č
un valido scambio di idee.
Ciao !


 dalla mia quotidiana esperienza lavorativa.
Ma certo, e` sempre utile confrontarsi.
-- 
Lawrence

 un valido scambio di idee.
Allora, io sono uno sviluppatore piuttosto giovane (sono ancora a quota
20, quindi non faccio molto testo in quanto ad esperto sul campo avendo
lavorato in due progetti, uno .NET e uno Python) ma a me .NET piace, ho
avuto la fortuna di collaborare per un'azienda l'anno scorso che
praticamente faceva totalmente roba su .NET (dalla beta mi sembra) anche
se a dire il vero era piu` 
ASP.NET
 che il resto... ma mi ha permesso lo
stesso di sporcarmi le mani con questa tecnologia. Io, e non sono di certo
il tipo che fa finta di niente, sono uno di quelli che appena trova un
difetto lo fa notare (se hai mai seguito il mio blog o miei post sui NG
della Microsoft, ma ne dubito dato che non sono una celebrita` da seguire
:P, ti sarai accorto che ho rotto le palle parecchio per questo e
quello). Tutto sommato .NET e` una tecnologia che sta ancora in una
situazione post 1.0 (diciamo che la 1.1 e` una service release) e che a
mio avviso con la 2.0 ci sara` il sano miglioramento che chi sviluppa con
.NET attende. Riguardo al mercato in generale sono ancora un po` dubbioso,
io non ho fretta di lavorare perche` ho ancora la fortuna (o la sfortuna)
di fare lo studente e potermi permettere di guardarmi intorno e scegliere
le tecnologie a mio piacimento ma... .NET non sembra attecchire, vuoi per
diffidenza verso MS che in passato ha fatto varie volte cambi di rotta,
vuoi per (anche se non amo la cosa) lo stradominio di Java e di PHP sul
web, vuoi per l'esplosione dell'Open source (il mercato all'uscita di Java
era un po` diverso IMHO), vuoi per tanti altri motivi...
Ho idea che pero` questa cosa cambiera` col passare del tempo (gia` ora un
po` di offerte di lavoro .NET centriche ci sono) e soprattutto con la
messa in commercio Longhorn che dovra` avere come motivetto
d'accompagnamento: "no .NET? Ahiahiai :P", semplicemente perche` le
applicazioni win32 continueranno a girare ma probabilmente verranno
deprecate col passare del tempo e sempre meno supportate su quel SO.
ciao!
-- 
Lawrence

 non uscira` nemmeno in versione 32 bit)
cioe': uscira' direttamente a 64 bit? ...ma l'hardware sara' gia' 
pronto, a un costo abbordabile per l'utente medio?
bye
dan

 pronto, a un costo abbordabile per l'utente medio?
Beh ho sentito per vie non ufficiali che AMD potrebbe anche smettere di
produrre CPU a 32 bit tra un po`.. ad ogni modo sara` il mercato a dircelo.
Sicuramente Longhorn sull'hw attuale sarebbe una chiavica
-- 
Lawrence

VB6... ma a mio avviso avrebbero fatto a mettere solo C# e C++.NET
Concordo.
-- 
ciao, hal

 
Sono diversi anni che faccio questo mestiere e mi pare che le intenzioni
di MS siano sempre le stesse: tirare fuori più soldi possibili dai suoi
clienti, sviluppatori inclusi, aumentando il controllo su di loro e 
sulle loro scelte.
Faccio sempre più fatica a capire cosa impedisca a MS di realizzare
strumenti veramente utili e innovativi. Evidentemente non sono proprio 
capaci di fare cose semplici e funzionanti, e quando le fanno, invece di 
migliorarle, le disfano.
Voglio lasciarti con una domanda. NET è disponibile oramai da anni, 
dove sono le applicazioni ?  Chi sviluppa con NET e cosa ?
Così a occhio mi pare che non sia stato proprio un 'successone'. 
Certamente, prima o poi tutti gli sviluppatori Windows saranno costretti 
ad utilizzarlo, ma credo proprio che lo sviluppo di software non sarà 
affatto diverso da quello che è ora.


 programma => altri 10 MB.
La mia situazione e' simile alla tua, con la differenza che ho pure
un sacco di installazioni su roba industriale che va supportata in
configurazioni per cui .Net non e' proponibile.
Se dovessi passare *ora* a .Net dovrei comunque fare il backporting da .Net
ai sorgenti "vecchi" per mantenere allineata l'offerta sia .Net che non.
Era da tempo che valutavo la possibilita di lasciare VB6 per qualcosa
piu multipiattaforma (che almeno oltre a Windows supporti Linux) ed e' quel
che intendo fare.
In ogni caso NON INTENDO ASSOLUTAMENTE mollare la palla-al-piede-VB6
per passare alla palla-al-piede-.Net (perche quello sono in ultima analisi)
e per questo ho gia escluso VB.Net e C#.
Non intendo fare tutta quella fatica per ritrovarmi al punto di prima.
Il problema e' che non ho ancora trovato una soluzione "completa"
(librerie multipiattaforma, IDE e tool RAD) che sia multipiattaforma
e sufficientemente completa/affidabile su cui puntare.
L. Micheletto

 esempio, il C++.
Ecco perche` puntano sul C# che grazie a Mono teoricamente potrebbe
colmare quel gap
ciao!
-- 
Lawrence

 e sufficientemente completa/affidabile su cui puntare.
Un solo nome: Python
ciao
-- 
Lawrence

 software non sarà affatto diverso da quello che è ora.
Staremo a vedere... io intanto continuo a studiare ;-)
-- 
Lawrence

 Sicuramente Longhorn sull'hw attuale sarebbe una chiavica
:)
Beh, allora speriamo di poter accedere quanto prima ad hw a 64 bit ad un 
prezzo accessibile.
Bye
Dan

In article <8765et9...@mobile.foo>, 
ra...@dot.com
 says...

Python ha la semplicita' e produttivita' di VB6? Non lo conosco molto 
come linguaggio...ma mi pare di capire sia piu' complesso di VB6, e il 
drag-and-drop dei componenti per comporre GUI in poco tempo non sia alla 
pari di quanto disponibile in VB6... correggimi se sbaglio (e spero di 
sbagliare, perche' in tal caso Python sarebbe un'ottima scelta).
Riguardo il discorso iniziale del post, circa il multipiattaforma, IDE, 
ecc., mi pare che Java sia, come noto, multipiattaforma, cosi' come le 
sue librerie; inoltre mi pare ci siano IDE free tipo "NetBeans".
Cosa non andrebbe? [forse non e' usabile in ambito industriale?]
Ciao
Dan

 Cosa non andrebbe? [forse non e' usabile in ambito industriale?]
E` linguaggio Java che non va ;-)
-- 
Lawrence

 E` linguaggio Java che non va ;-)
:-) Beh, sinceramente a me Java piace :) Non ci farei un motore 3D, per 
quello userei C++...pero' il bello di Java e' che ti toglie un sacco di 
complessita' del C++ (che in altri casi e' invece utile, es. quando hai 
bisogno di un controllo "fine" per le performance). Insomma, sono del 
parere che per ogni problema da risolvere c'e' uno o piu' linguaggi 
piu' adatti rispetto ad altri per quel particolare problema.
Bye
Dan

 piu' adatti rispetto ad altri per quel particolare problema.
Io sono anche del parere che non tutti i linguaggi vadano bene per un
determinato problema. O comunque uno sia piu` indicato di altri.
-- 
Lawrence

 
Si, su questo punto concordiamo pienamente. Al di la di tutto, 'staremo 
a vedere', e naturalmente continueremo sempre a studiare...
Grazie per la chiacchierata.


 determinato problema. O comunque uno sia piu` indicato di altri.
praticamente siamo dello stesso parere :-)

Lawrence Oluyede wrote:

Quello e' "solo" il linguaggio piu parecchie librerie, ma ad esempio
per quel che riguarda la GUI multipiattaforma bisogna minimo usare
wxPython e per l'IDE non ne ho vista una sufficientemente convincente.
Visto che il C/C++ mi serve comunque a quel punto diventerebbe
interessante usare wxWindows invece di usare due linguaggi diversi
(con i relativi problemi di debug), ma anche li manca l'IDE.
A quel punto si potrebbe fare un pensierino riguardo
Java + Eclipse + Eclipse CDT + SWT e Mingw/GCC
(SWT per la gui, Eclipse come IDE per Java e C/C++, Mingw/GCC come
  compilatore C/C++ per le parti in C/C++).
Ecc. ecc.
Ci sono molte altre opzioni che sono "quasi" buone, persino ad esempio
DrScheme (
www.drscheme.org
)
[N.B. Non sto scherzando, DrScheme come ambiente per imparare
       le basi della programmazione e' una perla rara, anche perche
       e' accoppiato ad un libro di testo ben fatto; ma e' utilizzabile
       anche per realizzare roba "seria" ]
L. Micheletto

 Grazie per la chiacchierata.
Grazie anche a te per non averla trasformata in un flame
(cosa che succede normalmente in altri NG :P)
-- 
Lawrence

 Roberto Rossi
-- 
.A
UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
Read my blog at: 
http://www.ugidotnet.org/4.blog


Ti dirò: nel mercato "finance" .NET sta riscuotendo un grande successo, e
anche le "telco" stanno iniziando a rispondere. La realtà è che .NET sta
avendo successo nel "back-end" (vedi: 
http://webservices.tiscali.com
), e
questo ne rende l'adozione meno visibile, ma non per qsto inesistente. E poi
AFAIK MS ormai punta decisamente al mercato enterprise (anche se Longhorn e
Orcas torneranno a strizzare l'occhio al mondo "client")


Quindi in definitiva, mi consigliate di impararmi qualcosa sul .net per 
nn rimanere troppo indietro?
P.S: complimenti x il livello della discussione e per nn averla portata 
a un flame
--
Kleidemos

 rimanere troppo indietro?
Se i tuoi interessi sfiorano in qualche modo il mondo Windows direi di si.
-- 
Lawrence

 programma => altri 10 MB.
Non ricordo questa tua analisi. Sei sicuro che fosse un'occupazione
effettiva? Come l'hai misurata? Il task manager e` sostanzialmente
inutile per capire quanta memoria fisica venga occupata da una singola
applicazione, dato che quando si parla di memoria virtuale bisogna
considerare un sacco di cose (la condivisione della memoria fisica
tramite il copy on write, la "prenotazione" della memoria, la cache per
i file...).
In altre parole, a botte di 10 MB riuscivi a esaurire la memoria fisica
e a far cominciare lo swap pesante? :)
-- 
Lorenzo

 
Non dubito che qualcuno oggi utilizzi .NET, anzi sono certo che alcune 
aziende lo usano e ne sono soddisfatte, ti dirò di più, nei prossimi 
anni, sono sicuro che .NET arriverà su tutti i PC (almeno quelli nuovi) 
e, come faccio io oggi, la maggior parte dei programmatori lo studierà e 
lo utilizzerà, sono però altrettando convinto .NET non è, e non sarà, il 
"sistema di sviluppo scelto da milioni di programmatori e di aziende" ma 
sarà semplicemente il "sistema di sviluppo imposto a milioni di 
programmatori e aziende".
Questo semplicemente perchè non contiene nulla di veramente innovativo. 
E per me, le innovazioni, sono quelle che ti fanno scivere applicazioni 
in minor tempo, in manierà più semplice e in modo più efficiente, 
ottenendo risultati migliori rispetto al passato. Al contrario .NET ci 
da cose già viste. Del resto, considerando gli anni passati dal suo 
rilascio, se non fosse così e se contenesse vere rivoluzioni,  io oggi 
svilupperei solo con .NET. Invece sviluppo con VC6, VB6, 
VB.NET
, ASP, 
VBA, PHP e Lisp.
Comunque sia, come diceva 'Lawrence' :
"Staremo a vedere... io intanto continuo a studiare"



"Gli anni?" Guarda che .NET è disponibile ufficialmente da _meno_ di due
anni... Non mi sembra che altre tecnologie abbiano avuto una adozione
altrettanto rapida...



...mi spiegheresti che vuol dire "Senior Architect"? ...vedo che spesso 
ci sono titoli come Developer, Software Engineer, Software Architect... 
ma sono sinonimi o ci sono differenze sostanziali?
TNX
[e scusa l'OT :-) ]
Ciao,
Dan

 ottimizzando per quella particolare CPU?? Funziona cosi', o sbaglio?
Si, in .NET il jit compiler ottimizza per la CPU che ha sotto, teoricamente
puoi usare anche il precompilatore ngen.exe
-- 
Lawrence

 
Davvero??
E incluso nel framework???
Cmq ho deciso...........mi studio il C# e uso #Develop su framework 
1.1............... vedremo poi se il linguaggio con la rev 2.0 sara 
divrerso :D
--
Kleidemos

 
Allora è meglio che ti decidi. Prima non avevi detto "NET non è comodo"?
Comunque, l'importante è crederci!
Grazie per l'illuminante conversazione.
Ciao

   rispetto ai compilati veri;
puoi dimostrarlo?
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.5. C, C++ and ASM developers
                               and beta testers are welcome!

 innovativo. 
non ti dispiacerà nominare un suo equivalente, quindi


 divrerso :D
Questo e` link alle specifiche di C#2.0 cosi puoi constatare con
mano:
http://download.microsoft.com/download/8/1/6/81682478-4018-48fe-9e5e-f87a44af3db9/SpecificationVer2.doc
-- 
Lawrence

 
Per quanto riguarda equivalenti, cioè ambienti che ti permettono di 
sviluppare le stesse applicazioni con la medesima semplicità, inizierei 
certamente da Java, e perchè no, proseguirei con Python (che tra le 
altre cose è anche più semplice da apprendere).
Se poi volessimo fare come si fa quando si parla di NET (parlando al 
futuro). Nei prossimi anni NET si confronterà anche con PHP.
So perfettamente che di solito non si dovrebbero confrontare linguaggi 
di scripting con compilati, però credo che quando arriveremo ad avare 
computer abbastanza potenti per far funzionare ambienti CAD scritti con 
.NET, potremo anche scrivere CAD con Java, Python o PHP.
Ovviamente non sarete dello stesso parere, è non mi meraviglio, visto 
che trattate questo sistema come il risolutore di tutti i vostri problemi.
Comunque sia, da tutti i discorsi che abbiamo fatto, si capisce 
benissimo che non esiste qualcosa di NET che lo avvantaggia in maniera 
chiara e decisiva su tutti gli altri, come tutti è più avanti in alcuni 
aspetti e più indietro in altri.
Gira e rigira, l'unico aspetto che lo avvantaggia su tutti, è l'azienda 
che gli sta dietro.
Ciao
Roberto

 futuro). Nei prossimi anni NET si confronterà anche con PHP.
.NET con PHP!?!?! J2EE mi sta bene, Python in parte mi sta bene
ma PHP e` un obbrobbrio a cui recentemente hanno appiccicato gli oggetti
Quasi peggio della programmazione ad oggetti in perl
ciao!
-- 
Lawrence

 obbrobbrio a cui recentemente hanno appiccicato gli oggetti
  ^^^^^^^^^^
notare lo sprecarsi di "b" :P
-- 
Lawrence


ciao


 paragonabile a quello della versione unmanaged.
confermo, ci ho giocato per mesi e la velocità è identica. E' molto più 
lento della versione commerciale, ma è perchè han dovuto disattivare le 
ottimizzazioni speciali per la piattaforma Intel (scritte in assembly e 
ovviamente non portabili)


 Non vorrei un flame bensi una discussione costruttiva.
Beh direi che ti hanno QUASI accontentato... :-)
Per parte mia, il .NET non l'ho ancora mai visto nè usato,
però ho scoperto or ora che il client eMulePlus 1.j che uso
è scritto in C++ e "puntoNET" e... infatti nonostante usi
non più del 4-5% di CPU si "impunta" spesso e volentieri
bloccando il PC per qualche istante ogni volta che con più
di tre applicazioni diverse faccio alt-tab fra l'una e l'altra.
Inoltre con applicazioni di calcolo intensivo "litiga" di brutto;
se lancio, per esempio, una conversione DivX insieme al Mulo
con la stessa priorità non va più niente: il PC ci mette ere
geologiche a rispondere alla tastiera (lasciamo perdere il
mouse) e nessuno dei due programmi va avanti di un millimetro.
Se li metto in classi di priorità diverse invece va tutto
abbastanza liscio (ma ogni tanto qualche cornata ancora se
la scambiano...)
Non capivo perchè cacchio lo facesse mai, adesso forse sì :-\
eMulePlus occupa solo 26MB in RAM, a sentire Task Manager,
però in cambio apre migliaia (letteralmente) di connessioni
internet contemporanee.
Tieni presente che ho un Athlon 1700, 512MB RAM e due HD per
complessivi 140GB in linea (40GB liberi) e gli swapfile se
li gestisce Windows per conto suo, quindi di spazio ne ha
a volontà. Ho l'ADSL, quindi una linea veloce. Insomma il
mio PC non è propriamente una carriola. Eppure...

 Come fa MS ad impedire a chiunque di implementare uno standard ISO? :-D
Ma le parti di .Net "standardizzate" sono solo una parte
del sistema completo, senza contare che nulla e' assicurato riguardo
le future estensioni.
Per esempio oltre al formato CIL e' possibile inserire una rappresentazione
alternativa (es: in formato SSA in modo da migliorare le prestazioni
del compilatore JIT attuale e la futura "compilazione in fase di
installazione") ed anche se il supporto per il "vecchio" CIL venisse
garantito le prestazioni ne risentirebbero.
L'alternativa migliore sarebbe lo sviluppo di una piattaforma
*veramente* aperta, che tenga conto sin dal principio anche delle
esigenze di chi non sviluppa solo normali applicazioni per desktop
e server (es: livelli "stratificati" per complessita e funzionalita
crescenti di API accessibili da piu linguaggi, *INCLUSO* il C, supporto
per la compilazione all'installazione e per la finalizzazione su memoria 
read-only, ecc. ecc.).
Purtroppo le probabilita che si sviluppi qualcosa di simile sono
assai basse.
L. Micheletto

 internet contemporanee.
Questo mi sembra un problema... si... ma non imputabile a .NET.
;-)
-- 
Lawrence

 qualche brevetto ?
la CLI è stata depositata all'ecma e tutti possono attingere:
http://msdn.microsoft.com/net/ecma/
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/deicazainterview.asp
Non per niente Rotor (la versione freeware del framework) è fornita in
sorgenti qui:
http://www.microsoft.com/downloads/details.aspx?FamilyId=3A1C93FA-7462-47D0-8E56-8DD34C6292F0&displaylang=en
Vedremo se i concorrenti saranno almeno tanto bravi quanto MS a creare un
framework alternativo (e lo spero di cuore).
Spero che non facciano la figuraccia che ha fatto SUN con la sua virtual
machine. Ogni giorno mi rompono l'anima per tutti i maledetti applet che
prima funzionavano e da quando abbiamo installato quella di SUN non solo non
funziona più, ma manda pure in crash la shell.
-- 
Raffaele Rialdi
UGIdotNET - User Group Italiano .NET  
http://www.ugidotnet.org
Weblog: 
http://www.ugidotnet.org/2082.blog

 read-only, ecc. ecc.).
IMHO Il C non avrebbe senso perchč Il framework č totalmente object
oriented. Il C non ha neppure gli statement che permetterebbero un simile
approccio. Creare delle estensioni come č stato fatto per C++
significherebbe stravolgere il linguaggio e questo non avrebbe senso.
Il C č un gran linguaggio che trova ancora molto spazio per esempio per la
programmazione di microcontrollori.
Non ho capito bene il resto del tuo discorso, ma con CodeDom puoi emettere
al runtime del codice, compilarlo e creare degli assembly (i file binari di
dotnet).
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 - 
http://italy.mvps.org
UGIdotNET - User Group Italiano .NET  
http://www.ugidotnet.org
Weblog: 
http://www.ugidotnet.org/2082.blog

 e a far cominciare lo swap pesante? :)
Mi ha tolto le parole dalla tastiera ;-)
Aggiungo solo che quando il garbage collector si accorge che la memoria c'è
e non è reclamata da altri applicativi, lui la tiene prenotata per
l'applicazione anche se in quel momento no la sta usando. L'operazione di
allocazione/disallocazione è costosa e se può essere evitata è meglio (il
tipico caso è un app che fa da viewer di bitmap: quando ne chiudo una per
aprire la successiva, perchè buttare via la ram appena usata se la dovrò
riallocare?).
-- 
Raffaele Rialdi


 dotnet).
Intendo che se si vuole un vero "sistema universale" il codice portabile
dovrebbe essere anche crosscompilabile on-demand
Es: Trasferisci&installi  un applicazione dal pc allo smartphone
     e questa viene crosscompilata al volo visto che lo smartphone
     non ha tutto il runtime e magari neppure tutte le librerie necessarie
     (vengono trasferite on-demand in forma rilocabile durante
      la crosscompilazione/installazione oppure vengono linkate
      staticamente con l'applicazione).
Sempre per avere un "sistema universale" bisogna prevedere ad esempio
per la GUI vari "strati" di funzionalita (es: livello minimale valido
dai display solo testo in su, widget/controlli "minimalisti" in cui
il look&feel e' controllato dal runtime in cui girano, widget/controlli
"complessi" ecc. ecc.).
Non si tratta di roba difficile da implementare se ci si pensa fin
dal principio, si tratta invece di una cosa incasinatissima
se si fa come Sun con Java (sistema con troppa roba "da desktop e da
server" e poi ri-ristretto per PDA e cellulari) o peggio
ancora come MS con .Net (sistema pensato per essere legato a doppio
filo con Windows e solo con windows e poi "ristretto" nel
mini-bloatware chiamato "framework compatto").
L. Micheletto

       staticamente con l'applicazione).
Ci sono cose che non hanno senso di esistere su certi device, altre che
presuppongono un approccio diverso anche nella progettazione della UI (un
bel form 800x600 su uno smartphone, uh?). Negli US è già uscito SPOT,
l'orologio da polso con il compact framework. Che senso avrebbe una
crosscompilazione per un device così diverso da un pc?
Personalmente non credo neanche nei sistemi universali ma questa è solo la
mia opinione.


 mia opinione.
Per questo il mio ipotetico "sistema universale" dovrebbe disporre
di "API stratificate" (in realta anche partizionate per funzionalita)
supporto alla crosscompilazione "in fase di installazione", ecc. ecc.
Servirebbe per generare al volo un "sistema specializzato"
(su un sistema embedded, uno smarphone o altro) a partire da un
"sistema universale" (che gira su un desktop oppure su un server).
Queste cose vengono gia fatte (in larga misura manualmente) ed
automatizzarle non richiederebbe uno sforzo tanto grande
(a patto di *non* lasciare la cosa in mano a gente che non ha abbastanza
  esperienza in tale ambito, per ora sia Sun che Microsoft
  nel settore embedded hanno dimostrato di essere dei
  "mangia brioches" che non sanno come la gente si guadagna il pane).
L. Micheletto

 Ho l'ADSL, quindi una linea veloce.
quindi eMule apre uno sfracello di connessioni, tonno


 Cambiano i termini del problema, ma il problema resta.
Ripeto che è necessario minimizzare i problemi. Non credo alle soluzioni
'definitive', 'universali' o quant'altro. Sarò ben felice di apprezzarle se
verranno fuori. Non ho pregiudizi.


 con i programmi managed ciccia
Non so se la tua affermazione è in riferimento alla distribuzione dei thread
o dell'uso di memoria.
* Per i thread, il thread pool del framework è nato per ottimizzare i tempi
di esecuzione e ne hai il pieno controllo.
* Per la memoria, sei sempre libero di usare la SetProcessWorkingSetSize
anche in programmi managed.
Vale sempre il discorso che farlo (sia in applicativi managed che unmanaged)
è ***svantaggioso*** (se non in pochi casi dove sai che certa memoria non
verrà più usata). Ecco i perchè:
http://groups.google.com/groups?q=SetProcessWorkingSetSize+group:microsoft.public.it.dotnet.*&hl=en&lr=&ie=UTF-8&group=microsoft.public.it.dotnet.*&selm=7ffde196-bd3f-4392-adfe-159cf7d5cef6%40UGI28293&rnum=2
Se poi vuoi fare profiling sul processo managed lo puoi fare. Con
performance monitor (o altro profiler che fa uso dei perf counter) puoi
monitorare totalmente l'attività del CLR. Con process explorer di
Russinovich ti da un altro bel pacchetto di info sul processo managed che
sta girarndo.


 e a far cominciare lo swap pesante? :)
Con 512 MB no ma su un pc non proprio recente (come mi capita di trovarne
ancora dai miei clienti, tipo PIII con 128 MB) credo non ci voglia molto...
Ciao
Stefano "HappyMan" (Lake Maggiore - Italy)
-- 
The Personal Framework for Object Oriented Windows Development (Win32)
http://www.sgr.info
Email happyman69 (at) 
despammed.com


La prova che devi fare (che è poi quella che hanno utilizzato allo scorso
TechEd per una demo) è questa:
1. scrivi un app che carica una serie di bitmap e li visualizza.
2. la lanci e carichi dei bitmap molto (ma veramente molto) pesanti).
3. Poi chiudi i bitmap con Dispose e lasci aperta l'applicazione
4. La memoria non diminuisce
5. ripeti i punti 2 e 3 (o anche con un 'altra applicazione pesante) finchè
non esaurisci la memoria
6. A questo punto il GC cominicia a lasciare memoria libera per chi ne fa
veramente uso. Lo swap non avviene se la memoria che occupi non è veramente
necessaria.


 quindi eMule apre uno sfracello di connessioni, tonno
Tonno sarą tuo nonno