Programmazione C o Visual Basic?

[pabloski]

Originariamente inviato da cdimauro

Per quanto mi riguarda un programmatore deve saper risolvere i problemi che si pongono davanti, nel "migliore" (col miglior compromesso possibile in base alla sua esperienza e conoscenza) dei modi.

si ok, ma questo non ci dice se questo fantomatico programmatore conosce il dietro le quinte o meno

essendo io partito dal basic, so benissimo che si può essere dei mostri nell'implementare programmi senza sapere molto di come funziona il sistema a basso livello

però se si vuole conoscere quel "basso livello" non c'è altra strada se non sporcarsi le mani con C e assembly

[cdimauro]

Conoscere i dettagli di basso livello non è più indispensabile, a meno che non si faccia un certo tipo di lavoro.

L'informatica tende sempre più verso l'alto livello, a raggiungere idealmente quello pseudocodice che da decenni viene usato per astrarre, eliminando proprio i dettagli di basso di livello.

[tomminno]

Originariamente inviato da FabryHw

Beh ma un prodotto che esce oggi, se fra 5 anni non ha subito evoluzioni non puoi dire che è morto "oggi".

Ok allora togli 4 anni e diciamo che è morto da 9 con l'uscita di Visual Studio 2002 e .Net 1.0

Secondo il tuo ragionamento allora il C è morto nel 1990, perché saranno anche usciti gli aggiornamenti del 2000 più un altro atteso in questi anni, ma è anche vero che la maggior parte dei compilatori supporta al 100% solo il C90 ed il resto è implementato parzialmente.

Mi pare che gcc supporti alla perfezione C99. E' Microsoft che non implementa il C99 perchè non è di suo interesse.

E cmq cosa intendi con mischiare il vecchio?

Nel senso che puoi parzialmente scrivere alla VB6.

Fonte il sito commerciale di F. Balena & Co. (sorry non Battilana) dove parlavano del suo tool (a pagamento) di conversione da VB6 a VB.Net.
Secondo lui VB ha ancora molto spazio ed i programmatori VB6 al più dovrebbero pensare a migrare le loro conoscienze su VB.Net e non pensare di ricominciare da zero con altri linguaggi tra cui C#.

Scopo per cui è stato sviluppato VB.Net

