Newsgroup: it.comp.programmare.win32
Titolo: Imparare Microsoft Visual C++ 6.0

ciao a tutti,
vorrei imparare a programmare un'applicazione windows utilizzando Visual
Studio 6.0 (e' l'ambiente di sviluppo che dovrei usare a breve al
lavoro..). Ho una buona infarinatura di C, ma nel mio lavoro ho sempre e
solo usato ambienti di programmazione "ad alto livello" (Simulink, Lbview,
ecc.).
 
Qualcuno mi sa suggerire libri, links, tutorials, ecc. che possano
aiutarmi? In rete si trova cosi' tanto materiale che, alla fine, sto
facendo confusione.. ;-)
Grazie dell'attenzione!!
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Grazie dell'attenzione!!
Considerato che VC6 è obsoleto di quasi 4 versioni, il cui compilatore non è 
standard ISO, il cui IDE era bello ma immensamente meno potente a quanto 
disponibile oggi, fatti un regalo e scaricati una di queste:
- VC2005 express (gratuita)
- VS2008 Beta 2 (eventualmente in virtual machine se preferisci) il cui IDE 
di VC++ è ancora migliorato. La versione full è gratuita fino al rilascio 
della RTM. Dopo sarà gratuita solo la versione express.
Per quanto poco tu lo possa sfruttare beneficerai almeno dello standard ISO 
C++ che ti garantisce di poter compilare librerie diffuse come Loki o Boost.
Per quanto riguarda il linguaggio, se ti interessa principalmente 
programmare per Windows, ti consiglio caldamente di considerare da subito 
l'uso di VC++/CLI dove "CLI" sono delle estensioni al linguaggio C++ per 
poter usare il Framework. Con tutto quello che c'è nel framework risparmi 
parecchio tempo e puoi usare in modo misto C# e C++, anche in un singolo 
file eseguibile.
Se non hai conoscenze di C++, imho la partenza è sempre il classico 
Strustrup. Per le estensioni CLI sono disponibili alcuni libri che puoi 
trovare facilmente su Amazon.
-- 
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://blogs.ugidotnet.org/raffaele

Urca!! Grazie della risposta completa ed esauriente! Mi informo sui link
che mi hai fornito e ,se mi permetti, sicuramente ti faro' ancora qualche
domanda.
Grazie ancora!
Raffaele Rialdi [MVP] ha scritto:





-- 


 diffuse come Loki o Boost.
Purtroppo il supporto dello standard potrebbe anche creare rogne 
ricompilando codice che sotto VC 6 funzionava... (la famigerata 
dichiarazione del contatore nel for, ad esempio). Ho litigato con 
codice del genere (su Windows CE) proprio l'altro giorno....
Ovviamente non si tratta di problemi insormontabili, ma se l'azienda 
ha deciso di evitarli, non credo che il nostro amico, da neo-
assunto, possa avere il "peso" contrattuale per cambiare queste 
decisioni. Al limite potrà studiarsi per conto suo .NET e l'ambiente 
VS2005 e cambiare lavoro :)
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 VS2005 e cambiare lavoro :)
eheh ... meglio però saperlo prima di imparare un ambiente che oggi è già da 
buttare :)


 Grazie ancora!
Prego!
Dai un occhio anche a questo link:
http://msdn2.microsoft.com/en-us/express/future/bb421472.aspx


Grazie della risposta!
In effetti mi intriga molto VC2005 pero', in effetti, in azienda c'e'
ancora Visual Studio e quindi preferirei concenrarmi su quest'ambiente.
Si, "Thinking in C++" l'ho scaricato e mi sembra ottimo, per essere un
libro gratuito..
Provo a vedere i tutorial che mi hai consigliato.
Sullo sviluppo di applicazioni con Visual Studio sei a conoscenza di
qualche tutorial utile?
Grazie ancora per le informazioni!
 
Valter Minute ha scritto:







-- 


Grazie del tuo intervento!
Se posso permettermi, prima di arrivare a concetti molto complicati,
dovrei prima pasticciare un po' con il C++ e imparare le nozioni piu'
semplici. Per fare questo mi serve un ambiente in cui scrivere il codice e
compilare il tutto. Visual Studio ce l'ho installato e ho la maledetta
paura di doverlo disinstallare se voglio mettere VC2005 Express o cose
simili.. Quindi credo che partiro' da questo "vecchietto" e poi vedo se
riesco a fare il passaggio a a qualcosa di piu' nuovo. 
Concordo con tutti coloro che mi hanno risposto: credo sia importante
conoscere un po' di rudimenti sul sistema operativo Windows se voglio fare
le cose per bene. 
Grazie ancora dell'aiuto!!


 riposto.
Potresti spiegare meglio che mi interessa (magari un link)?
Grazie
GM

frequentava questi lidi), oppure il "tomone" di petzold.
Sì, ottimi. C'è da dire che partono veramente *veramente* dal basso.

compilare il tutto. 
Se ne vuoi uno gratuito e open-source: 
www.codeblocks.org
Oltretutto è basato su gcc, il che è una buona garanzia in termini di
conformità allo standard ISO C++ (il gcc sta addirittura anticipando
caratteristiche che saranno presenti nel C++0x prossimo venturo).

 Grazie ancora dell'aiuto!!
Buono studio :)


 caratteristiche che saranno presenti nel C++0x prossimo venturo).
Lungi da me aprire flame, ma in quanto a stabilità il GCC mi ha dato non 
pochi problem, per esempio sul parsing.
Sorgenti in cui espressioni come a=b=c; non vengono compilati nelle versioni 
più recenti dei tool mentre in giro di sorgenti con espressioni come queste 
(a partire da Linux stesso) è pieno.
Con tutto ciò nessuno vuol togliere nulla agli indiscutilibili meriti.


 Potresti spiegare meglio che mi interessa (magari un link)?
WPF permette di sviluppare interfacce grafiche con una struttura totalmente 
nuova, che si appoggia a Directx, che è totalmente avulsa dai concetti di 
User32 (niente hwnd e tutto il resto), che ha una struttura object oriented 
estremamente versatile e in grado di gestire nativamente 2D e 3D. Inoltre è 
basato su concetti vettoriali per cui è re-sizable a piacere supportando 
così anche i monitor high-DPI, (e molto altro ancora).
Uno dei progetti in cui sono coinvolto è un sistema di automazione dove 
l'operatore ha un visione 3D del sistema, può ruotarlo, zoomarlo, vedere i 
dettagli in tempo reale. Realizzare custom control "realistici" con WPF è 
molto semplice ed estremamente potente.
Se con win32 saresti diventato pazzo a fare controlli che mimino il pannello 
sinottico, con WPF è molto più semplice e la grafica viene totalmente 
scaricata su DirectX quindi sulla GPU, permettendo ad un PC di prestazioni 
medio basse di fare un lavoro più egregio di quanto oggi può fare con 
GDI/GDI+
Se cerchi in giro di WPF trovi una tonnellata di esempi, demo e materiale 
vario.
Puoi partire da qui che è la "home" sia di WPF che di Windows forms:
http://windowsclient.com/Default.aspx
Ciao


Sorgenti in cui espressioni come a=b=c; non vengono compilati
Mi sembra molto molto strano. Sei in grado di riportare la versione e
uno spezzone di codice con cui si possa ricostruire il problema?
Se lo chiedo più per preoccupazione che per semplice curiosità.

  Io sulla mia macchina ho Visual Studio 6, VS2003 e VS2005.
Io sapevo che VS2003 e VS2005 si pestano i piedi. Quindi ho VC6 e VC8 
su PC, e VC7 su una macchina virtuale. Poi alla fine della fiera uso 
solo VC6 (10%) e VC8 (90%). Il VC7 lo tengo per compatibilità con certi 
progetti.
-- 
partecipa anche tu:  
http://www.beppegrillo.it/vaffanculoday/

 amministratore.
