Programmazione C o Visual Basic? [Archivio]

tomminno

08-10-2011, 10:12

Volevi dire 3 anni fa, perché 13 anni fa mi sembrava ben in vita (era appena uscita la versione 6.0) :D

E' stato l'ultimo aggiornamento del linguaggio, non ha più subito evoluzioni.
:cool:

Cmq c'è anche Visual Basic.Net che io conosco zero ma sento dire che è un linguaggio di pari livello sotto DotNet e che non è da buttare via.

Non ha senso partire da 0 con un linguaggio che mischia un po' di sintassi del vecchio e del nuovo, con una chiarezza dei nuoi costrutti pari a 0.
Tanto vale partire direttamente con un linguaggio moderno.

Anzi secondo il famoso guru Battilana con VB fai anche cose che con C# sono poco agevoli da fare.

Dubito fortemente. Qualche riferimento diretto alla fonte?

Cmq per la programmazione Windows consiglio pure io C# in primis e C++ in seconda.
Anche se non trascurerei un certo Java :D e se non sono richieste prestazioni estreme (cmq raggiungibili) anche Python

Secondo me oggi come oggi si fa molto prima a fare una interfaccia grafica con Qt che non con Java (paradossalmente pure per Android).
Java lo lascerei nel suo regno Enterprise.

cdimauro

08-10-2011, 10:25

Suvvia: VB non è certo rimasto lo stesso, a meno che non ci si fermi alle incarnazioni pre-.NET. ;)

Comunque ricordo che VB.NET offriva qualche costrutto sintattico non disponibile in C#, che per le prossime versioni di quest'ultimo pensavano di integrare.

Era qualcosa relativa alle eccezioni, ma è passato tempo e non rammento i dettagli.
Perchè PURTROPPO? :D (Io ho sentito dire che quel linguaggio è molto complicato)
Perché è orribile. :D
Comunque tornando alla programmazione C... in effetti sul web avevo già letto molti commenti di utenti che consigliavano questo linguaggio (addirittura uno in particolare così parlava del C: "è un linguaggio di programmazione che ti fa le ossa, ti insegna cosa è la programmazione e in virtù del quale, poi, puoi apprendere più facilmente gli altri linguaggi")
E' gente che non ha capito niente della programmazione.

"Non ragioniam di lor, ma guarda e passa".
Premetto che io sono un fan sfegatato di Apple e i suoi prodotti (adoro il mio mac Pro :) ) ma so pure che Objective-C gira solo su Mac, quindi avrei delle competenze limitate a quel campo.
In realtà c'è un compilatore GNU che dovrebbe girare anche su macchine diverse.
Python pure, ho sentito dire che è un linguaggio emergente...
Beh, non è che sia tanto giovane: è pure un po' più vecchio di Java. :p
Non so proprio da dove cominciare... :D
Dalla mia firma.:cool:

-sparkster-

08-10-2011, 11:24

E' gente che non ha capito niente della programmazione.

Scusa quindi secondo te, se non è C che ti fa capire "cos'è la programmazione", qual è il linguaggio ad hoc? Python? (questa sarebbe la "tua firma"? :D ) Cos'ha Python che non hanno C, C Sharp e C++? Quindi iniziare da C per poi passare a C# e C++ me lo sconsigli?

"Non ragioniam di lor, ma guarda e passa".

Bella la citazione alla Divina Commedia. :D

pabloski

08-10-2011, 11:37

Scusa quindi secondo te, se non è C che ti fa capire "cos'è la programmazione", qual è il linguaggio ad hoc? Python? (questa sarebbe la "tua firma"? :D ) Cos'ha Python che non hanno C, C Sharp e C++? Quindi iniziare da C per poi passare a C# e C++ me lo sconsigli?

dipende da quale concetto di programmazione si vuole padroneggiare

il punto è che da un lato ci sono i problemi e le loro soluzioni algoritmiche, per cui un linguaggio come python è decisamente e assolutamente preferibile

dall'altro c'è la macchina con tutti i suoi misteri....se t'interessa quest'ultimo aspetto della programmazione devi considerare il C e magari l'assembly....python ad esempio ti astrae millemila cose che la macchina fa dietro le quinte

la fregatura è che sono due aspetti che bisogna conoscere, non si può essere informatici per metà

FabryHw

08-10-2011, 12:34

E' stato l'ultimo aggiornamento del linguaggio, non ha più subito evoluzioni.
:cool:

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

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.

Non ha senso partire da 0 con un linguaggio che mischia un po' di sintassi del vecchio e del nuovo, con una chiarezza dei nuoi costrutti pari a 0.
Tanto vale partire direttamente con un linguaggio moderno.