Poi Balena da Guru VB6 e VB.Net (nonché esperto C#, ma qui forse non un guru) proponeva degli esempi, in cui mostrava che C# non era per nulla superiore a VB.Net ma che entrambi i linguaggi potevano assolvere gli stessi compiti e che le prestazioni del codice CLR (sotto Dot.Net) alla fine erano pure uguali o quasi.

Il runtime è lo stesso.
E' la sintassi veramente barbara il dramma del VB...

Tra quegli esempi ne mostrava anche alcuni dove VB.Net aveva dei vantaggi su C# permettendo di fare cose non fattibili in C# (o fattibili solo con codice scomodo da scrivere).
Se ritrovo il link lo posto.

Sarei curioso di vederlo. In compenso io ne ho tanti altri in cui a scrivere in C# è l'IDE mentre in VB devo indovinare la mega stringona da scrivere (es. i delegati).

Inoltre mi pare di aver letto in giro che VB.Net 2010 avrebbe già il supporto a DLR ma che Microsoft non lo abbia rilasciato solo perché non è (o era) in grado di rilasciarlo anche per C# e non voleva creare scompensi (rendendo VB.Net troppo in vantaggio su C#).

Strano dato che il DLR deve integrarsi con il CLR e quindi essere indipendente dal linguaggio.

[pabloski]

Originariamente inviato da cdimauro

Conoscere i dettagli di basso livello non è più indispensabile, a meno che non si faccia un certo tipo di lavoro.

appunto, ma è difficile che un informatico faccia per tutta la vita un lavoro che lo terrà lontano da quei dettagli a basso livello

detto questo, beh, se si dev'essere degli esperti bisogna esserlo....nessun corso di laurea salta architettura dei calcolatori

[cdimauro]

Originariamente inviato da tomminno

Mi pare che gcc supporti alla perfezione C99.

L'ultima volta che ho controllato il manuale del GCC è stato un po' di mesi fa, e non era totalmente compliant col C99.

E' Microsoft che non implementa il C99 perchè non è di suo interesse.

Non lo fa praticamente nessuno. Purtroppo lo standard di riferimento rimane l'ANSI C89.

Oltre, si va direttamente di C++.

Originariamente inviato da pabloski

appunto, ma è difficile che un informatico faccia per tutta la vita un lavoro che lo terrà lontano da quei dettagli a basso livello

Quando ne avrei bisogno li imparerai. Tantissime cose le ho imparate così: per necessità.

detto questo, beh, se si dev'essere degli esperti bisogna esserlo....nessun corso di laurea salta architettura dei calcolatori

Se ti chiedessi la definizione di esperto?

Esperto <> laureato <> conoscente architettura degli elaboratori.

[LMCH]

Originariamente inviato da Kralizek

posso capire per VB6 e precedenti, ma VB.NET e C# hanno un bella base di posizioni aperte in tutto il mondo e, soprattutto, la comunitá open source si sta iniziando a dare da fare anche in ambito .NET con progetti sempre piú interessanti.

Il mio punto è che se si può scegliere (ed io spesso posso), sono da evitare per i motivi che avevo descritto.

Originariamente inviato da Kralizek

Tra l'altro, a differenza di altri linguaggi piú "consigliati", C# e VB.NET hanno un'evoluzione molto piú veloce cosa che tra l'altro invoglia i progetti open source a muoversi da un porting line-to-line ad un porting funzionalmente compatibile (tranne pochi casi, come lucene.net )

Uhm! Sbaglio o quando dici "porting" stai parlando di riscrittura completa dei sorgenti ?

Originariamente inviato da Kralizek

poi é vero che io sono un fanatico di LINQ e da poco in ufficio ci siamo creati una nostra libreria per eseguire alcune operazioni in maniera piú memory-efficient, peró non vedo nessuna tecnologia che nello stesso costrutto mi permette di definire una query sql anche complessa, filtrarla ulteriormente in memoria e trasformare tutto in xml: ovviamente, il tutto verrá poi eseguito solo quando il risultato sará veramente necessario.

Ci sono buoni motivi per cui cose simili sono da evitare, ma mi limiterò a farti notare che in realtà LINQ non fa altro che "integrare" a colpi di zucchero sintattico buona parte di SQL in C# e VB .Net facendo finta che siano un unico linguaggio.
Ti lega alla piattaforma in cambio di una maggior velocità di codifica di applicazioni "una botta e via".

Originariamente inviato da Kralizek

Ovviamente non voglio buttarla alla solita sterile guerra di quale piattaforma ce l'ha piú lungo. semplicemente non mi trovo daccordo sulla tua osservazione sull'utilizzabilitá dei lunguaggi .NET

Non è questione di "utilizzabilità" ma di vantaggi a medio e lungo termine.
Se "possiedi il software" (nel senso che è tuo o che ne hai la responsabilità) è meglio evitare di legarsi mani e piedi ad un "fornitore di tool" con priorità e precedenti come quelli di Microsoft.

[Kralizek]

Originariamente inviato da LMCH

Il mio punto è che se si può scegliere (ed io spesso posso), sono da evitare per i motivi che avevo descritto.

Ecco questo è il concetto più importante: analizzare i requisiti che si devono soddisfare e, possibilmente, fare la scelta più funzionale.

Uhm! Sbaglio o quando dici "porting" stai parlando di riscrittura completa dei sorgenti ?

Premesso che i porting di cui parlo sono di librerie OS disponibili per Java (Hibernate e Lucene, per spararne due) e che a poco a poco vengono portate su .NET o riscritte in toto usufruendo delle caratteristiche avanzate che questa piattaforma offre.

Non mi scandalizza tanto la riscrittura di librerie per un'altra piattaforma perchè se così non fosse saremmo ancora fermi a lavorare in C/C++ con i pro (pochi) ed i contro (tanti) che questo vuol dire.

Ci sono buoni motivi per cui cose simili sono da evitare, ma mi limiterò a farti notare che in realtà LINQ non fa altro che "integrare" a colpi di zucchero sintattico buona parte di SQL in C# e VB .Net facendo finta che siano un unico linguaggio.
Ti lega alla piattaforma in cambio di una maggior velocità di codifica di applicazioni "una botta e via".

Onestamente non ti ho mai letto qui sul forum quindi non so bene quale piattaforma sia per te il "bene" visto che .NET è sicuramente il "male". Ad occhio azzarderei un fanatico dell'open source alla FSF-way.

So bene cosa ci sta dietro le quinte e cosa LINQ fa per me e forse proprio perchè lo so cosa fa posso dire di preferire la possibilità di scrivere una chiamata del genere al dover creare una routine che
1) esegua l'accesso al database, dopo aver validato i parametri da passare alla query e concatenato ad uopo le stringhe
2) esegua qualche elaborazione in memoria
3) crei il file xml