Torni indietro dei tuoi passi perche' hai delle copie di salvataggio fino a 
un'ora fa quando l'internal error non usciva e cerchi di capire come 
evitarlo.
Poi probabilmente ti e' gia' capitato quindi sai come ovviare, decisamente 
molto piu' veloce e pratico di cercare di risolvere un internal error su 
Visual Studio 2005 che non e' ancora successo a nessuno e nessuno sa ancora 
come risolverlo...
Concludo il mio intervento ribadendo il concetto che non si puo' 
generalizzare: come in tutte le cose c'e' un pro ed un contro e il compito 
di un responsabile di sviluppo e' proprio quello di valutare attentamente le 
proprie scelte perche' le ricadute possono essere molto gravi e 
imprevedibili. Se parliamo di stabilita' e di sicurezza sicuramente avere un 
ambiente di sviluppo nuovo ogni due anni non ti aiuta (com'era il proverbio 
che diceva 'chi va piano va lontano?')
-- 
Gugu
OIBABOI! (Tutti insiem OiBaBoi)

 Se lo chiedo più per preoccupazione che per semplice curiosità.
La versione se non erro era la 4.2.1 sotto debian. Però avevo visto che 
dipendeva anche dalle opzioni del mostruoso makefile associato alla 
ricompilazione di una versione mips di linux... cioè facendo la prova con le 
classiche 4 righe non dava l'errore, mentre in quel contesto ha funzionato 
solo splittando b=c; e a=b;
Tieni presente che questo è solo uno delle decine di errori tra gcc e shell 
che abbiamo incontrato e dovuto correggere modificando, ahimè, i sorgenti.
Ho trovato documentazione di queste incongruenze su vari forum (magra 
consolazione) e pure guide ufficiali che parlano apertamente di 
incompatibilità dei vari toolset per cui è necessario downgradare 
compilatore e toolset più in generale. E le security patch se ne vanno a 
farsi friggere.


 certi progetti.
Anch'io tengo vs2003 per vecchi progetti e concordo con quanto già detto in 
questo thread che upgradare va fatto solo quando necessario.... ma prima o 
poi il progetto diventa obsoleto oppure tocca upgradarlo.
Adesso l'unico che tengo in VM per non mischiare beta con RTM è VS2008 
(Orcas) ma quando esce sostituirò VS2005.


 oggi è già da buttare :)
Verso la fine del 1999 avrei tanto voluto sapere un po' di cobol :)


 aiuta (com'era il proverbio che diceva 'chi va piano va lontano?')
Per la sicurezza più che mai è necessario aggiornare di continuo proprio 
perché chi difende non può sapere in anticipo cosa si inventerà l'attacker.
D'altra parte WinUpdate ha la controparte Linux che è altrettanto 
mastodontica, quindi il problema oggi c'è e non si può ignorare da nessuna 
parte.


 ma poi potrà sostituire completamente VS2005 visto che è multi-target.
Cioe' io posso scaricare visual Studio Express 2005 e installarlo anche se
ho gia' il vecchio visual studio sul mio pc? Se me l'assicuri, corro a
scaricarlo!!
Domandina da principiante: se ho un progetto VB6, lo posso portare in
VS2005 oppure devo rifare tutto daccapo (forse sono un po' drastico..)?
Grazie ancora per il supporto!!


 farsi friggere.
Azz.. questa cosa mi preoccupa, sinceramente. Io so di operazioni
one-liner come a^=b^=a^=b (il trick per lo scambio di due valori) che
vengono sconsigliate perché non portabili. Sulla FAQ di comp.lang.c, ad
esempio, viene riportato che il seguente codice:
int a = 123, b = 7654;
a^=b^=a^=b;
con lo SCO Optimizing C Compiler imposta (contrariamente a quanto ci si
aspetterebbe) 'b' a 123 ed 'a' a 0. Ma questa è una tipica assegnazione in
cui ci sono side-effect sulle variabili in gioco e quindi è normale che
abbia un risultato impredicibile. Non capisco, invece, che cosa possa
esserci di così difficile interpretazione per il compilatore in uno
statement semplice come "a=b=c". 


 VC 6.
ciao a tutti,
urca! La mia semplice richiesta di aiuto ha scatenato una bella
discussione.
Provo ad aggiungere anche il mio punto di vista..
Premetto che l'idea di cominciare ad utilizzare VS6 mi e' venuta in mente
per mia cultura personale. Faccio il consulente nel campo automotive e mi
occupo di automazione da 3 anni. Quello che vedo intorno a me nel campo
dell'automazione, e' il migrare sempre di piu' verso l'utilizzo di sistemi
di sviluppo "grafico" del codice, come Simulink e Labview e alla
generazione automatica di codice per centraline o sistemi embedded.
Sviluppare applicazioni in questo modo ha innegabili vantaggi, anche se i
programmatori puri storceranno un po' il naso.. ;-)
Ovviamente pero' per certe attivita' ci si deve ancora rivolgere al buon
vecchio C, come lo sviluppo di driver, modifiche e adattamenti del codice
generato, creazione di applicativi windows, ecc. 
Visto che pero' odio vedere solo un aspetto del problema, ho pensato di
avvicinarmi di piu' al punto di vista del programmatore C++.
Per quanto riguarda la questione Visual Studio 6. vs Visual Studio 2005
aggiungerei il seguente punto. 
Esiste completa portabilita' di progetti VS6 su VS2005?? Se si, tutto ok,
altrimenti mi sa che nessuna azienda abbandonera' mai completamente VS6.
Cosa ne faccio del software presente su una macchina venduta 10 anni fa?
Ad alcuni colleghi capita spesso di dover apportare modifiche a questi
software, questo perche' il cliente vuole migliorare la produttivita'
senza modifiche pesanti al sistema che ha comprato..


 Verso la fine del 1999 avrei tanto voluto sapere un po' di cobol :)
Io ho pasticciato un po' di Cobol.NET qualche anno fa e ti assicuro che non 
è una bella esperienza :)


 sistema che ha comprato..
Se il cliente vuole "migliorare", questo vuol dire che il ciclo di vita del 
software deve fare il suo corso. E oggi la produttività dei nuovi tool ti 
permettono di risparmiare il tempo degli sviluppatori.


 Grazie ancora per il supporto!!
Prego!


 il compilatore in uno statement semplice come "a=b=c".
Non saprei proprio. Sono purtroppo talmente tanti gli errori che saltano 
fuori ricompilando progetti OS che dovrebbero essere consolidati e perfetti, 
che non ho avuto il tempo di fare altre indagini. Scopri una marea di tweak 
su varie pagine private o di forum ma di documentazione su questi errori 
manco l'ombra.
Io comunque preferisco sorgente piů verboso senza i trick che hai riportato.


 Io comunque preferisco sorgente più verboso senza i trick che hai riportato.
Assolutamente d'accordo. Quello citato è difatti un esempio negativo, da
non seguire assolutamente. Non è una novità che il codice che dà problemi,
alla fine, sia sempre quello più contorto e antiintuitivo. A me, ad
esempio, piace esplodere i += e i -=, perché so per esperienza che la
gente confonde a -= b con a = b - a. Dichiaro su più righe le variabili
(anche dello stesso tipo) quando c'è ambiguità ( vedi "int* a,b;"), non
faccio mai assegnazioni multiple, seguo sempre e solo un metodo per
compiere certe operazioni (ad esempio, sempre e solo "while" e "for" e mai
"do..while") e tante altre cose che si acquisiscono col tempo.


 al sistema che ha comprato.. 
Dipende dall'azienda e dal software. Probabilmente è vero che rifare 
da zero la certificazione di tutto un software su cui si fa solo 
bug-fixing potrebbe essere troppo rischioso (oltre alle feature e 
alla compatibilità ISO la nuova versione potrebbe pure avere 
introdotto dei bug...) o comunque non conveniente.
Per software su cui si fanno pesanti implementazioni e manutenzioni 
credo che il passaggio a VS2005 (o 2008) sia da considerare, prima o 
poi.


 assicuro che non è una bella esperienza :)