Ripeto conosco pochissimo Vb.Net (mentre conosco VB6) ma dal poco letto in giro, si diceva che a parte una sintassi VB like i 2 condividono ben poco e VB.Net è un linguaggio moderno pienamente orientato agli oggetti.

E cmq cosa intendi con mischiare il vecchio?
Il fatto che supporta (forse ripeto lo conosco poco) il paradigma procedurale e forse lo può mischiare al paradigma ad oggetti?

Ma allora anche C++ e Python sono vecchi in quel senso.

Dubito fortemente. Qualche riferimento diretto alla fonte?

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#.

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.
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.

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#).

LMCH

08-10-2011, 22:34

Per quel che mi riguarda Visual Basic non è consigliabile per chi inizia ora a programmare e questo include quella pseudotruffa che è Visual Basic .Net.

Mi spiego meglio, l'unico motivo per cui esiste Visual Basic .Net è che c'era una mole ENORME di codice legacy scritto in VB4/VB5/VB6.
Fino a VB6, un programma scritto in VB n lo potevi ricompilare tale e quale per VB n+1 e funzionava, poi potevi sfruttare le funzionalità aggiuntive e migliorarlo (nel caso fosse utile).

Poi con .Net fu decisa la "morte" di Visual Basic come prodotto separato e la sua integrazione in .Net, solo che Visual Basic "pre .Net" aveva un set di librerie ed oggetti "tutto suo" che sarebbe stato difficile da portare su .Net, e questo portò a chiamare Visual Basic .Net un linguaggio che in pratica è "C# con una sintassi simile a VB".

In altre parole: prendi un programma scritto per VB n e DOVRAI FARE MODIFICHE FUNZIONALMENTE EQUIVALENTI AD UNA RISCRITTURA IN C# per renderlo compilabile in VB .Net (che poi funzioni correttamente è tutto un altro paio di maniche, per quello serviranno altri test e modifiche).

Se non ci credete, considerate che esiste ancora parecchio software scritto in VB6 che non è stato portato a VB .Net e che semmai è stato riscritto o verrà riscritto in altri linguaggi e con altri runtime.

Per quel che mi riguarda, VB (con o senza .Net) e C# sono da considerare come COBOL e Fortran: linguaggi di programmazione da usare solo se qualcuno ti paga TANTO (ma TANTO, eh) e non interessa minimamente cosa succederà dopo.

Se si sviluppa software e si vogliono evitare inutili riscritture e non si vuole restare ingabbiati su un unica piattaforma conviene scegliere altri linguaggi, altre librerie ed altri tool.

Premesso questo, neanche C è consigliabile "per iniziare" perchè sotto vari aspetti "è un linguaggio che non perdona".
Sotto tale aspetto Python e Java sono più amichevoli per i principianti.

Io personalmente quando posso scegliere linguaggio e tool di sviluppo utilizzo C++ e Qt, le librerie "standard" di C++ lasciano molto a desiderare se si deve sviluppare un applicazione con interfaccia utente "ricca", ma proprio per questo lo abbino a Qt perché fornisce proprio tutto quello che manca (senza contare la maggior portabilità ecc. ecc.).

-sparkster-

09-10-2011, 09:44

Premesso questo, neanche C è consigliabile "per iniziare" perchè sotto vari aspetti "è un linguaggio che non perdona".
Sotto tale aspetto Python e Java sono più amichevoli per i principianti.

Scusa che intendi con "linguaggio che non perdona"? Forse che è un linguaggio intollerante anche al minimo margine di errore nella scrittura del codice per un programma? (Si potrebbe paragonare a GNU/Linux, che è scritto proprio in C)

LMCH

09-10-2011, 16:58

Scusa che intendi con "linguaggio che non perdona"? Forse che è un linguaggio intollerante anche al minimo margine di errore nella scrittura del codice per un programma? (Si potrebbe paragonare a GNU/Linux, che è scritto proprio in C)

Come linguaggio, C è di tipo procedurale e non orientato alla programmazione ad oggetti.
Questo significa che non appena cominci a fare cose di una certa complessità, per cose per cui con C++ o altri linguaggi risolvi tutto con oggetti, ereditarietà e metodi virtuali, nel caso del C ti ritrovi ad usare struct con puntatori ecc. ecc.

Il problema (oltre ad una maggior complessità del codice da scrivere con le proprie mani) è che C è stato "pensato" per essere efficiente (quasi) quanto il codice macchina (in un periodo in cui i compilatori non ottimizzavano il codice come ora), quindi fa uso di puntatori su cui si possono eseguire operazioni aritmetiche (quindi basta una svista e ti ritrovi con puntatori randagi che scrivono in ram dove non dovrebbero).