certo, lo posso scrivere anche così, ma cosa ci guadagno? la possibilità di migrare questo codice? ma forse questo non è mai stato un requisito e quindi mi trovo un codice portabilissimo da 40/50 linee di codice (dipende da quanto vuoi sporcare il tuo portabilissimo codice). Se la portabilità non è un requisito, quel zuccherino sintattico mi sta più che bene perchè aumenta la mia produttività e la qualità del mio codice visto che assumo che il codice terzo che utilizzo (microsoft e non) sia stato testato.

Non è questione di "utilizzabilità" ma di vantaggi a medio e lungo termine.
Se "possiedi il software" (nel senso che è tuo o che ne hai la responsabilità) è meglio evitare di legarsi mani e piedi ad un "fornitore di tool" con priorità e precedenti come quelli di Microsoft.

Mettiamo che stai parlando con il mio capo, titolare di un'azienda con qualcosa come 500 siti web di varia grandezza nel mercato del marketing online dell'educazione (dalle high schools ai corsi di formazioni ed MBA passando per università).
Da un lato hai un framework che ti offre tantissima roba già pronta, una piattaforma web stabile ed in continua evoluzione, features sempre all'avanguardia che semplificano il lavoro di ogni giorno (per dirne una, abbiamo spostato un servizio remoto da una macchina remota alla stessa macchina e nel frattempo siamo passati da comunicazione SOAP a Named Pipes: 2 click on WCF), dall'altro hai la possibilità di avere il codice tuo e sapere che non verrà cambiato da qui all'estinzione della Città del Vaticano (perchè Microsoft ad ogni nuova release di .NET dà un 10 anni minimo di supporto, poca roba vero?).

Cosa scegliamo? una bella CGI scritta in C++?

Ripeto, non so con chi sto parlando, magari sei il CEO di Facebook o di chissà quale altro famoso sito, ma ad occhio mi sembra una di quelle discussioni che facevamo stesi a prendere il sole nel giardino dell'università dove i puristi del software libero e compilabile ovunque provavano a convincere quelli che con il software già ci portavano il pane a casa o comunque avevano una visione un po' più profonda della Lista a Puntatori fatta il giorno prima in laboratorio.

Ma sono felice di essere smentito.

[LMCH]

Originariamente inviato da Kralizek

Premesso che i porting di cui parlo sono di librerie OS disponibili per Java (Hibernate e Lucene, per spararne due) e che a poco a poco vengono portate su .NET o riscritte in toto usufruendo delle caratteristiche avanzate che questa piattaforma offre.

Niente neolingua microsoftiana, per favore.
Una riscrittura è decisamente più radicale di un porting (in cui dove possibile si cercano di evitare le riscritture complete).
Ed in questo caso stai parlando pure di un cambio del linguaggio di codifica dei sorgenti.

Originariamente inviato da Kralizek

Non mi scandalizza tanto la riscrittura di librerie per un'altra piattaforma perchè se così non fosse saremmo ancora fermi a lavorare in C/C++ con i pro (pochi) ed i contro (tanti) che questo vuol dire.

"Saremmo ancora fermi a lavorare in C/C++" ?
Ci sono moltissime librerie scritte in C/C++ ed utilizzabili da altri linguaggi e pure dal runtime .Net senza essere costretti a riscrivere il tutto in C#.
Persino .Net si appoggia su un fottio di librerie scritte in C/C++, pensa un po.

Originariamente inviato da Kralizek

Onestamente non ti ho mai letto qui sul forum quindi non so bene quale piattaforma sia per te il "bene" visto che .NET è sicuramente il "male". Ad occhio azzarderei un fanatico dell'open source alla FSF-way.