Non pensavo sarebbe stato bello. Però c'era un sacco di richiesta 
causa fine millennio! 


 "imprevedibili" (vedi gestione del real-time).
Su questo ci sono belle novità in Orcas con:
GCSettings.LatencyMode = GCLatencyMode.LowLatency;
che ti permette di dire al GC di interrompere per il minimo tempo possibile.
Non è real-time ma permette ad esempio di stare dietro a gaming e altre 
procedure critiche.


 causa fine millennio!
LOL


 a gaming e altre procedure critiche.
Aspetto con ansia che arrivi su CE :)
Anche se, come già dici tu, credo che il mondo "managed" sia ancora 
molto lontano dal real-time.


 Di piů non ti posso assicurare :)
Perfetto! In questi giorni provo a fare la migrazione verso VC2005.
Grazie!


 Grazie!
Prego!


 molto lontano dal real-time.
Il GC, che è l'unico vero "ostacolo" al real time, evita fondalmentalmente 
la frammentazione della memoria.
La frammentazione è un problema che può affliggere gravemente i processi 
unmanaged che usano per lo più dei garbage collector c++ per evitare il 
problema ma che allo stesso tempo cocciano con il realtime.
A questo punto non restano che due soluzioni:
- chiedere al GC di lavorare in una modalità che non deframmenti evitando 
così qualsiasi latenza (resta la frammentazione ma è vero che non è sempre 
un problema) ... chissà forse già ci stanno lavorando sopra
- demandare le operazioni di realtime in un piccolo processore esterno. 
Questa è la soluzione che prediligo per cose relativamente semplici. Uso dei 
PIC esterni che fanno il lavoro critico e il resto si lascia al PC.
Vedremo! :)


 che si acquisiscono col tempo.
concordo visto che ormai gli ottimizzatori di codice dei compilatori sono 
sufficientemente smart da non richiedere questo genere di attenzioni da 
parte del developer.


 lavoro critico e il resto si lascia al PC. 
Questo dipende molto dall'hardware che scegli e dai vincoli di 
dimensioni/costo/consumi. 
Se usi CE su un ARM che magari ha già dei convertitori A/D, per 
esempio, usare un processore esterno per fare la stessa cosa 
rappresenta una complicazione hardware, un costo e un dispendio 
energetico che potrebbero essere inaccettabili, soprattutto se il 
numero di pezzi è alto.
Per chi ragiona su grandi quantità il software è quasi a costo zero, 
nel senso che i tempi e costi di sviluppo sono poi redistribuiti sul 
numero di pezzi. Se spendo un milione di euro in più per il software 
e risparmio 3 euro di hardware per pezzo il discorso non ha senso 
per mille pezzi, ne ha molto per tre milioni di pezzi.


 parte.
Se il pericolo esiste si, ma quando il pericolo non esiste o e' molto remoto 
bisogna saper valutare cosa e' meglio fare.
Quando un sistema e' stabile e tutte le pecche sono state chiuse e non ci 
sono piu' rischi di attacchi ecco che esce un sistema nuovo con nuove pecche 
e nuovi pericoli e tutti a buttare via quello vecchio.
Posso scegliere? Io mantengo il sistema vecchio piu' che posso.


 
Azz...
io ho provato un paio di mesi fa e proprio non mi si installava!!! (ora 
non ricordo che errore usciva ma abortiva completamente l'installazione)
Bisogna usare qualche trucco/procedura strana? esiste documentazione?
GM

 Bisogna usare qualche trucco/procedura strana? esiste documentazione?
Intanto disattiva AUC e quando esegui il setup fallo con il tasto DX e 
scegli esegui come amminstratore (Vista dovrebbe riconoscere i setup.exe 
farlo automaticamente avevo letto da qualche parte ma non mi sono mai 
fidato).
Sicuramente verranno visualizzati messaggi di avvertimento ma ignorali e 
procedi pure.
Poi sul collegamento che ti lancia il Visual Studio metti lo spunto di 
eseguirlo come amministratore e anche in quel caso se ti visualizza dei 
messaggi di avvertimento ignorali.
Controlla eventualmente che la cartella C:\Program Files\Visual studio che 
l'utente administrator abbia le autorizzazioni di controllo completo.
L'ho installato senza problemi su queste versioni di vista: enterprise, 
ultimate e business (le ultime due sia in italiano che in inglese).


 per mille pezzi, ne ha molto per tre milioni di pezzi.
Certo, daccordissimo, è che molti si fossilizzano sulla soluzione realtime 
mentre con pochi euro risolvi tutto.


 vecchio. Posso scegliere? Io mantengo il sistema vecchio piu' che posso.
Io no e se leggi i security bullettin magari cambi idea :)


 Intanto disattiva AUC e quando esegui il setup fallo con il tasto DX e 
[SNIP]...
Grazie.
Ma ora che ci ripenso mi sembra di ricordare che il problema fosse 
l'installazione del SP6 che si confonde con la rilevazione dell'MDAC 
presente e abortisce l'installazione. Ma sono solo vaghi ricordi di 
circa 2 mesi fa...
Mi confermi che si riesce ad installare anche SP6?
GM

 GM
Assolutamente si: VB6 e VC6 con SP6.



Se ti facessi un giro dalle mie parti magari idea la cambi tu.


 :-) ?
Ciao Lawrence!
:) lo diventerà presto... per adesso è solo una raccolta di link ma vorrei 
espandere un po' il discorso con le ricerche che sto facendo tra NDepend 
(fantastico tool) e l'immancabile Reflector.


 realtime mentre con pochi euro risolvi tutto.
Anche perchè gli hanno venduto un S.O. hard real time :)
IMHO non è sempre e solo una questione di soldi e di 
fossilizzazione. Un componente e un software in più sono comunque 
una possibile fonte di problemi e, comunque, la tendenza è quella di 
"spremere" tutto il possibile da quello che si ha a disposizione.
Per contro, mi è capitato di vedere approcci conservativi dove si 
usavano microprocessori esterni per gestire cose che si gestivano 
con mezza giornata di lavoro dal processore principale...


 Se ti facessi un giro dalle mie parti magari idea la cambi tu.
Cambiare idea e pensare che un sistema vecchio sia più sicuro?
WPA2 era considerata sicura ... era ... oggi abbiamo le rainbow anche per 
quella. Questo è solo uno dei mille esempi per cui vecchio != sicuro


 (fantastico tool) e l'immancabile Reflector.
Ok, magari fai un post qui quando hai finito anche :-P
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

 con mezza giornata di lavoro dal processore principale...
certo, capisco.


> Ok, magari fai un post qui quando hai finito anche :-P
Qui lo vedo un po' OT, ma sul mio blog di sicuro.


 quella. Questo è solo uno dei mille esempi per cui vecchio != sicuro
Certe volte no.
Secondo te invece e' sempre NO... bha, se sei convinto di questo vivi pure 
contento e felice delle tue convinzioni, peccato che il mondo reale e' un 
po' diverso.


 DIO del sapere informatico fai pure.
Io non mi eleggo a un bel niente. Ho solo risposto ad un thread e ho detto 
come la penso. Se non condividi le opinioni degli altri, non puoi sparargli.


 sparargli.
E che da una persone con una firma come la tua ci si aspetterebbe un po' 
piu' di umilta' e di apertura mentale.
Comunque sei tu che metti al muro chi usa VS6.0, non io.


 Comunque sei tu che metti al muro chi usa VS6.0, non io.
