Programmazione C o Visual Basic?

[ingframin]

Uagliù.... Il povero Cristo del primo post voleva un consiglio tra vb e c per iniziare a programmare da zero perché non ne sa nulla e voi vi mettete a parlare di LINQ e puntatori a 64 bit e codice unmanaged?
Facciamolo un piccolo sunto:
1) Tra i due linguaggi del post originario io suggerisco C.
Trovo assolutamente che sia fattibile partire da li soprattutto leggendo
il libro "Il linguaggio C: principi di programmazione e manuale di riferimento"
di Brian W. Kernighan, Dennis M. Ritchie (buon anima).
Ovviamente questa è anche la base per poi apprendere Objective-C e C++
che ti possono servire per gli iCosi (iPhone, iPod, iTostapane, ecc...).

2) Se invece hai più ampie vedute parti da Python che è molto meglio e ti risparmia tanti grattacapi, soprattutto se non sei un grande smanettone
e poi è molto molto molto più didattico. Anche qui puoi comprare "Imparare Python" di Mark Lutz, seguire il consiglio del libro in firma a cdmauro, cercare su internet. L'unica cosa che non manca in Python e proprio la documentazione per principianti.

3) Per quanto riguarda .Net... A me non piace legarmi a una ditta in particolare... Vedi XNA, ci sono un sacco di persone che hanno studiato e fatto giochi in C# con XNA, ora pare XNA non verrà mai più aggiornato e la 4 sarà l'ultima versione (basata per altro su directx 9) :-/.
In ogni caso C# è uno standard ECMA quindi puoi stare tranquillo che non verrà abbandonato.

4) Java è il futuro! Ma probabilmente non sarà mai il presente XD
Ad oggi sono molto poche le applicazioni desktop scritte in Java, idem per i giochi. Sicuramente è molto friendly per i principianti, io all'uni ho iniziato con Java e probabilmente è un buon compromesso. Non so a livello di mac come siete messi in ambito Java.
Se hai voglia potrebbe essere tranquillamente un'alternativa valida agli altri succitati linguaggi e soprattutto ti apre abbastanza porte nel mondo del lavoro (così come C#).

In bocca al lupo!
Poi ci sono anche linguaggi simpatici eh... http://www.bigzaphod.org/cow/

[tomminno]

Originariamente inviato da LMCH

Il nome dice tutto: IntPtr ... ed invece è una struct (per serie: cominciamo beeene!)

Scusa eh ma in .Net ci sono solo class (reference type) e struct (value type)
Cos'altro dovevano usare?

E' un escamotage aggiunto dopo che si sono accorti che a troppi sviluppatori (pure ai loro che mangiano pane e volpe) era necessario interfacciarsi in modo portabile con codice unmanaged.

IntPtr è stato aggiunto nella versione 1.1 che non esiste per i 64bit, quindi di quale limite nella portabilità ti stai lamentando?
Che non puoi scrivere codice .Net 1.0 portabile sui 64bit?

Infine se per te è così importante l'unmanaged Microsoft ha subito fornito la risposta: C++/CLI.

La prima soluzione ufficiale di Microsoft era stata del tipo: "Veh! Se volete la portabilita dei puntatori unamanaged usate interi a 64bit per memorizzarli in codice managed"

Scusa ma te hai avuto bisogno di scrivere codice .Net 1.X che giri a 64bit???
In un applicativo a 32 bit i puntatori sono sempre a 32bit e non puoi mischiare codice a 32 bit con codice a 64bit. E dato che .Net 1.0 c'era solo a 32bit non vedo dove possa essere il problema.
Per .Net 1.1 il problema era stato risolto con IntPtr, ma comunque non poteva girare a 64bit. Solo con il 2.0 puoi scrivere applicativi "portabili", ma in questo caso hai tutti gli strumenti per farlo.

Se vuoi considera .Net 1.0 la alfa, 1.1. la beta e la 2.0 la versione definitiva che offre tutte le funzionalità come devono essere.
Anche Microsoft ha risorse limitate, hanno aggiunto funzionalità nel tempo come fanno tutte le aziende che producono software.

[-sparkster-]

Originariamente inviato da ingframin

Uagliù.... Il povero Cristo del primo post voleva un consiglio tra vb e c per iniziare a programmare da zero perché non ne sa nulla e voi vi mettete a parlare di LINQ e puntatori a 64 bit e codice unmanaged?
Facciamolo un piccolo sunto:
1) Tra i due linguaggi del post originario io suggerisco C.
Trovo assolutamente che sia fattibile partire da li soprattutto leggendo
il libro "Il linguaggio C: principi di programmazione e manuale di riferimento"
di Brian W. Kernighan, Dennis M. Ritchie (buon anima).
Ovviamente questa è anche la base per poi apprendere Objective-C e C++
che ti possono servire per gli iCosi (iPhone, iPod, iTostapane, ecc...).

2) Se invece hai più ampie vedute parti da Python che è molto meglio e ti risparmia tanti grattacapi, soprattutto se non sei un grande smanettone
e poi è molto molto molto più didattico. Anche qui puoi comprare "Imparare Python" di Mark Lutz, seguire il consiglio del libro in firma a cdmauro, cercare su internet. L'unica cosa che non manca in Python e proprio la documentazione per principianti.