Sopravvaluti .Net se pensi questo.
Dal mio punto di vista .Net non è "il male", ma più semplicemente sotto certi aspetti è nato male in origine e poi si sta evolvendo come è successo con il "vecchio" VB (tanto zucchero sintattico che con il tempo diventerà sempre più difficile da gestire).
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".

Certo, se ti limiti a web application non ti accorgerai mai di simili limitazioni, ma ci sono e creano parecchi grattacapi quando ti devi interfacciare in modo non banale con codice unmanaged (ed in alcuni casi crea problemi anche quando la cosa in teoria sarebbe banale).

Originariamente inviato da Kralizek

So bene cosa ci sta dietro le quinte e cosa LINQ fa per me e forse proprio perchè lo so cosa fa posso dire di preferire la possibilità di scrivere una chiamata del genere al dover creare una routine che
1) esegua l'accesso al database, dopo aver validato i parametri da passare alla query e concatenato ad uopo le stringhe
2) esegua qualche elaborazione in memoria
3) crei il file xml

certo, lo posso scrivere anche così, ma cosa ci guadagno? la possibilità di migrare questo codice? ma forse questo non è mai stato un requisito e quindi mi trovo un codice portabilissimo da 40/50 linee di codice (dipende da quanto vuoi sporcare il tuo portabilissimo codice). Se la portabilità non è un requisito, quel zuccherino sintattico mi sta più che bene perchè aumenta la mia produttività e la qualità del mio codice visto che assumo che il codice terzo che utilizzo (microsoft e non) sia stato testato.

Ed è esattamente quello che avevo scritto:
Ti lega alla piattaforma in cambio di una maggior velocità di codifica di applicazioni "una botta e via".

Originariamente inviato da Kralizek

Mettiamo che stai parlando con il mio capo, titolare di un'azienda con qualcosa come 500 siti web di varia grandezza nel mercato del marketing online dell'educazione (dalle high schools ai corsi di formazioni ed MBA passando per università).
Da un lato hai un framework che ti offre tantissima roba già pronta, una piattaforma web stabile ed in continua evoluzione, features sempre all'avanguardia che semplificano il lavoro di ogni giorno (per dirne una, abbiamo spostato un servizio remoto da una macchina remota alla stessa macchina e nel frattempo siamo passati da comunicazione SOAP a Named Pipes: 2 click on WCF), dall'altro hai la possibilità di avere il codice tuo e sapere che non verrà cambiato da qui all'estinzione della Città del Vaticano (perchè Microsoft ad ogni nuova release di .NET dà un 10 anni minimo di supporto, poca roba vero?).

Cosa scegliamo? una bella CGI scritta in C++?

Ripeto, non so con chi sto parlando, magari sei il CEO di Facebook o di chissà quale altro famoso sito, ma ad occhio mi sembra una di quelle discussioni che facevamo stesi a prendere il sole nel giardino dell'università dove i puristi del software libero e compilabile ovunque provavano a convincere quelli che con il software già ci portavano il pane a casa o comunque avevano una visione un po' più profonda della Lista a Puntatori fatta il giorno prima in laboratorio.

Ma sono felice di essere smentito.

Visto che ne hai parlato per primo, quelli di Facebook usano pure PHP "compilato" in C con un tool di conversione automatica, fai un po te.

Più seriamente, io sviluppo applicazioni in ambito industriale, su Windows, Windows CE, Linux, ed anche firmware "senza sistema operativo" scritto in C ed assembly, attualmente dove possibile sui frontend utilizzo C++ e Qt, ma ho ancora parecchia roba legacy "in supporto prolungato" (inclusi frontend e tool vari scritti in VB6).
Un settore molto diverso dal tuo sotto parecchi aspetti ma dove puoi star certo che se si usa un certo software o un certo linguaggio non è certo per motivazioni ideologiche.

[!fazz]

Originariamente inviato da LMCH

Niente neolingua microsoftiana, per favore.
Una riscrittura è decisamente più radicale di un porting (in cui dove possibile si cercano di evitare le riscritture complete).
Ed in questo caso stai parlando pure di un cambio del linguaggio di codifica dei sorgenti.



"Saremmo ancora fermi a lavorare in C/C++" ?
Ci sono moltissime librerie scritte in C/C++ ed utilizzabili da altri linguaggi e pure dal runtime .Net senza essere costretti a riscrivere il tutto in C#.
Persino .Net si appoggia su un fottio di librerie scritte in C/C++, pensa un po.