Al muro? Sto obbligando qualcuno? Ma rileggiti il thread!


 Russinovich che spiegano tanti dettagli fondamentali
Dove? Non mi ci ritrovo su quel sito.
-- 
partecipa anche tu:  
http://www.beppegrillo.it/vaffanculoday/

scelta continuare a mantenerlo.
Io ti ho detto che ci sono situazioni in cui invece e' una buona scelta 
mantenerlo, non ci credi e non ne vuoi sapere.
Menomale che siete solo in 25... tanti danni non ne potete farli.


 Menomale che siete solo in 25... tanti danni non ne potete farli.
Tu porti delle motivazioni che hanno dei costi e rischi che non sono 
valutati nel rapporto costi benefici di cui parlavo io. Infatti ho detto fin 
dall'inizio che la valutazione va fatta su questi presupposti.
Questo può influire o condizionare qualcosa? No, mostra solo un punto di 
vista. E poi ciascuno farà le proprie valutazioni.


 Dove? Non mi ci ritrovo su quel sito.
Ecco i tre link:
http://www.microsoft.com/technet/technetmag/issues/2007/02/VistaKernel/
http://www.microsoft.com/technet/technetmag/issues/2007/03/VistaKernel/
http://www.microsoft.com/technet/technetmag/issues/2007/04/VistaKernel/


 Ecco i tre link:
Grazie, poi me li leggo con calma.


 vista. E poi ciascuno farà le proprie valutazioni.
Secondo tutti quelli che usano ancora VS6.0 e che hanno in giro migliaia di 
impianti installati e funzionanti con sistemi operativi che non sono windows 
Vista le valutazioni se sia conventiente cambiare non le abbiano fatte?


 cambiare non le abbiano fatte?
Per quello che ho visto presso diverse aziende, sono tantissime a non 
conoscere le ultime tecnologie, e questo è lo stesso tipo di feedback che ho 
da tanti amici e colleghi.
C'è chi non ne conosce l'esistenza, c'è chi le ha sentite nominare ma non ne 
conosce le specifiche oppure i suoi campi di applicazione.
Tutto questo evidenzia semplicemente che molte aziende non hanno tempo di 
capire (o non hanno pianificato nel loro budget) l'investimento di tempo per 
capire se esista qualcosa sul mercato che possa dare loro un sostanzioso 
risparmio di tempo e dei vantaggi in termini di specifiche.
Inoltre da questi thread sembra che la migrazione da VC6 a VS2005 sia una 
apocalisse. Non esageriamo...
- la maggior parte degli errori è solo noiosa da mettere a posto
- l'adeguamento alle Safe-CRT è opzionale anche se vale la pena di farlo in 
quanto può rivelare subdoli errori già presenti nel vecchio listato
- le differenze di comportamento a runtime richiedono giustamente la 
ripetizione di tutti i test di cui un software dovrebbe sempre avere 
corredato.


> Grazie, poi me li leggo con calma.
Prego


 - la maggior parte degli errori è solo noiosa da mettere a posto
Pero' ci sono gli errori che non dipendono da te ma dipendono dall'ambiente 
di sviluppo e quelli sono snervanti perche' prima di riuscire a capire che 
non e' un tuo problema ma di qualche bug nel software hai perso del tempo e 
pazienza.
Comunque questo thread non ha piu' ragione di proseguire, intanto ho capito 
che viviamo sue due mondi paralleli e non riuscirai mai a capire che ci sono 
situazioni in cui l'evoluzione non ha senso, e' solo un dispendio di energie 
e di risorse per ottenere delle migliorie che sono assultamente inutili e 
irrilevanti...


 migliorie che sono assultamente inutili e irrilevanti...
Non sono affatto daccordo ma questo era già chiaro da un pezzo :)


 i vecchi progetti le librerie nuove del framework.
Dio ce ne scampi dal CLR. Ci sono settori in cui il non determinismo 
del CLR è letale. Per dire della caratteristica più problematica. Al 
limite non è nemmeno un problema di prestazioni, e proprio questa idea 
del GC che parte per i fatti suoi e fa pulizia bloccando il sistema. Al 
che per rimediare devi "pilotare" la GC. Chi ha vissuto senza, 
continuerà a vivere senza. Non credo che dotnet 3.0 cambierà le cose.
Se uno faceva una DLL con interfaccia in C usata (principalmente) da un 
programma in VB, perché dovrebbe cambiare approccio? Una libreria C++ 
managed non è esattamente la stessa cosa. Ma sopratutto, dov'è il 
vantaggio nel cambio di approccio, a parte l'idea di legarsi per sempre 
ai compilatori MS?


 l'idea di legarsi per sempre ai compilatori MS?
Se non ricordo male, anche borland ha un compilatore C# che genera 
"eseguibili" .NET. 
Sicuramente ti leghi alla tecnologia .NET ma, nell'ambito dei RAD, è 
difficile non legarsi a qualcosa. Sia .NET, Java, VB6, il framework 
borland (che dipende da delphi) o altri sistemi proprietari.


 sempre ai compilatori MS?
Il fatto di legarsi è molto relativo. Se oggi usi Win32, sei già legato. 
Tuttalpiù il problema di essere legati dipende da come hai strutturato 
l'architettura dell'applicazione. Cioè puoi creare una serie di moduli che 
siano totalmente OS indipendenti e poi un'altra serie di DLL che usino le 
api specifiche... siano queste Win32 o managed non importa assolutamente 
nulla.
Poi su un OS differente non dovrai far altro che implementare quelle "OS 
specific" usando le api di quell'OS e/o mono in caso di Linux.
I vantaggi di usare il framework sono tanti, a cominciare dalla vasta base 
class library, al supporto per le applicazioni distribuite con WCF che 
semplifica tutti i protocolli standard WS-*, la realizzazioni di interfacce 
grafice 2D e 3D (che usano DirectX) con WPF e tantissime altre cose.
Io ci metto anche il GC che semplifica la gestione delle allocazioni. Se non 
lo vuoi usare per tutte, sei libero di farlo. Se vuoi vederlo efficiente, 
devi capire bene come funziona. Il GC va capito e l'affermazione per cui ti 
dimentichi della memoria è falsa.


 Non sono affatto daccordo ma questo era già chiaro da un pezzo :)
Peccato, perche' questo sarebbe solamente valore aggiunto a quelle che sono 
le tue attuali conoscenze.


 I vantaggi di usare il framework sono tanti.
Visto che scrivo server, onestamente non me ne viene in mente nemmeno 
uno.
-- 
partecipa anche tu:  
http://www.beppegrillo.it/vaffanculoday/
il capitalismo: 
http://www.rat-man.com/site/IT/IT/rat_cartoon.ashx?mn=5

difficile non legarsi a qualcosa.
Programmo ancora, per fortuna in modo mooolto saltuario, con gcc a riga 
di comando. Però capisci che se ho queste esigenze, dotnet è una 
soluzione che tendo a scartare se posso. Poi ovviamente dipende dal 
progetto.
-- 
partecipa anche tu:  
http://www.beppegrillo.it/vaffanculoday/
il capitalismo: 
http://www.rat-man.com/site/IT/IT/rat_cartoon.ashx?mn=5

 dipende dal progetto.
Anche io faccio programmi di prova usando le API e qualche volta 
nemmeno il C++. Però un conto sono programmini semplici, un conto 
sono applicazioni con una UI complicata. Caso in cui uno strumento 
RAD (sia .NET, sia qualcosa basato su Java, QT, GTK o altro) 
velocizza di molto i tempi di sviluppo.
E si parlava di RAD. Non credo che gcc rientri nella categoria...
Chiaramente non ha senso usare un RAD per implementare una mezza 
dialog box ma, nelle situazioni in cui il RAD ha senso, le 
motivazioni per cui dici di scartare a priori il framework .NET mi 
sembrano applicabili a tutti i framework e quindi, o li scarti in 
blocco (ma realizzare una GUI complessa con gcc a linea di comando e 
nessuna libreria proprietaria sconfina IMVHO nel masochismo). oppure 
ne scegli un altro. In questo secondo caso mi piacerebbe sapere 
quale e in cosa è superiore a .NET.


 GC (argomento di cui si parlava).