Oltre a questo le librerie "standard" del C sono ancora più ridotte all'osso di quelle di C++ (quindi o ti scrivi un sacco di codice da te o devi cominciare
da subito ad usare librerie esterne di vario tipo per roba che ad esempio in C++ viene fornita "di serie").

Per questo l'ho definito un "linguaggio che non perdona", ti permette di fare roba che con altri linguaggi non è possibile (ma poi sono cavoli tuoi se sbagli qualcosa) e spesso non hai alternative all'uso dell'aritmetica dei puntatori (mentre invece ad esempio il C++ tra le librerie "standard" ha le STL che forniscono oggetti per gestire strutture dati complesse riducendo al minimo l'uso di aritmentica dei puntatori e rendendola più "sicura" dove possibile).

Se ti servono prestazioni elevate, possibilità di interfacciarti facilmente con roba a basso livello, una buona portabilità ed hai già sufficiente esperienza come programmatore, il linguaggio C può essere una buona scelta, ma non è esattamente il linguaggio migliore con cui iniziare ad imparare a programmare (si rischia di perdere più tempo ad imparare il linguaggio che ad imparare le basi della programmazione, inoltre per imparare la programmazione ad oggetti dovrai cambiare linguaggio).

cdimauro

09-10-2011, 21:51

Scusa quindi secondo te, se non è C che ti fa capire "cos'è la programmazione", qual è il linguaggio ad hoc? Python? (questa sarebbe la "tua firma"? :D )
Al momento ritengo che sia Python, perché ti permette di concentrarti sulla risoluzione del problema piuttosto che sui dettagli di più basso livello.
Cos'ha Python che non hanno C, C Sharp e C++?
La semplicità nell'affrontare e risolvere i problemi, generalmente.
Quindi iniziare da C per poi passare a C# e C++ me lo sconsigli?
Assolutamente. Vade retro, Satana. :D
Bella la citazione alla Divina Commedia. :D
Te ne faccio un'altra: "E non ci indurre in tentazione, ma liberaci dal male".

Cioè da C & derivati. :O
dipende da quale concetto di programmazione si vuole padroneggiare

il punto è che da un lato ci sono i problemi e le loro soluzioni algoritmiche, per cui un linguaggio come python è decisamente e assolutamente preferibile

dall'altro c'è la macchina con tutti i suoi misteri....se t'interessa quest'ultimo aspetto della programmazione devi considerare il C e magari l'assembly....python ad esempio ti astrae millemila cose che la macchina fa dietro le quinte

la fregatura è che sono due aspetti che bisogna conoscere, non si può essere informatici per metà
:mbe: Dammi la definizione di "informatico a metà" e, se ce l'hai, anche di "informatico intero". :read:

Kralizek

10-10-2011, 08:36

Per quel che mi riguarda, VB (con o senza .Net) e C# sono da considerare come COBOL e Fortran: linguaggi di programmazione da usare solo se qualcuno ti paga TANTO (ma TANTO, eh) e non interessa minimamente cosa succederà dopo.

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.

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 :doh: )

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.

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 ;)

banryu79

10-10-2011, 10:43

Ciao -sparkster-,
ti linko un articolo che fa un discorso molto generale su quale genere di linguaggio di programmazione sia utile scegliere per chi comincia da zero (e quest'ultima parte della frase è l'aspetto rilevante dell'intera faccenda):
http://www.appuntidigitali.it/2506/quale-linguaggio-per-imparare-a-programmare/

Se poi da profano sei cursioso di sapere che genere di caratteristiche differenzi un linguaggio di programmazione da un'altro, consiglio la discussione in evidenza creata appositamente:
http://www.hwupgrade.it/forum/showthread.php?t=1979444

!fazz

10-10-2011, 11:05

Scusa che intendi con "linguaggio che non perdona"? Forse che è un linguaggio intollerante anche al minimo margine di errore nella scrittura del codice per un programma? (Si potrebbe paragonare a GNU/Linux, che è scritto proprio in C)

no è proprio l'opposto è un linguaggio talmente tollerante che ti permette anche di far cose senza il minimo senso logico (tipo overflow su array ecc ecc) e giù un sequela di problematiche a non finire :D :D :D :D :D

se poi consideri che C è un linguaggio procedurale...
se posso dire la mia devi vedere l'ambito applicativo

se ti vuoi interessarti all'elettronica digitale, sistemi a microcontrollore ecc ecc inizia a studiare C e C++ se vuoi sviluppare applicazioni desktop piuttosto che visual basic puro che è morto anni fà scegli un ambiente .net se ti interessa sviluppare per windows.
che poi impari c# o vb.net è assolutamente identico, io ad esempio preferisco c# perchè ha una sintassi abbastanza simile al C++ quindi abbastanza stringata ma sono scelte personali dello sviluppatore che non impattano sulla qualità del codice in uscita

pabloski

10-10-2011, 14:53

:mbe: Dammi la definizione di "informatico a metà" e, se ce l'hai, anche di "informatico intero". :read:

non penso che chi conosce la logica algoritmica e magari sa pure realizzare programmi in 4-5 linguaggi diversi, ma non sa cosa avviene dietro le quinte, possa essere definito un informatico

il tizio dice "sono bravissimo a fare programmi vb, creo gestionali a raffica, ma non chiedermi com'è rappresentata in memoria una stringa, perchè non è di mia competenza"....ecco, questo è un informatico a metà

cdimauro

10-10-2011, 17:25

E' una tua definizione che ovviamente non condivido.

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.

pabloski

10-10-2011, 18:11

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

10-10-2011, 18:47

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

10-10-2011, 18:57

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

10-10-2011, 19:14

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

10-10-2011, 20:15

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++.
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? :D

Esperto <> laureato <> conoscente architettura degli elaboratori.

LMCH

11-10-2011, 17:42

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.

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 :doh: )

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

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".

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