Sopravvaluti .Net se pensi questo.
Dal mio punto di vista .Net non è "il male", ma più semplicemente sotto certi aspetti è nato male in origine e poi si sta evolvendo come è successo con il "vecchio" VB (tanto zucchero sintattico che con il tempo diventerà sempre più difficile da gestire).
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".

Certo, se ti limiti a web application non ti accorgerai mai di simili limitazioni, ma ci sono e creano parecchi grattacapi quando ti devi interfacciare in modo non banale con codice unmanaged (ed in alcuni casi crea problemi anche quando la cosa in teoria sarebbe banale).



Ed è esattamente quello che avevo scritto:
Ti lega alla piattaforma in cambio di una maggior velocità di codifica di applicazioni "una botta e via".



Visto che ne hai parlato per primo, quelli di Facebook usano pure PHP "compilato" in C con un tool di conversione automatica, fai un po te.

Più seriamente, io sviluppo applicazioni in ambito industriale, su Windows, Windows CE, Linux, ed anche firmware "senza sistema operativo" scritto in C ed assembly, attualmente dove possibile sui frontend utilizzo C++ e Qt, ma ho ancora parecchia roba legacy "in supporto prolungato" (inclusi frontend e tool vari scritti in VB6).
Un settore molto diverso dal tuo sotto parecchi aspetti ma dove puoi star certo che se si usa un certo software o un certo linguaggio non è certo per motivazioni ideologiche.

questioni di preferenze
io personalmente piuttosto che imbarcamenarmi con qt e c++ uso tranquillamente .net per i backend e il c++ lo relego al firmware

[LMCH]

Originariamente inviato da !fazz

questioni di preferenze
io personalmente piuttosto che imbarcamenarmi con qt e c++ uso tranquillamente .net per i backend e il c++ lo relego al firmware

Dipende da che target hai in termini di clientela e tipologie di pacchetti software e soluzioni che proponi, non puoi "preferire" .Net se non può girare sull'hardware che ti permette di essere più competitivo sui grandi numeri, tanto per fare un esempio.

[cdimauro]

Dipende, appunto, dai requisiti che hai, come diceva giustamente Kralizek. Se non ci sono impedimenti, e per un progetto puoi utilizzare strumenti più produttivi, perché non usarli? Solo perché sono diffusi su Windows? Non ha alcun senso.

Riguardo allo zucchero sintattico, poi, mi sembra una scusa oltre che un'argomentazione surreale. Qualunque linguaggio offre costrutti sintattici per semplificare la vita degli sviluppatori. E' la differenza che passa anche fra linguaggi di più basso livello e quelli di livello più alto.

Te la sentiresti di sviluppare un'applicazione web in brainfuck? E' disponibile per qualunque piattaforma, dunque perché non adottarlo?

Tra l'altro la teoria della computazione ha dimostrato che per essere Turing-completi basta una macchina in grado di eseguire tre sole istruzioni (incremento di un registro, azzeramento di un registro, salto se due registri sono diversi; ad esempio, ma ce possono essere altre "architetture" dotate sempre di 3 istruzioni, ma diverse).

Se oggi uso (Iron)Python piuttosto che l'assembly x86, penso che avrò i miei buoni motivi. E se a lavoro mi diverto con le query di LINQ quando manipolo collezioni di dati, avrò anch'io i miei buoni motivi.

Forse non mi piace scrivere PAPIRI per fare cose che si risolvono con un paio di righe LINQ, per pattern abbastanza ricorrenti nella programmazione di tutti giorni.

Con ciò NON voglio dire che i linguaggi dovrebbero implementare qualunque costrutto sintattico; tutt'altro. Ma se la pratica dimostra la ricorrenza di certe situazioni, offrire uno strumento per risolvere velocemente il problema può essere una gran comodità, che comporta un miglioramento della produttività e, quindi, del time-to-market.

D'altra parte il riuso del codice è un fondamento della programmazione. Si fa di tutto per astrarre e riutilizzarlo il più possibile. Strumenti come LINQ nascono apposta allo scopo: non reinventare ogni volta la ruota, ma semplificare notevolmente la scrittura di pattern comuni.