Se tu allochi molte cose, e non puoi o non vuoi, disallocare, e lasci 
l'incombenza alla GC, ci sono due casi con cui puoi scontarti:
consumo abnorme di memoria
programma completamente piantato perché la GC pulisce
Problema riscontrato sia con C# che con Python. Il problema è che certe 
cose e meglio non farli con certi linguaggi a meno di non volersi 
complicare troppo la vita.
in codice pitonesco
for i to range(1000):
  s = str(i)
e alla fine del ciclo hai 1000 stringhe in memoria che prima o poi 
dovranno essere riallocate. Ora, l'esempio è cretino, però con questi 
problemi cretini si può soccombere.
Per esempio quando disallochi un socket in dotnet, la liberazione delle 
risorse quando viene fatta? Questo è un esempio meno cretino, abbiamo 
avuto grossi problemi su questo, anche perché in windows non hai 
disponibili MAX_INT socket, ma molti meno.


 uno.
Provo a farti degli esempi per il lato server ...
- Visto che sviluppi multipiattaforma, il vantaggio ad esempio di WCF è 
quello di poter dialogare con protocolli che sono dispobili anche in 
ambiente java (WS-Security, WS-Trust, WS-Transaction, ...).
Per esempio con il framework 3.5 c'è un protocollo nuovo, Syndacation, che 
ti permette di erogare feed RSS e ATOM dalla tua applicazione. Vantaggio 
immediato: il client è già pronto, sia esso uno dei tanti aggregatori o 
direttamente IE7. Usato per la diagnostica del server è indubbiamente un 
guadagno di tempo notevole.
- Workflow Foundation è una infrastruttura per la costruzione visuale di 
workflow sequenziali e macchine a stati. Ad esempio una macchina a stati per 
la gestione dell'impianto può beneficiare di questa infrastruttura perché 
sono già pronti i servizi per fare tracing (logging su db), visualizzare la 
storia delle transizioni, transazioni, gestione dei fault, persistenza su 
disco automatica quando l'esecuzione ha tempi lunghi o devi semplicemente 
far ripartire l'applicazione. E molto altro ...
- Altre tonnellate di classi per gestire crittografia, XML,  gestione di 
event log, WMI, socket o più alto livello, compressione dati, etc. etc.


 windows non hai disponibili MAX_INT socket, ma molti meno.
Lo stesso problema c'è con gli handle dei file. Per questo tipo di 
oggetti è consigliata una gestione esplicita con chiamate ai metodi 
di chiusura. Anche perchè, se hai memoria, potrebbero non essere mai 
rilasciati.
Questo tipo di problemi si potrà risolvere solo integrando 
pesantemente la gestione "managed" nel S.O. facendo in modo, ad 
esempio, che scatti un GC per un certo tipo di oggetti (i socket) 
quando quelli liberi scarseggiano.


 falsi benefici che si otterrebbero.
E sta benissimo, infatti ho scritto più volte che è una questione di 
valutazione costi/benefici. È nella lista delle cose che ci sono dentro i 
costi e i benefici che non siamo daccordo, ma pazienza :)


 hai disponibili MAX_INT socket, ma molti meno.
Per questo č importante conoscere il pattern Dispose e lo statement using 
(non quello dell'inizio del listato) di C#/VB.
Il succo č:
- Le risorse native devono essere wrappate dentro una classe che espone 
IDisposable e secondo quanto previsto dal pattern Dispose (che C++/CLI crea 
automaticamente al contrario di C# e VB)
- Lo sviluppatore deve chiamare Dispose se questa esiste in una classe. Se 
non lo fa incorre nei problemi che tu dici ma, al contrario del codce 
nativo, hai la garanzia che l'oggetto finirą nella coda di finalizzazione e 
quindi la Dispose verra chiamata comunque.
Attenzione a non confondere la memoria (gestita dal GC) dalle risorse native 
(tipicamente disallocate dalla Dispose quando č presente) ed eseguita 
durante la Finalizzazione (e non la garbage collection).
Qualche hanno fa ho scritto un articolo su questo:
http://www.ugidotnet.org/articles/articles_read.aspx?ID=53


 quando quelli liberi scarseggiano.
La domanda principale però a questo punto, perché devo andarmi a 
cercare i problemi con codice managed? Io sviluppo server. Nel mio caso 
non vedo vantaggi. Per le cose che faccio non ho un crollo dei tempi di 
sviluppo dipendenti dal linguaggio. Quello che mi cambia la vita è 
l'ambiente di sviluppo, e il Visual Studio è notevole da questo punto 
di vista, almeno in debug.
La domanda secondario è che per fare queste cose ci vuole conoscenza. 
Magari io preferisco spendere tempo a capire Kerberos, che non a far 
funzionare del codice managed.


 
http://www.ugidotnet.org/articles/articles_read.aspx?ID=53
Nome utente e password, che palle.
Ho trovato questo, è lo stesso?
http://download.microsoft.com/download/b/d/4/bd4a3237-649f-44e2-94db-fd804e01e128/MixedCodeC_CLI.ppt


 Provo a farti degli esempi per il lato server ...
Tutte cose belle, però io alla fine non mi fido di Microsoft, come di 
nessun'altro. Se posso scegliere, e non è detto che posso, voglio i 
sorgenti. Voglio i sorgenti di DES come quelli di una libreria POP3, e 
così via. Certo, su DES non posso in realtà metterci becco, ma su altre 
cose si.
Faccio un esempio, il WebClient. Oggetto fantastico, quasi magico. Ora 
su certi progetti lo uso con gioia. Ma su altri io voglio sapere di 
ogni byte che mi passa sotto il naso, e non è mie intenzione usare 
analizzatore di protocollo per vedere cosa succede dietro le quinte. Tu 
mi potresti dire, usa i socket raw del CLI. Ma in quei casi a che pro?
Chiaramente lavoro su cose che mi permetteno un tempo di sviluppo più 
alto, che mi permettono di costruirmi la "mia" libreria. Poi sono gli 
altri che devono parlare con me, e non io con gli altri. Quindi sono 
gli altri che si devono "adeguare" :-)
Di solito con un HTTP GET o HTTP POST risolvo tutti i problemi di 
comunicazione con qualsiasi cliente. E mi ci trovo molto meglio che con 
i webservice (molto gettonati in ditta).
Comunque ci ho messo hanni per trovare un caso in cui mi facesse comodo 
l'XML. Sono duro di comprendonio, ma sono posso anche cambiare idea 
qualche volta!


 che non a far funzionare del codice managed.
Ok. Ma secondo me vale la pena di sprecare un po' di tempo (una 
giornata di conferenza?) per capire cosa fa e non fa questo benedetto 
sistema managed e capire se può esserti utile.
Scartarlo perchè non hai tempo di studiarlo mi sembra un po' 
affrettato.


 storico postatore, e io uno storico lettore.
Il sottoscritto è storico anche in senso anagrafico... ormai.


 affrettato.
Sinceramente o fai progetti giocattoli, o inserirlo su un progetto 
pilota è qualcosa di costoso. Cosa che comunque alla fine viene fatto 
in ditta, anche se non a me. Io vedo dei progetti in C# che collassano. 
Ho ipotesi sul perché questo succede.
Andare ad una conferenza è una giornata, ma poi le cosi le devi fare 
per vedere sul serio se "funzionano". Altro che giornata. Quindi, io 
sparo le miei cagate, vedo un poco la reazione, e se vedo che sono 
molto cazziato "studio". Mi risparmio un sacco di tempo così :-)


 Il sottoscritto è storico anche in senso anagrafico... ormai.