3) Per quanto riguarda .Net... A me non piace legarmi a una ditta in particolare... Vedi XNA, ci sono un sacco di persone che hanno studiato e fatto giochi in C# con XNA, ora pare XNA non verrà mai più aggiornato e la 4 sarà l'ultima versione (basata per altro su directx 9) :-/.
In ogni caso C# è uno standard ECMA quindi puoi stare tranquillo che non verrà abbandonato.

4) Java è il futuro! Ma probabilmente non sarà mai il presente XD
Ad oggi sono molto poche le applicazioni desktop scritte in Java, idem per i giochi. Sicuramente è molto friendly per i principianti, io all'uni ho iniziato con Java e probabilmente è un buon compromesso. Non so a livello di mac come siete messi in ambito Java.
Se hai voglia potrebbe essere tranquillamente un'alternativa valida agli altri succitati linguaggi e soprattutto ti apre abbastanza porte nel mondo del lavoro (così come C#).

In bocca al lupo!
Poi ci sono anche linguaggi simpatici eh... http://www.bigzaphod.org/cow/

Ciao e grazie per la considerazione!!

Io infatti volevo procurarmi il libro di Brian & Dennis, ma molti dicono che non sia attuale (è stato scritto nel 1978 da quanto ne so) e quindi poco consono per lo sviluppo nel presente/futuro; altri sostengono che sia un buon punto di partenza anche per i novizi. Tu cosa ne pensi? E' vero poi che imparare C ti aiuta a comprendere il funzionamento della macchina e cosa vuol dire programmare? (Se tutto questo fosse vero io propenderei per questo linguaggio, come inizio, perchè non mi piace fare le cose a metà e perchè un vero informatico, come sosteneva un altro utente intervenuto in questo thread, secondo me deve anche capire cosa si cela dietro quello che sta facendo, carpirne l'essenza)

P.s.: crepi il lupo!!!

[cdimauro]

Originariamente inviato da -sparkster-

E' vero poi che imparare C ti aiuta a comprendere il funzionamento della macchina

No.

e cosa vuol dire programmare?

No.