In tutto ciò, pur con tutta la fantasia e la buona volontà, non riesco a capire come si possa parlare di maggior difficoltà di gestione del codice, quando il risultato ottenuto è l'esatto contrario: fra manutenere un paio di righe di codice, peraltro estremamente leggibili, col papiro equivalente, non c'è proprio paragone; ma a favore della prima soluzione!

Questo "lega" a una determinata piattaforma? A parte che l'esistenza di progetti come Mono dimostra il contrario, mi viene in mente il ritornello di una celebre canzone di Celentano e di sua moglie: "siamo la coppia più bella del mondo, e ci dispiace per gli altri..."

Come dicevo, se non vincoli di piattaforma e devo risolvere un problema prima possibile, non mi faccio alcuno scrupolo a utilizzare strumenti come questi. Sarei, al contrario, stupido a non farlo.

Ovviamente si tratta di scelte che DEVONO tener conto della prospettiva futura in termini di supporto, manutenibilità ed estensione del codice. Cose che può garantire Microsoft per un lungo arco di tempo, come dimostra la storia.

Non mi è nemmeno chiara la questione del codice unmanaged, dei 64 bit, e della memorizzazione dei puntatori. Anche perché fin dall'inizio .NET mette a disposizione un tipo intero (intptr, se non ricordo male il nome) che nasce proprio allo scopo.

E anche la gestione del codice unmanaged non mi sembra roba dell'altro mondo (sebbene NON ne abbia mai fatto uso: mai sentita questa necessità, anche grazie alle reference e ai parametri di input/output).

Pertanto condivido, e chiudo, anche il messaggio di !fazz.

[Kralizek]

Originariamente inviato da LMCH

Più seriamente, io sviluppo applicazioni in ambito industriale, su Windows, Windows CE, Linux, ed anche firmware "senza sistema operativo" scritto in C ed assembly, attualmente dove possibile sui frontend utilizzo C++ e Qt, ma ho ancora parecchia roba legacy "in supporto prolungato" (inclusi frontend e tool vari scritti in VB6).
Un settore molto diverso dal tuo sotto parecchi aspetti ma dove puoi star certo che se si usa un certo software o un certo linguaggio non è certo per motivazioni ideologiche.

vabbè in quest ambito, se mi permetti, è .net a non fare proprio al caso tuo

[LMCH]

Originariamente inviato da cdimauro

Non mi è nemmeno chiara la questione del codice unmanaged, dei 64 bit, e della memorizzazione dei puntatori. Anche perché fin dall'inizio .NET mette a disposizione un tipo intero (intptr, se non ricordo male il nome) che nasce proprio allo scopo.

Il nome dice tutto: IntPtr ... ed invece è una struct (per serie: cominciamo beeene!)
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.

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"