Esperienza da vendere. A quanto la vendi? :-)


 (nuove o vecchie) dipende anche dal campo di applicazione.
Quoto :-)


 
http://download.microsoft.com/download/b/d/4/bd4a3237-649f-44e2-94db-fd804e01e128/MixedCodeC_CLI.ppt
No quella è un'altra presentazione che ho tenuto sul codice misto usando 
C++/CLI.


 idea qualche volta!
I motivi principali per cui mi piace sono il parsing e la validazione su uno 
schema. Due cose che sono preziose e allo stesso tempo noiosissime da 
reimplmentare (e soprattutto testare).
Inoltre con il fatto che il framework puoi serializzare molto facilmente in 
XML una classe, rende molto più comodo il suo uso.


 cose simili.
La maggior parte di grosse applicazioni andranno sempre più in codice mixed.
Office 2003 faceva già uso del framework.
Sql 2005 hosta il CLR internamente per scrivere stored procedure in C# (e 
molto altro)
È chiaro che il codice che è già consolidato e collaudato come nativo ha 
senso evolverlo con le release più recenti del compilatore, ma difficilmente 
fare una migrazione totale al codice managed. Se devi inserire delle nuove 
feature (per esempio la view a fotogrammi di powerpoint) tantovale usare lo 
strumento che ti permette la maggiore resa con il minor costo... e il team 
di ppt in quel caso ha scelto dei controlli winform pur essendo tutto il 
resto fatto con MFC.


 difficilmente fare una migrazione totale al codice managed.
Molto interessante...


 tempo così :-) 
Ok. Però la giornata ti serve per capire se mettere in pista uno 
studio più approfondito, oppure no.
Ovviamente, conferenze o no, credo che nessuno si faccia folgorare 
sulla strada di Damasco e, tornato dalla conferenza, butti via tutto 
il pregresso per abbracciare la nuova tecnologia!


 Esperienza da vendere. A quanto la vendi? :-)
Sono un dipendente, quindi non sono io a fare i prezzi...


 Sono un dipendente, quindi non sono io a fare i prezzi...
Tanto non ero io a pagare. Al massimo posso offrirti il caffè.


 tempi biblici permette di fare cose "impossibili" su Windows.
Il tempo del caricamento del CLR e il Jitting del codice hanno il loro peso 
ma, se questo costituisce un problema, è possibile adottare delle 
contromisure.
- Per il tempo del lancio del processo si ovvia caricando le dll in modo 
dinamico (un po' come avviene con LoadLibrary nel nativo). In casi 
decisamente rari si può creare un processo nativo che poi prende in host il 
CLR. In questo secondo caso hai addirittura la possibilità di pluggare il 
CLR di una serie di oggetti che gestiscono threading, memoria, e molto altro 
ancora al posto di quelli di default del framework.
Questa tecnica si usa per customizzare il comportamento del framework, al 
pari di quello che hanno fatti i ragazzi del team di sql server per evitare 
che possano essere utilizzate certe funzioni di libreria che potrebbero 
compromettere il funzionamento del DB engine.
- I tempi di jitting si possono azzerare pre-generando le immagini native 
(utility ngen) che ha come effetto negativo il fatto di eseguire 
ottimizzazioni leggermente inferiori a quelle che può invece fare il Jitter 
a runtime.



+1: VS6/2003/2005 installati, e VS2008 (beta2) in VM
-- 
.A
UGIdotNET - 
http://www.ugidotnet.org
GUISA - 
http://www.guisa.org
Read my blog at: 
http://blogs.ugidotnet.org/pape
 

 invece fare il Jitter a runtime.
Mi sfugge il motivo di questa differenza.
Se il tool "compila" l'IL (mi viene da chiamarlo bytecode :P) 
staticamente perchè ottimizza meno? In teoria non ha i requisiti 
stringenti del compilatore just in time e può prendersi tutto il tempo 
che vuole per analizzare e tradurre il codice...


 demo di questa condizione di lavoro del GC.
Hai superato la quantità di informazione che posso digerire in una 
pausa caffè. Mastico e medito e poi torno.
A titolo di curiosità il mio problema è un ciclo che usa e butta 
risorse in continuazione. Da quel vedo in diretta non ho una "vera" 
garanzia che la GC ci stia dietro, anzi io vedo che questo non succede. 
La memoria tende ad aumentare in modo indefinito, ed ad un certo punto 
l'applicazione scoppia.
Però non dirmi nulla, mi hai già dato troppe informazioni.
Devo digerire quelle intanto :-)
Anche perché il programma in questione non l'ho scritto io. Io lo avrei 
scritto in C++ "puro" non in C# :-) !!


 Come al solito la risposta è dipende.
Piacere :-) eccomi qua: io sono proprio quello che deve fare CAD/CAM!
Abbiamo scritto un motore di nesting per ottimizzare il taglio del pellame e 
che per ovvie questioni di prestazioni (la macchina impiega 2 minuti a 
tagliare una pelle intera e in quei 2 minuti dobbiamo calcolare piu' 
soluzioni possibili per essere competitivi con i tagliatori a mano) gira su 
un dual pentium dualcore (4 processori per eseguire 4 tentativi 
contemporaneamente) e si mangia 2 Giga di RAM.
Forse il framework era la scelta migliore e noi abbiamo fatto una cazzata a 
scriverlo in C++ (Visual Studio 2005) ma sta di fatto che abbiamo 
implementato noi un gestore di memoria per evitare nel modo più totale 
qualunque allocazione o cancellazione di memoria altrimenti il PC andava in 
stallo dopo pochi minuti di lavoro.
Se qualcuno mi firma nero su bianco che utilizzando il framework in modo 
corretto aumentiamo le prestazioni di calcolo e risuciamo quindi ad essere 
più competitivi facendo piu' tentativi (a parita' di harware ovviamente) 
parto anche oggi a riscrivere tutto in C# e gli pago un bel po' di extra 
sulla consulenza.
Ma se ciò non dovesse succedere mi rimborsa il tempo speso per fare questo 
tentativo fino all'ultimo centesimo...


 Se qualcuno mi firma nero su bianco
Ovviamente nessuno firma cambiali in bianco. Si posso solo fare dei 
test e poi decidere.
Semmai la domanda è perchè non usate un cluester (magari questo: 
http://www.calvin.edu/~adams/research/microwulf/PPR/
 ) e demandate a 
lui i conti. Sulla macchina mettete un 486 di scarto giusto per la 
comunicazione di rete.
-- 
partecipa anche tu:  
http://www.beppegrillo.it/vaffanculoday/
il capitalismo: 
http://www.rat-man.com/site/IT/IT/rat_cartoon.ashx?mn=5

 che vuole per analizzare e tradurre il codice...
Perché a runtime lui riesce a capire (non ho mai guardato nello specifico di 
quali parametri si avvalga per decidere) cosa viene usato di più o di meno e 
genera codice leggermente superiore. Per esempio il fatto che il JIT conosca 
l'indirizzamento del processo e quindi dove stanno i moduli che sono già in 
memoria, gli consente di jittare codice che chiami direttamente i metodi di 
un altro assembly senza passare da uno stub come invece è necessario per una 
dll soggetta a ngen (che è poi lo stesso comportamento di una dll normale).
Poi ci sono altri potenziali problemi come il rebasing che il jitter fa 
automaticamente mentre ngen deve essere istruito con i base address 
corretti.
Non mi sono mai messo a fare benchmark su questo ma sulla superiorità del 
codice del jit me ne ha parlato Jim Hogg alla PDC del 2005 alla cena di VC++ 
(che ho bloggato in foto se vuoi vederne il volto). Lui è il responsabile 
del Phoenix Framework, un nuovo backend di futuri compilatori che dovrebbe 
servire come base e language-independent.
-- 
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://blogs.ugidotnet.org/raffaele

 avrei scritto in C++ "puro" non in C# :-) !!