(Se tutto questo fosse vero io propenderei per questo linguaggio, come inizio, perchè non mi piace fare le cose a metà e perchè un vero informatico, come sosteneva un altro utente intervenuto in questo thread,

Un "vero" informatico ha un solo dogma da seguire: questo.

secondo me deve anche capire cosa si cela dietro quello che sta facendo, carpirne l'essenza)

In questo caso ti consiglio un buon corso di fisica teorica.

[LMCH]

Originariamente inviato da cdimauro

Comunque non mi sembra che SafeHandle crei problemi, per lo meno da quel che ho letto, e il codice rimane "safe" / managed.

Non ho mai scritto che "Safehandle crea problemi".

Quello che ho continuato a ripetere nei post precedenti è che le varie "pezze" non risolvono davvero il problema di base che ha portato alla loro introduzione.

[LMCH]

Originariamente inviato da tomminno

Scusa eh ma in .Net ci sono solo class (reference type) e struct (value type)
Cos'altro dovevano usare?

Non so come dirtelo senza ferire i tuoi sentimenti ma ...
Ho già scritto più volte che puntatori ed handle dovevano essere gestiti come tipi nativi (quelli che in netspeak sono chiamati "tipi primitivi").
http://msdn.microsoft.com/it-it/libr...=vs.71%29.aspx

Originariamente inviato da tomminno

Anche Microsoft ha risorse limitate, hanno aggiunto funzionalità nel tempo come fanno tutte le aziende che producono software.

Non è un problema di risorse limitate, ma di pessima progettazione iniziale.
Azz! Persino il C gestisce i puntatori come tipi nativi, non è che gli esempi non mancassero, con .Net dovevano solo fare la stessa cosa per puntatori ed handle e fornire maggiori controlli e validazioni a livello di compilatore e runtime (che potevano poi essere migliorati e resi più efficaci nelle release successive senza dover introdurre nuovi tipi, ecc. ecc.).

La cosa più fastidiosa è che Microsoft con la versione successiva di .Net poteva tranquillamente ridefinire il CLR per gestire la cosa a livello di tipi primitivi ma ha scelto di mettere pezze più ad alto livello che non risolvevano completamente il problema.
Si tratta della soluzione che sceglierebbe un programmatore "che non ha controllo sul runtime" (e quindi non può fare altro che introdurre dei wrapper "per metterci una pezza parziale sopra"), quando lo fa chi ha il pieno controllo del runtime non è una bella cosa.

Ma del resto, se si fa attenzione alle modifiche introdotte con Windows 8 è evidente che pure all'interno di Microsoft c'è parecchia insoddisfazione riguardo il modo in cui è stato gestito lo sviluppo iniziale e l'evoluzione di .Net.

A parole .Net "era il futuro" ma con l'introduzione di WinRT è sin troppo evidente che in realtà .Net è "solo" il successore di Visual Basic (quello precedente a .Net).

Sia ben chiaro, .Net è un ottima scelta per un certo tipo di applicazioni ma pensare che sia davvero la panacea che Microsoft dice che sia è un grave errore.

[tomminno]

Originariamente inviato da LMCH

Non so come dirtelo senza ferire i tuoi sentimenti ma ...
Ho già scritto più volte che puntatori ed handle dovevano essere gestiti come tipi nativi (quelli che in netspeak sono chiamati "tipi primitivi").
http://msdn.microsoft.com/it-it/libr...=vs.71%29.aspx

Io non vorrei ferire i tuoi, ma i tipi "primitivi" come li definisci te, in .Net sono le struct, più precisamente dei ValueType...
Forse sarebbe il caso di dare una ripassatina alle basi del .Net prima di pontificare errori di progettazione dell'intero sistema.

Non è un problema di risorse limitate, ma di pessima progettazione iniziale.

Perchè mai pessima?
Se vuoi il nativo in .Net c'è C++/CLI. Ti fai il tuo layer e poi lo usi in C#.
C# non fatto per lavorare in nativo. Se cerchi il nativo in C# stai sbagliando linguaggio. E questo non è colpa di Microsoft, sei te che stai usando lo strumento sbagliato.
.Net fa di tutto per cercare di tenere lontane le persone dalle magagne dello sviluppo "nativo".

Azz! Persino il C gestisce i puntatori come tipi nativi, non è che gli esempi non mancassero, con .Net dovevano solo fare la stessa cosa per puntatori ed handle e fornire maggiori controlli e validazioni a livello di compilatore e runtime (che potevano poi essere migliorati e resi più efficaci nelle release successive senza dover introdurre nuovi tipi, ecc. ecc.).

In .Net hai IntPtr e SafeHandle, quindi dove sta il problema?
Che non erano presenti nella versione 1.0 del runtime? E chi se ne frega!
Non mi sembra che abbiano dovuto fare chissà quali strvolgimenti per introdurli.

La cosa più fastidiosa è che Microsoft con la versione successiva di .Net poteva tranquillamente ridefinire il CLR per gestire la cosa a livello di tipi primitivi ma ha scelto di mettere pezze più ad alto livello che non risolvevano completamente il problema.

Guarda che IntPtr è un tipo "primitivo"! E' un value type! Meno di quello in .Net non c'è.
SafeHandle no, ma è ovvio il perchè: implementa IDisposable.

Si tratta della soluzione che sceglierebbe un programmatore "che non ha controllo sul runtime" (e quindi non può fare altro che introdurre dei wrapper "per metterci una pezza parziale sopra"), quando lo fa chi ha il pieno controllo del runtime non è una bella cosa.

IntPtr è esattamente come un Int32, il programmatore della strada non avrebbe potuto farlo.

Ma del resto, se si fa attenzione alle modifiche introdotte con Windows 8 è evidente che pure all'interno di Microsoft c'è parecchia insoddisfazione riguardo il modo in cui è stato gestito lo sviluppo iniziale e l'evoluzione di .Net.

Guarda che qui stai sbagliando di grosso.
.Net non ha mai fatto presa sul team che sviluppa Windows, perchè per lo sviluppo del sistema operativo non serve a niente.

A parole .Net "era il futuro" ma con l'introduzione di WinRT è sin troppo evidente che in realtà .Net è "solo" il successore di Visual Basic (quello precedente a .Net).

WinRT è il successore di Win32 per quanto riguarda la parte grafica.
Windows è qualcosa in più di una interfaccia grafica.
.Net è un modo comodo per sviluppare in Windows, ma le basi rimarranno sempre e soltanto native, fintanto che avremo a che fare con Windows.
E poi sicuramente ci sarà modo di usare WinRT da .Net, quindi non vedo il problema.

Sia ben chiaro, .Net è un ottima scelta per un certo tipo di applicazioni ma pensare che sia davvero la panacea che Microsoft dice che sia è un grave errore.

.Net è attualmente il miglior modo per sviluppare software sotto Windows.
Sinceramente mi suona strano aver tutta questa necessità di accedere in nativo: quali componenti di Windows non mappate in .Net stavi cercando di usare?

[ingframin]

Originariamente inviato da -sparkster-

Ciao e grazie per la considerazione!!

Io infatti volevo procurarmi il libro di Brian & Dennis, ma molti dicono che non sia attuale (è stato scritto nel 1978 da quanto ne so) e quindi poco consono per lo sviluppo nel presente/futuro; altri sostengono che sia un buon punto di partenza anche per i novizi. Tu cosa ne pensi? E' vero poi che imparare C ti aiuta a comprendere il funzionamento della macchina e cosa vuol dire programmare? (Se tutto questo fosse vero io propenderei per questo linguaggio, come inizio, perchè non mi piace fare le cose a metà e perchè un vero informatico, come sosteneva un altro utente intervenuto in questo thread, secondo me deve anche capire cosa si cela dietro quello che sta facendo, carpirne l'essenza)

P.s.: crepi il lupo!!!