Cioè avevano progettato una virtual machine ed un runtime "da zero" e non avevano minimamente considerato che prima o poi capita di dover "uscir fuori la dove ci sono puntatori ed handle" e che doveva essere fatto in modo portabile ed indipendente dalla piattaforma visto che .Net doveva essere multipiattaforma (all'interno delle piattaforme di Microsoft).

Dopo hanno cercato di metterci una pezza proprio con IntPtr come "tipo standard per rappresentare puntatori ed handle" e non contenti hanno pure aggiunto UIntPtr ... sconsigliandone l'uso (per la serie: complichiamo anche la pezza).
Non sto scherzando, nella documentazione si trova scritto:
"Il tipo IntPtr è conforme a CLS, mentre il tipo UIntPtr non lo è. Solamente il tipo IntPtr viene utilizzato in Common Language Runtime. Il tipo UIntPtr viene fornito principalmente allo scopo di mantenere la simmetria di architettura con il tipo IntPtr."

In ogni caso IntPtr serve solo come promemoria di "questo in realtà è un handle o un puntatore", ma non hai nessuna vera protezione o check aggiuntivo.

Questa non-gestione è anche uno dei motivi per cui era usciti parecchio in ritardo con la versione a 64bit di .Net (tante bug legate alla dimensione dei puntatori).

[cdimauro]

Scusami, ma io leggo questo:

.NET Framework 1.1

Platforms: Windows 98, Windows NT 4.0, Windows Millennium Edition, Windows 2000, Windows XP Home Edition, Windows XP Professional, Windows Server 2003 family, .NET Compact Framework

Ricordavo bene, dunque: questo tipo (definito come struttura, ma è indifferente: l'importante è che sia utile allo scopo) esiste da una vita. Certo, non dalla prima versione, ma già dalla seconda.

Se consideri tutte le versioni che ci sono state e quanto tempo è passato, non mi sembra una tragedia il fatto che sia stato messo a disposizione dalla 1.1, cioè circa UN anno dopo la 1.0.

UIntPtr, poi, non è una pezza. In .NET tutti i tipi interi, di qualunque dimensione, sono disponibili signed o unsigned. Per cui è stato aggiunto anche questo, per "simmetria", come hanno sottolineato.

Ma per lo scopo per cui è nato IntPtr, è sufficiente far uso soltanto di questo tipo. Anche qui, non mi sembra il caso di stracciarsi le vesti. Devi usare codice unmanaged? Usa IntPtr per infilarci i puntatori.

Poi qual è il problema con la mancanza di protezione? Cosa ti saresti aspettato?

[LMCH]

Originariamente inviato da cdimauro

Poi qual è il problema con la mancanza di protezione? Cosa ti saresti aspettato?

Hai presente i vari patch (inclusi quelli di questa settimana) per .Net nelle sue varie versioni relativi a problemi di sicurezza ?
In buona parte sono dovuti a quella enorme svista iniziale che ha portato poi all'introduzione di IntPtr tra i vari rimedi "post-disastro".
L'accesso a puntatori ed handle poteva essere reso più sicuro (e pure più semplice) ma erano troppo presi dal realizzare la loro "risposta a Java" (perchè .Net quello è in ultima analisi) e come è successo con Java hanno sottovalutato le esigenze (e le problematiche) di chi ha necessità di interfacciarsi con codice unmanaged/nativo/legacy (in primo luogo chi dentro Microsoft deve interfacciarsi con il codice di più basso livello e mixare dati managed con dati unmanaged).

Tieni comunque presente che per me non è un problema visto che nel mio settore mi da un notevole vantaggio sulla concorrenza.

[cdimauro]

Non m'è ancora chiaro cosa e come avrebbero dovuto fare.

Comunque .NET è senza dubbio una risposta a Java (Microsoft fu costretta a eliminare la sua JVM e le estensioni a essa apportate), ma fortunatamente è diverso.

[LMCH]

Originariamente inviato da cdimauro

Non m'è ancora chiaro cosa e come avrebbero dovuto fare.

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.

[nico159]

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.

Scusa ma non esiste
http://msdn.microsoft.com/it-it/libr...afehandle.aspx
http://blogs.msdn.com/b/bclteam/arch...15/396335.aspx

?

[LMCH]

Originariamente inviato da nico159

Scusa ma non esiste
http://msdn.microsoft.com/it-it/libr...afehandle.aspx
http://blogs.msdn.com/b/bclteam/arch...15/396335.aspx

Appunto.

Notare come nella documentazione stessa di Safehandle sia scritto esplicitamento che serve per porre rimedio a certi "problemini" di IntPtr.

Notare anche come serve al programmatore per rendere "più sicuro" il proprio codice, ma non rende il runtime più sicuro e robusto come sarebbe stato se la cosa fosse gestita come tipi nativi del runtime (quindi da codice managed puoi ancora fare un sacco di porcate con handle e puntatori se è quello l'obiettivo come succede con codice malevole).

Notare infine come Safehandle è presente solo a partire da .Net 2.0 quando invece il problema doveva essere decisamente ovvio già durante la progettazione iniziale di .Net (con tutto quel codice unmanaged su cui si appoggiavano era decisamente difficile non accorgersene, solo che come al solito hanno preferito prendere qualche scorciatoia).

[cdimauro]

OK, ma la 2.0 ha già 6 anni sulle spalle, ed è nata per rimpiazzare completamente le precedenti 1.x (o sviluppi per 1.x oppure 2.0+), rimediando anche ad altri errori di progettazione.

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

Mentre quando usi IntPtr il codice è necessariamente "unsafe" / unmanaged. Fermo restando che questo tipo avrebbero potuto implementarlo in modo migliore, come dicevi prima.

Le differenze e, soprattutto, la "divisione" del codice nell'uso dei due tipi sono nette.