eheh :)


 Semmai la domanda è perchè non usate un cluester
Uno dei nostri clienti  ha su un cluster di 8 macchine, in questo modo se si 
ferma un PC lo puo' sostiture e continuare a lavorare.
La scelta di quanto si vuole spendere per l'hardware la fa il cliente, dal 
mio punto di vista mi preoccupo delle prestazioni del software.
-- 
Gugu
OIBABOI! (Tutti insiem OiBaBoi)

 questo tentativo fino all'ultimo centesimo...
Se riscrivi tutto in C# puoi farlo girare su una piattaforma a 64 bit e 
questo già annulla i problemi dei limiti di memoria a 2GB.
Volendo rimanere su una piattaforma 32bit, per quello che riguarda 
l'occupazione di memoria, potresti avere un beneficio a splittare alcune 
porzioni di calcolo su processi differenti, ma certamente queste ed altre 
sono valutazioni che avrete fatto.
Per le performance dipende da come scrivi il codice :)


 memory pressure
Non mi ricordo esattamente cosa succedeva. Mi pare che andasse in crash 
e stop. Se ricordo bene la memoria aumenta sempre e poi verso i 2 GB la 
macchina andava in crisi. La CPU era perennemente al 100% o quasi. Ci 
misi una pezza uccidendo il processo quando superava un Gb di memoria, 
e facendolo ripartire con un monitor esterno, ma poi non so come è 
evoluta la cosa.
Credo che quel cliente ci abbia denunciato agli organi giudiziari come 
incompetenti e mangiapane a tradimento :-(


 incompetenti e mangiapane a tradimento :-(
uhm, così è difficile cosa succedeva. Se non c'era più memoria a 
disposizione nella ThreadException (che trappa le eccezioni del thread) 
avresti ricevuto una OutOfMemoryException. Se così è, con tutta probabilità 
c'erano dei reference attivi verso la memoria allocata e quindi il GC non 
poteva disfarsene.
Ad ogni modo con un profiler questi problemi si mettono a posto abbastanza 
velocemente.


 
Oltre a quanto detto da Raffaele, IMHO la maggiore differenza è che il 
JIT conosce la CPU effettiva per cui deve produrre il codice, la 
compilazione statica no.
Pertanto la compilazione statica non può prendere vantaggio da features 
nuove o migliori presenti solo su CPU più moderne (o di fascia più alta) 
a meno di rinunciare alla compatibilità con le altre CPU o di compilare 
N immagini.
GM

 contemporaneamente) e si mangia 2 Giga di RAM.
...
2 minuti sono veramente tanta roba!!!
In generale in questi casi (non sto parlando del TUO caso in particolare 
in cui sicuramente ci avrete pensato per bene), conviene concentrarsi 
più sull'algoritmo che sulla "potenza di fuoco".
A volte si può scoprire che un buon algoritmo ha complessità di ordini 
di grandezza inferiori e magari si passa da minuti a secondi (o 
addirittura a frazioni).
Con questo non voglio certo dire che questo sia il vostro caso: non 
conosco nè il problema nè la soluzione da voi adottata. Parlo solo per 
mie esperienze personali.
L'unica cosa che mi suona strana è che un problema di ottimizzazione 
necessiti di risorse così "pesanti" per poter essere competitivo con 
un'ottimizzaizone "umana". Così a occhio e croce mi verrebbe da dire che 
  anche la macchina dovrebbe poter vincere a mani basse (ma ripeto non 
conosco il problema e non voglio assolutamente creare polemica).

 istruito con i base address corretti.
Ok. Ma questo lo può fare anche ngen compilando più assembly in una 
volta. E' lo stesso ragionamento che fa il make-image di Windows CE.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 altre CPU o di compilare N immagini.
Ma ngen viene lanciato sul sistema dove il codice sarà eseguito e 
quindi (salvo aggiornamenti hardware...) conosce benissimo la CPU.
Il tuo discorso può valere se si parla di differenza tra JIT e 
compilazione diretta in codice nativo. Anche se, IMVHO, il compilatore 
nativo può fare analisi molto più approfondite (eventualmente anche 
CPU-dependent) visto che non ha l'onere di pesare anche sul tempo di 
esecuzione.


 
Hai ragione. Mi confondevo con il confronto jit-compilazione statica.

 conosco il problema e non voglio assolutamente creare polemica).
Certamente,  il fatto è che l'uomo (in questo caso il tagliatore) si puo' 
permettere di "stirare" la pelle a mano per far stare quel pezzo che non ci 
starebbe per un paio di millimetri oppure puo' anche ingnorare un difetto 
perche' per la sua esperienza non e' poi cosi' tanto grave. In questo modo 
ad esempio quando devi lavorare su materiale molto pregiato, tipo piccole 
pelli di capretto, un tagliatore a mano usa qualche trucco per farci stare 
un pezzo che il tuo sistema, nonostante gli imponi delle tolleranze, non 
riuscirebbe mai a farci stare. Se tu invece allarghi troppo le tolleranze 
del tuo sistema finisce che ti mette dei pezzi che poi devi buttare via 
perche' non sono tagliabili.


 Per le performance dipende da come scrivi il codice :)
Ma come? Il C# non doveva essere super/mega/iper ottimizzato? :-P
A ma allora tanto vale farlo in C++ ... heheheheh


 volta. E' lo stesso ragionamento che fa il make-image di Windows CE.
Ad Ngen 2.0 sono già state fatti grossi miglioramenti, forse in successive 
versioni aggiungeranno anche questo... per adesso non l'hanno fatto e non ne 
conosco le motivazioni.


 A ma allora tanto vale farlo in C++ ... heheheheh
Il giorno che inventeranno un linguaggio in cui non c'è più bisogno di 
sapere quello che si sta scrivendo, probabilmente cambierò mestiere ;-)
Come ho già detto in un altro post, è necessario che lo sviluppatore sappia 
come usare al meglio il GC e non può fregarsene totalmente della memoria. E 
allo stesso modo per tante altre cose ... fortunatamente :)


 facile coniugare le due cose... però chissà...
Questa sarebbe fantascienza :)
Mi basterebbe un attributo sulle classi o sui metodi che dica al 
jitter che per quel metodo voglio privilegiare le performances 
piuttosto che la compattezza del codice. Un po' quello che si fa, 
staticamente, in C/C++ con le opzioni di compilazione.
Una funzione così potrebbe consentire di sfruttare il compilatore just 
in time per migliorare (ovviamente non credo in modo drammatico) le 
performances dell'applicazione.


 performances dell'applicazione.
Qualcosina c'è già: LoaderOptimizationAttribute (che ho usato di recente in 
un servizio con più appdomain), DefaultDependencyAttribute (che indica 
quanto aspettare per tirare su un assembly) e mi sembra di ricordare 
qualcos'altro ma mi sfugge il nome


 sfugge il nome 
Ok. Mi riprometto di studiarli la prossima volta che dovrò mettere 
mano seriamente a qualcosa in C#. Anche se non sò se su compact 
framework sono supportati.


 framework sono supportati.
uhm non rircordo ma basta guardare msdn


 tanto grave. 
...
Se per caso vi serve un sistema di ispezione automatica per i difetti 
fammelo sapere... :)

 fammelo sapere... :)
Come funziona?
Il sistema che adesso abbiamo adesso noi si basa su dei segni (glifi) che il 
tagliatore esperto fa sulla pelle e poi il software di riconoscimento 
interpreta opportunamente.. Ci sono ad esempio dei difetti che si vedono 
stirando la pelle o guardandola controluce, tutte cose che con una semplice 
ripresa digitale non sono purtroppo messe in evidenza (tolti ovviamente i 
fori o eventuali macchie). Non e' da escludere che utilizzando altre 
tecnologie (infrarossi?) questi difetti possano invece essere evidenziati. 
Se hai qualche cosa da offrire di valido potrebbe esserci molto utile!