Allora... Il punto fondamentale del mio post è che il linguaggio non è importante all'inizio, all'inizio è importante imparare la mentalità. Il libro di Kernighan e Ritchie è un libro pensato per un corso base di informatica e quindi ci sono tutti gli esercizi e le spiegazioni tipici dei corsi introduttivi di informatica. Sul fatto che non sia attuale... Tieni conto che non è dopo una settimana che leggi il libro che programmi il nuovo MS Office.
Quindi, impara la logica prima. Il mio consiglio si associa alla voce di Cesare, impara col Python. Ti risparmia un sacco di grattacapi e ti fa concentrare sulla logica più che sul linguaggio. Quando poi sarai pratico tutto il resto verrà dopo.
Se vuoi imparare qualcosa di più C-like puoi provare con Java usando ad esempio "Concetti di informatica e fondamenti di Java" (http://www.apogeonline.com/libri/9788850323180/scheda ) di Cay Horstmann oppure col C oppure col C# (ma qui non so consigliarti perché non l'ho mai studiato).
Per quanto riguarda la storia del dietro le quinte... Quella viene col tempo, considera che la maggior parte degli informatici non ha idea di cosa ci sia dietro le quinte, quello è in genere territorio degli elettronici.
L'importante è avere le idee abbastanza chiare sul funzionamento della macchina e quello verrà col tempo e con lo studio.
Se proprio ti interessa come è fatto un computer mi permetto di consigliarti "Reti logiche e calcolatori" (http://www.libreriauniversitaria.it/.../9788833954875) di Fabrizio Luccio e Linda Pagli, oppure
"Architettura dei calcolatori. Un approccio strutturale. Con CD-ROM"
di Andrew S. Tanenbaum (http://www.libreriauniversitaria.it/...9788871922713).
Ma sono libri successivi. Prima impara a programmare e poi approfondisci gli aspetti che più ti interessano, magari iscrivendoti a un corso universitario.
Soprattutto poniti degli obiettivi alla tua portata, chi dopo il tipico "Hello world" cerca di rifare World of Warcraft ci resta male

[jonnykaraoke]

scusami cdimauro, io faccio ing. informatica e da quello che ho potuto studiare sull'informatica ho potuto constatare una tua affermazione davvero errata...io non so se conosci il C (perchè mi sembra proprio di no) ma ti posso dire che un requisito necessario per conoscere il funzionamento di un computer è proprio avere almeno le basi su quel linguaggio...in architettura dei calcolatori se non conosci il C è come andarti a seguire una messa in latino, spiegami come fai se non conosci quella lingua??? se vogliamo parlare di programmatori sotto alienazione che non capiscono le conseguenze dei loro input allora spero che chi lo è si accontenti di questo...chi vuole avere ambizioni e quindi conoscere il loro operato allora si parte dal basso livello per poi salire in alto...io ho cominciato dal python non conoscendo nulla di programmazione...poi sono passato al C e ho provato la stessa sensazione di quando non sapevo nulla e ho fatto il primo hello world in python....poi dal C sono passato al java e in solo 3 giorni mi sono impadronito del linguaggio...il python è bello da usare e ti fa risparmiare tempo....ma un esperto sa sempre quello che sta facendo...non so come ragionano i programmatori ma gli aspiranti ingegneri (come me) o ingegneri non si fermano alla superficialità....e a chiunque voglia iniziare un linguaggio si ponga la domanda per cui nelle facoltà informatiche si inizia con un linguaggio come C e non un linguaggio a interprete come python...

[tomminno]

Originariamente inviato da jonnykaraoke

se vogliamo parlare di programmatori sotto alienazione che non capiscono le conseguenze dei loro input allora spero che chi lo è si accontenti di questo...

I sistemi reali sono talmente complessi che sperare di capire tutto è pura utopia.
Quando definisci un workflow di business non stai a pensare a quale valore assumerà un determinato registro di una CPU di un cluster.

chi vuole avere ambizioni e quindi conoscere il loro operato allora si parte dal basso livello per poi salire in alto...io ho cominciato dal python non conoscendo nulla di programmazione...poi sono passato al C e ho provato la stessa sensazione di quando non sapevo nulla e ho fatto il primo hello world in python....poi dal C sono passato al java e in solo 3 giorni mi sono impadronito del linguaggio...

Beh insomma in 3 giorni non impari a programmare ad oggetti, men che meno ad usare un linguaggio vasto come Java.

ma un esperto sa sempre quello che sta facendo...non so come ragionano i programmatori ma gli aspiranti ingegneri (come me) o ingegneri non si fermano alla superficialità....

Come ingegnere spero che la tua aspirazione non sia fare il programmatore, altrimenti stai buttando via tempo.
E poi hai una visione distorta dei linguaggi di programmazione. Non sono il fine ma il mezzo con cui costruire altro.
Una persona che non si ferma alla superficialità utilizza il linguaggio migliore per risolvere il problema a cui deve dare una risposta.
Poi nella realtà nascono ostacoli per cui uno è costretto ad usare il linguaggio per cui riesce a trovare skill all'interno dell'azienda.
Ma qui nasce il capitolo di gestione dei progetti software che esula dalla programmazione spicciola.

e a chiunque voglia iniziare un linguaggio si ponga la domanda per cui nelle facoltà informatiche si inizia con un linguaggio come C e non un linguaggio a interprete come python...

Quando ho fatto io ingegneria pensa che la programmazione la davano per scontata e non te la insegnavano nemmeno, quando c'era un elaborato lo potevi fare con il linguaggio che preferivi, l'importante era risolvere il problema assegnato...

[LMCH]

Originariamente inviato da tomminno

Io non vorrei ferire i tuoi, ma i tipi "primitivi" come li definisci te, in .Net sono le struct, più precisamente dei ValueType...
Forse sarebbe il caso di dare una ripassatina alle basi del .Net prima di pontificare errori di progettazione dell'intero sistema.

Io non pontifico, esprimo una mia opinione basata su fatti ben precisi e sopratutto a suo tempo ho letto la documentazione Microsoft:
Ad esempio infatti leggi sul link che avevo riportato ( http://msdn.microsoft.com/it-it/libr...=vs.71%29.aspx )
trovi le seguenti affermazioni:

Originariamente inviato da Documentazione su MSDN

I tipi primitivi si differenziano rispetto ad altri tipi struttura in quanto permettono alcune ulteriori operazioni:

• Tutti i tipi primitivi consentono la creazione di valori mediante la scrittura di rappresentazioni formali. 123I, ad esempio, è una rappresentazione formale di tipo Integer.
• È possibile dichiarare costanti dei tipi primitivi.
• Quando gli operandi di un'espressione sono tutte costanti di tipo primitivo, in fase di compilazione sarà possibile valutare l'espressione tramite il compilatore. Un'espressione di questo tipo è detta espressione costante.

A te possono sembrare differenze da poco, ma combinando questo con ulteriori vincoli a livello di runtime in un colpo solo ottieni un interfaccia molto più pulita e sicura verso codice e dati unmanaged e completamente trasparente (anche perchè la rappresentazione formale può essere resa distinta da quella degli int, cosa che invece non succede con IntPtr e SafeHandle).

Originariamente inviato da tomminno

Perchè mai pessima?
Se vuoi il nativo in .Net c'è C++/CLI. Ti fai il tuo layer e poi lo usi in C#.
C# non fatto per lavorare in nativo. Se cerchi il nativo in C# stai sbagliando linguaggio. E questo non è colpa di Microsoft, sei te che stai usando lo strumento sbagliato.
.Net fa di tutto per cercare di tenere lontane le persone dalle magagne dello sviluppo "nativo".

Il motivo è che se .Net permette di interfacciarsi con codice/dati unmanaged ma le problematiche di interfacciamento sono state evidentemente trascurate, si può parlare tranquillamente di pessima progettazione del sistema.
Questo ha anche notevoli ripercussioni sulla possibilità di scrivere codice managed "malevole" e scusa se è poco.

Originariamente inviato da tomminno

Guarda che IntPtr è un tipo "primitivo"! E' un value type! Meno di quello in .Net non c'è.

No, Microsoft la pensa diversamente da te, leggi quello che avevo quotato sopra.

Originariamente inviato da tomminno

IntPtr è esattamente come un Int32, il programmatore della strada non avrebbe potuto farlo.

No, per il semplice motivo che non è un tipo primitivo, in base alla piattaforma viene essenzialmente mappato su un integer con dimensione dipendente dalla piattaforma, ma non ha una semantica distinta e gestita allo stesso livello di un vero tipo primitivo distinto.

Originariamente inviato da tomminno

Guarda che qui stai sbagliando di grosso.
.Net non ha mai fatto presa sul team che sviluppa Windows, perchè per lo sviluppo del sistema operativo non serve a niente.

Guarda che ho scritto esplicitamente "parecchia insoddisfazione riguardo il modo in cui è stato gestito lo sviluppo iniziale e l'evoluzione di .Net".

Quando parte delle competenze che in precedenza erano del team che curava lo sviluppo di .Net vengono passate al team del SO, quando al tempo stesso il team del SO sviluppa un nuovo runtime "di base" e quando viene presentato c'è maggior riguardo verso tool di sviluppo alternativi a .Net ...
Beh! Il messaggio mi sembra sin troppo chiaro.

Originariamente inviato da tomminno

WinRT è il successore di Win32 per quanto riguarda la parte grafica.

Mi sa che stai confondendo Direct2D con WinRT, lascio a te trarre le dovute conclusioni.

Originariamente inviato da tomminno

Sinceramente mi suona strano aver tutta questa necessità di accedere in nativo: quali componenti di Windows non mappate in .Net stavi cercando di usare?

Esistono quelle cose chiamate "librerie di terze parti scritte in C/C++" che essendo parecchio massicce nessuno sano di mente riscriverebbe in .Net solo per i gusto di farlo.

Specialmente se Windows-qualcosa non è l'unico target.

[nico159]

No, per il semplice motivo che non è un tipo primitivo, in base alla piattaforma viene essenzialmente mappato su un integer con dimensione dipendente dalla piattaforma, ma non ha una semantica distinta e gestita allo stesso livello di un vero tipo primitivo distinto.

Uhm? Mi sta che un pò di confusione la stai facendo anche tu

http://msdn.microsoft.com/en-us/libr...primitive.aspx

The primitive types are Boolean, Byte, SByte, Int16, UInt16, Int32, UInt32, Int64, UInt64, IntPtr, UIntPtr, Char, Double, and Single.

Ma del resto, se si fa attenzione alle modifiche introdotte con Windows 8 è evidente che pure all'interno di Microsoft c'è parecchia insoddisfazione riguardo il modo in cui è stato gestito lo sviluppo iniziale e l'evoluzione di .Net.

Forse hai tu un pò di difficoltà nel comprendere cos'è WinRT, dato che non sostituisce .Net, ma si presenta come alternativa a Win32
http://tirania.org/blog/archive/2011/Sep-15.html

.Net è uno dei 3 ambienti per utilizzare e creare componenti WinRT, insieme a C++ e Javascript

Come ha detto tomminno, WinRT è una enorme rivoluzione che permette di fatto di creare applicazioni mobili per i futuri tablet Windows (e non solo)

[tomminno]

Originariamente inviato da LMCH

Io non pontifico, esprimo una mia opinione basata su fatti ben precisi e sopratutto a suo tempo ho letto la documentazione Microsoft:
Ad esempio infatti leggi sul link che avevo riportato ( http://msdn.microsoft.com/it-it/libr...=vs.71%29.aspx )
trovi le seguenti affermazioni:


A te possono sembrare differenze da poco, ma combinando questo con ulteriori vincoli a livello di runtime in un colpo solo ottieni un interfaccia molto più pulita e sicura verso codice e dati unmanaged e completamente trasparente (anche perchè la rappresentazione formale può essere resa distinta da quella degli int, cosa che invece non succede con IntPtr e SafeHandle).

Scusa eh ma a te cosa stampa questa riga di codice?
Console.WriteLine(typeof(IntPtr).IsPrimitive);
A me dice true. Ovvero IntPtr è un tipo primitivo. Di cosa stai discutendo quindi?
Tra l'altro mi sono riguardato il supporto. IntPtr è presente fin dal .Net 1.0

Il motivo è che se .Net permette di interfacciarsi con codice/dati unmanaged ma le problematiche di interfacciamento sono state evidentemente trascurate, si può parlare tranquillamente di pessima progettazione del sistema.

Le tue crtiche erano: non poter scrivere software "portabile" da 32 a 64bit mentre IntPtr c'è fin dalle origini. Poi che non c'era un tipo distinto per la gestione degli Handle che è stato aggiunto da .Net 2.0.
Poi ti lamenti che IntPtr non è primitivo (mentre lo è) e quindi pontifichi che in .Net non sono state affrontate le problematiche di interfacciamento.

Questo ha anche notevoli ripercussioni sulla possibilità di scrivere codice managed "malevole" e scusa se è poco.

Ovvero?
Certo che se il codice gira in FullTrust, puoi fare gli stessi danni che faresti in C++. Ma non mi pare proprio che .Net sia stato pensato per non far scrivere codice malevolo.
Anche perchè gli applicativi desktop girano di default in FullTrust...

No, Microsoft la pensa diversamente da te, leggi quello che avevo quotato sopra.

Microsoft la pensava come me: IntPtr è primitivo. Sei te che credi che non lo sia contro ogni evidenza.

No, per il semplice motivo che non è un tipo primitivo, in base alla piattaforma viene essenzialmente mappato su un integer con dimensione dipendente dalla piattaforma, ma non ha una semantica distinta e gestita allo stesso livello di un vero tipo primitivo distinto.

IntPtr è un tipo primitivo.

Guarda che ho scritto esplicitamente "parecchia insoddisfazione riguardo il modo in cui è stato gestito lo sviluppo iniziale e l'evoluzione di .Net".

Fonti a riguardo?
Che poi .Net non abbia fatto presa sul dev team di Windows è risaputo. Probabilmente quando hanno dovuto resettare lo sviluppo di Vista perchè dall'alto volevano a tutti i costi usare .Net si sono ricreduti un pò tutti all'interno di Microsoft.

Se per questo anche gli installer di software come SqlServer e BizTalk sono delle applicazioni MFC...

Quando parte delle competenze che in precedenza erano del team che curava lo sviluppo di .Net vengono passate al team del SO, quando al tempo stesso il team del SO sviluppa un nuovo runtime "di base" e quando viene presentato c'è maggior riguardo verso tool di sviluppo alternativi a .Net ...
Beh! Il messaggio mi sembra sin troppo chiaro.

Veramente hanno semplicemente ritenuto valido XAML e hanno decido di inglobarne lo sviluppo in Windows, tutto finalizzato all'utilizzo di Windows nei tablet. Se Windows Phone 7 richiede un processore ad 1GHz per funzionare fluidamente grazie a .Net, Windows completo non poteva assolutamente competere con Android sui tablet...

Mi sa che stai confondendo Direct2D con WinRT, lascio a te trarre le dovute conclusioni.

WinRT è il runtime dell'interfaccia Metro.
Se devi andare a leggere la configurazione della rete usi ancora le care vecchie Win32...

Esistono quelle cose chiamate "librerie di terze parti scritte in C/C++" che essendo parecchio massicce nessuno sano di mente riscriverebbe in .Net solo per i gusto di farlo.

Specialmente se Windows-qualcosa non è l'unico target.

Appunto a maggior ragione che te ne fai di .Net, dato che è solo per Windows?
Tanto vale andare di C++ e rimanere con un software unico per differenti sistemi operativi (tralascio appositamente Java per compassione).

[LMCH]

Originariamente inviato da nico159

Uhm? Mi sta che un pò di confusione la stai facendo anche tu

http://msdn.microsoft.com/en-us/libr...primitive.aspx

The primitive types are Boolean, Byte, SByte, Int16, UInt16, Int32, UInt32, Int64, UInt64, IntPtr, UIntPtr, Char, Double, and Single.

E' considerato un tipo primitivo perchè viene mappato di volta in volta su Int32 o su Int64, ma a livello di runtime, inizializzazione, ecc. non ha una semantica separata da essi.

Infatti, se ad esempio guardi in:
http://msdn.microsoft.com/en-us/libr...em.intptr.aspx
Trovi scritto esplicitamente:
"The IntPtr type is designed to be an integer whose size is platform-specific."

Mentre ad esempio in C i puntatori NON SONO interi ed hanno una semantica separata.

Se ci pensi, è un pochino grottesco che il C gestisca i puntatori in modo più sicuro di quando faccia .Net con gli IntPtr.

[LMCH]

Originariamente inviato da tomminno

Scusa eh ma a te cosa stampa questa riga di codice?
Console.WriteLine(typeof(IntPtr).IsPrimitive);
A me dice true. Ovvero IntPtr è un tipo primitivo. Di cosa stai discutendo quindi?
Tra l'altro mi sono riguardato il supporto. IntPtr è presente fin dal .Net 1.0

nico159 ti aveva preceduto su questo e gli ho già risposto chiaramente a riguardo.
Solo perchè è mappato su un intero (che è considerato un tipo primitivo) non lo trasforma automagicamente in un tipo primitivo distinto con semantica distinta.
Se non ti è chiaro il motivo, considera ad esempio cosa succede quando sommi un intero ad un puntatore in C e cosa succede in .Net quando sommi un intero ad un IntPtr.

Originariamente inviato da tomminno

Le tue crtiche erano: non poter scrivere software "portabile" da 32 a 64bit mentre IntPtr c'è fin dalle origini. Poi che non c'era un tipo distinto per la gestione degli Handle che è stato aggiunto da .Net 2.0.
Poi ti lamenti che IntPtr non è primitivo (mentre lo è) e quindi pontifichi che in .Net non sono state affrontate le problematiche di interfacciamento.

No, per prima cosa (messaggio #28) avevo scritto:

Originariamente inviato da LMCH

Ad esempio, il team di .Net ha sottovalutato in modo clamoroso l'importanza del codice unmanaged (con tutti i casini che comporta, basta vedere quanto hanno faticato per supportare anche i 64bit con il loro nuovo runtime "nato per essere portabile"), potevano prevedere "puntatori nativi" in modo esplicito e gestirli in modo molto più sicuro e portatile ed invece non hanno saputo fare di meglio che consigliare di usare interi a 64bit per memorizzare puntatori unamanaged in modo "portabile".

E' una cosa ben diversa da quello che mi attribuisci.

Poi (messaggio #37) avevo scritto ancora più chiaramente:

Originariamente inviato da LMCH

Gestire come tipi nativi distinti puntatori ed handle ed impedire che si possa manipolarli in modo incontrollato dal lato managed.

Attualmente con IntPtr viene esposto al programmatore se si tratta di puntatori o handle a 32bit oppure a 64bit e li puoi manipolare in tutti i modi possibili con degli interi.

Le operazioni "corrette" su puntatori ed handle sono un sottoinsieme più facile da controllare rispetto a quelle su generici interi e quindi (se ci avessero pensato mentre definivano la VM ed il runtime) in primo luogo avrebbero implementato handle e puntatori come due tipi separati con metodi ed operatori specifici (es: sugli handle non si dovrebbero fare operazioni di aritmetica dei puntatori) ed in secondo luogo avrebbero anche potuto includere nei puntatori informazioni sui range di indirizzi validi per operazioni su di esse (es: se la funzione nativa restituisce un puntatore ad una struct, il "puntatore" del CLR include indirizzo base e dimensione della struct in modo da impedire letture/scritture al di fuori di essa).

Dal punto di vista computazionale l'aggravio sarebbe quasi nullo e tutto il runtime sarebbe stato molto più robusto nei confronti di codice malevole o semplicemente di errori di programmazione nell'accesso a dati e/o codice unmanaged.

Mi sembra di essere stato sin troppo prolisso a riguardo, decisamente non ho scritto quello che mi hai attribuito circa 20 messaggi dopo.

Originariamente inviato da tomminno

WinRT è il runtime dell'interfaccia Metro.
Se devi andare a leggere la configurazione della rete usi ancora le care vecchie Win32...

WinRT include anche l'UI di Metro, ma non solo quella.
Nella presentazione durante Build 2011 c'era questo schemino che dovrebbe essere autoesplicativo:


A parte questo, solo perchè il programma di configurazione usa win32 non significa che non puoi fare la stessa cosa anche via WinRT ad esempio usando questo:
http://msdn.microsoft.com/en-us/libr...formation.aspx
Ad occhio e croce il motivo principale per usare ancora win32 per certe cose è che attualmente la documentazione di WinRT lascia parecchio a desiderare (senza contare possibili bug ancora da sistemare) e visto che win32 c'è ancora, non credo abbiano fretta di portare tutto e subito sotto WinRT.

Originariamente inviato da tomminno

Appunto a maggior ragione che te ne fai di .Net, dato che è solo per Windows?
Tanto vale andare di C++ e rimanere con un software unico per differenti sistemi operativi (tralascio appositamente Java per compassione).

Infatti io uso .Net solo se lo richiede espressamente il committente o dove ha senso farlo, per questo non è infrequente che mi devo interfacciare con roba mia o altrui (esempio OpenCV) che per portabilità è scritta in C/C++ e che non avrebbe senso riscrivere in C#.
In precedenza facevo lo stesso con VB4/5/6 al posto di .Net per le stesse ragioni.

[cdimauro]

Veramente IntPtr non è nato per gestire i puntatori. In C# (e in altri linguaggi .NET che supportano il concetto) i puntatori si gestiscono come faresti in C (con qualche differenza in alcuni casi), usando la keyword unsafe.

IntPtr nasce per gestire casi in cui t'interessa conservare interi o puntatori usando lo stesso tipo di dato, ma senza tanti sbattimenti riguardo alla sua dimensione a causa delle architetture a 32 o 64 bit, perché ci pensa il .NET a risolverti il problema, appunto.

In passato con Delphi ho avuto quest'esigenza (per memorizzare numeri o puntatori, a seconda del contesto, nel campo Tag degli elementi di alcune TreeView), e ho sentito la mancanza di un tipo come IntPtr, che m'avrebbe risolto il problema banalmente.

Originariamente inviato da jonnykaraoke

scusami cdimauro, io faccio ing. informatica e da quello che ho potuto studiare sull'informatica ho potuto constatare una tua affermazione davvero errata...

Vedremo.

io non so se conosci il C (perchè mi sembra proprio di no)

Solo di vista.

ma ti posso dire che un requisito necessario per conoscere il funzionamento di un computer è proprio avere almeno le basi su quel linguaggio...

In tal caso non hai che da dimostrarne la necessità, ma ne parlo meglio dopo.

in architettura dei calcolatori se non conosci il C è come andarti a seguire una messa in latino, spiegami come fai se non conosci quella lingua???

Forse perché proprio per quella materia serve altro? Al mio esame (sostenuto una 15ina d'anni fa, se non erro, ma è passato parecchio tempo) c'erano scritto e orale.

Scritto: data una procedura in Pascal che eseguiva alcune operazioni su array, convertirla in assembly 8086.

Orale: si parlava di diversi aspetti delle architetture degli elaboratori, fra cui, ad esempio, come sono implementati i singoli bit di memoria a livello di porte logiche / flip-flop.

Del C non c'era nessuna traccia.

Lo scritto l'ho passato senza usare alcuna variabile temporanea allocata sullo stack (professore e assistente non riuscivano a crederci), e all'orale all'ultima domanda bastarda dell'assistente (che, diciamo, non era molto rinomato fra gli studenti ) mi sono permesso di rispondere con aria di sufficienza "ovviamente è così...".

Il risultato lo puoi immaginare da solo.

Adesso mi aspetto che mi dimostri la necessità della conoscenza del C per quella dell'architettura degli elaboratori.

Sul resto concordo con tomminno.

[ingframin]

Architettura dei calcolatori:
- Scritto: 3 procedure da implementare in assembly 8086
- Orale: Ricerca binaria sempre in Assembly

Calcolatori elettronici:
-Scritto: automi a stati finiti + date 3 istruzioni assembler per JVM implementare la microarchitettura.
- Orale: porte logiche, flip/flop, architettura JVM (seguimmo il libro di Tanenbaum)

Architetture innovative:
-Scritto: Dato l'assembler (non completo, 3 o 4 istruzioni) progettare la microarchitetture + circuito per eseguirle
-Orale: Pipeline, Interrupt, Architettura Ultra SPARC II, Architettura Pentium 4, qualche altra cosa che non ricordo su circuiti aritmetici e confronto tra RISC e CISC con esempi di implementazione + qualcosa sugli automi.

C l'ho studiato per conto mio tra il terzo e il quarto anno di uni per un progetto personale, mai visto senno' a lezione in nessun corso.