11-10-2011, 19:53

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 ? :eek:

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

12-10-2011, 03:40

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. :eek:

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. :D

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". :eek:

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).

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". :read:

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

12-10-2011, 15:00

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. :eek:

"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. :D

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". :eek:

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". :read:

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

12-10-2011, 18:38

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

12-10-2011, 19:31

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..." :D

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

12-10-2011, 19:43

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

12-10-2011, 23:40

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. :stordita:

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" :rolleyes:

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). :rolleyes:

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." :eek:

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. :doh:

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

13-10-2011, 06:13

Scusami, ma io leggo questo (http://msdn.microsoft.com/en-us/library/system.intptr(v=vs.71).aspx):
.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

13-10-2011, 17:10

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. :D

cdimauro

13-10-2011, 20:56

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

14-10-2011, 16:48

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

14-10-2011, 23:12

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/library/system.runtime.interopservices.safehandle.aspx
http://blogs.msdn.com/b/bclteam/archive/2005/03/15/396335.aspx

?

LMCH

15-10-2011, 01:21

Scusa ma non esiste
http://msdn.microsoft.com/it-it/library/system.runtime.interopservices.safehandle.aspx
http://blogs.msdn.com/b/bclteam/archive/2005/03/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

15-10-2011, 06:30

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.

ingframin

15-10-2011, 07:26

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? :doh:
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/ :D

tomminno

15-10-2011, 10:12

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. :stordita:

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" :rolleyes:

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-

15-10-2011, 18:48

cdimauro

15-10-2011, 19:43

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 (http://it.wikipedia.org/wiki/Algoritmo).
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 (http://it.wikipedia.org/wiki/Fisica_teorica).

LMCH

15-10-2011, 21:29

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

15-10-2011, 22:05

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/library/aa711900%28v=vs.71%29.aspx

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

16-10-2011, 09:24

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/library/aa711900%28v=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

16-10-2011, 10:10

Ciao e grazie per la considerazione!! :D

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/reti-logiche-calcolatore-luccio-fabrizio/libro/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/architettura-calcolatori-approccio-strutturale-cd/libro/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

16-10-2011, 10:29

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

16-10-2011, 11:17

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

16-10-2011, 16:49

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: :read:
Ad esempio infatti leggi sul link che avevo riportato ( http://msdn.microsoft.com/it-it/library/aa711900%28v=vs.71%29.aspx )
trovi le seguenti affermazioni:

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).

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.

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. :read:

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.

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.

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. ;)

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

16-10-2011, 18:20

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 :D

http://msdn.microsoft.com/en-us/library/system.type.isprimitive.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

16-10-2011, 18:50

Io non pontifico, esprimo una mia opinione basata su fatti ben precisi e sopratutto a suo tempo ho letto la documentazione Microsoft: :read:
Ad esempio infatti leggi sul link che avevo riportato ( http://msdn.microsoft.com/it-it/library/aa711900%28v=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. :read:

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

17-10-2011, 01:03

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

http://msdn.microsoft.com/en-us/library/system.type.isprimitive.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/library/system.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. :eek:

LMCH

17-10-2011, 04:22

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.

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:
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:
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. ;)

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:
http://www.readwriteweb.com/hack/110913%20Windows%208%20Platform%20diagram.JPG

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/library/windows/apps/windows.networking.connectivity.networkinformation.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.

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

17-10-2011, 04:32

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.
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 :asd:) 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. :read:

Sul resto concordo con tomminno.