Gugu ha scritto:

No, no, non ho nulla di tutto ciò.
E' che di mestiere mi occupo di ispezione automatica ma in un settore 
completamente diverso, pertanto non ho alcuna esperienza in merito.
Andrebbero visti i difetti e studiato un sistema di 
illuminazione/ripresa ad hoc e un adeguato sw di visione.
La mia era più che altro una battuta, in quanto siamo già occupati al 
150% e per ora non abbiamo la forza per affrontare mercati nuovi.
Ovvio che se ci fossero certi numeri...

 costi e i benefici che non siamo daccordo, ma pazienza :)
Pazienza davvero, ti dico solo che se quando e' uscito Visual Studio .NET 
2002 o 2003 l'ho saltato a pie' pari e ho aspettato Visual Studio 2005 ho 
fatto i conti giusti perche' i fatti mi hanno soltanto dato ragione, come ho 
saltato a pie' pari Visual Studio 2007 mentre sono quasi sicuro che 
adottero' Visual Studio 2008.
Comunque alla fine di tutto questo bel discorso ti voglio soltanto ricordare 
che Microsoft stessa nei confronti del vecchio ha dei bei riguardi alle 
volte (
http://msdn2.microsoft.com/en-us/vbrun/ms788708.aspx
) e di cazzate 
nelle innovazioni che fanno anche loro e i loro sbagli li ammettono, come e' 
giusto che sia perche' siamo tutti umani e tutti possiamo sbagliare. Loro 
hanno pero' la capacita' di fartele passare inizialmente tutte come 
innovazioni positive (esattamente come tendi a fare tu) mai poi sara' il 
mercato a fare le sue valutazioni, quando con i conti alla mano ti ritrovi 
che aver speso nmila euro in formazione, nmila in licenze software, nmila in 
tempi uomo per lo sviluppo, scopri che hai fatturato esattamente come l'anno 
precedente e tutti questi nmila euro per l'innovazione non ti sono tornati 
indietro, in compenso pero' hai accumulato un numero di rogne senza senso 
perche' i clienti che non vogliono comprare il nuovo ci sono e che 
pretendono di usare il vecchio perche' non capiscono e non capiranno mai che 
tra un computer e un martello un po' di differenza ci passa...


 l'innovazione non ti sono tornati indietro
Non voglio far polemica, però a volte un investimento in innovazione 
e formazione è indispensabile anche solo per non perdere quote di 
mercato (e quindi fatturato).
Nel tuo esempio può essere sia che l'investimento è stato sprecato 
perchè il fatturato sarebbe rimasto lo stesso anche senza, sia che è 
stato insufficiente a farti realizzare una nuova generazione di 
prodotti con caratteristiche tali da conquistare nuovi spazi sul 
mercato e che quindi, invece che abbandonarlo, è necessario 
dedicarci ancora più risorse!
Anche le aziende che fanno produzioni "tradizionali" (vino, 
alimentari, abbigliamento o arredamento "classico") introducono 
innovazione, magari senza cambiare troppo il prodotto finale... 
figurati un'azienda che produce software o comunque sistemi con alto 
contenuto tecnologico!
I clienti hanno sempre nuove esigenze e, se queste non corrispondono 
a nuove funzionalità, come minimo vogliono fare le cose più in 
fretta e spendendo meno. 
Ovviamente bisogna sempre valutare attentamente se vale la pena di 
lasciare la strada vecchia per la nuova (come già dicevo prima), ma 
bisogna anche ricordarsi che per chi sa usare solo il martello tutti 
i problemi sono chiodi... e non tutto si risolve a martellate :)
Soprattutto perchè rimanere troppo indietro spesso vuol dire 
fallire.
Pensa a Ashton Tate, Wordstar o altre aziende che hanno perso il 
"treno" della GUI o lo hanno preso quando ormai altri avevano 
rilevato la loro quota di mercato.
Probabilmente qualcuno dei loro "capoccia" aveva giudicato la GUI 
una tecnologia inutile e aveva previsto che il grosso degli utenti 
sarebbero rimasti fedeli al caro vecchio DOS.
Allo stesso modo altre aziende (Corel?) si sono scottate le mani 
abbracciando tecnologie non ancora mature o non adatte al desktop 
(java e linux, nel caso di corel), perdendo la leadership per non 
avere innovato il prodotto "tradizionale", rilasciandone uno nuovo 
non all'altezza del predecessore e dei concorrenti che, rimanendo 
sulla vecchia tecnologia, li avevano superati.


 ci passa...
Certo, ma non credere che ci sia qualche pazzo furioso che inventa nuove 
cose e poi viene proposto mandando le novità allo sbaraglio.
Tutte le novità sono frutto di accurati studi che partono dal feedback dei 
clienti (prima i grossi e poi gli altri). Ovviamente il trend del mercato 
può cambiare rapidamente e qualche volta accade che sia necessario fare 
diversamente ... si chiama rischio imprenditoriale :)


 rilevato la loro quota di mercato.
[...]
E sono daccordo, l'evoluzione e' un treno in corsa ma prima di salirci sopra 
io guardo dove mi porta e anche se non ci sono le sfere di cristallo 
piuttosto corro il rischio di prendere il treno dopo che non finire su un 
binario morto...


 cose e poi viene proposto mandando le novità allo sbaraglio.
Ma no, non dico questo anche se spesso i colpi di genio nascono quando sei 
nel cesso e le piu' grandi cazzate le fai proprio quando invece ti dici 
"Allora, cerchiamo di fare le cose fatte bene..." (vedi ad esempio chi ha 
inventato il connettore USB, un connettore universale che devi piantarlo 
almeno 2 volte prima di capire come devi girarlo).
Dico solo che (e non ce la faccio quasi piu') ci sono molti a cui queste 
innovazioni:
    NON interessano
    NON servono
    e sopratutto NON sono un investimento (perche' i fatti mi cosano, altro 
che pugnette)
Ue ragazzi, io ci HO provato. Chi vuol intendere intenda, altrimenti 
inCamper.
E quando comincio a parlare in questo modo vuol dire che sono proprio 
arrivato alla frutta (la prossima risposta a questo thread la troverai su 
it.hobby.umorismo...)


 troverai su it.hobby.umorismo...)
LOL


 cose che sono *DAVVERO* importanti..
Certo, anche in assembler puoi fare tutto ma non mi metterei mai a fare le 
cose che faccio oggi con WPF. È una questione di tempi e quindi di costi.
Tanto più è il supporto a disposizione dello sviluppatore, tanto più è 
raffinato il livello dell'applicazione finale.
All'inizio in pochi potevano dare una GUI ad un prodotto, oggi lo fanno 
tutti. Prima comunicare tra moduli di applicazioni era complesso, oggi in 
poche righe lo può fare chiunque... tutto tempo che può essere speso per 
arricchire il prodotto finale.
Innovazione significa "introdurre sistemi o metodi nuovi", non inventare 
metodi che cambiano l'universo. L'innovazione c'è perché ci sono molte cose 
che oggi puoi fare e che prima non erano disponibili allo sviluppatore. WPF 
è innovativo perché propone un modello di sviluppo della UI completamente 
nuovo rispetto a tutti i predecessori. WCF è innotvativo perché è il primo 
esempio di creazione di un sistema di comunicazione distribuito che 
prescinde dal protocollo standard che deve utilizzare, WF è innovativo 
perché propone un'infrastruttura per sviluppare secondo la logica 
sequenziale e macchine a stati.... ma non c'è la pretesa aver inventato la 
GUI, le macchine a stati o chissà che altro.
