Newsgroup: it.comp.programmare.win32
Titolo: c++ e sviluppo software per windows: quali prospettive?

Ciao,
la mia domanda č semplice:
vorrei sapere se la conoscenza del
linguaggio c++ puň essere considerata
sufficiente per lo sviluppo di applicazioni
per ambienti windows o č consigliabile
e piů comodo imparare il visual basic .net
o un altro linguaggio microsoft.
Vorrei un parere in proposito
da qualche professionista. 

 o un altro linguaggio microsoft.
dipende da ciò che devi realizzare.

"Marco" <ma...@cognome.nome> ha scritto nel messaggio 
news:Ooosh.1315$422....@twister2.libero.it...

In pratica, quali vantaggi potrebbe dare
un linguaggio come visual 
basic.net
rispetto a c++ e viceversa? 

 o un altro linguaggio microsoft.
Il linguaggio C++ e' sicuramente sufficiente, in quanto non c'e' niente 
che si possa fare in un altro linguaggio e non si possa fare in C++, con 
la sola eccezione del linguaggio assembly.
Tuttavia, la *conoscenza* del linguaggio C++ e della sua libreria 
standard certamente non e' sufficiente, in quanto e' necessario 
conoscere anche l'API di Windows o qualche libreria di interfacciamento 
con Windows, in quanto usando solamente il linguaggio e la libreria 
standard si possono creare solamente programmi a riga di comando 
(modalità console).
Questo non contraddice il fatto che possa essere consigliabile e più 
comodo imparare e usare qualche altro linguaggio.
Infatti, il C++ e' probabilmente il linguaggio piu' difficile da 
imparare e da usare.
Non vedo pero' perche' limitarsi ai linguaggi Microsoft. Se si usano 
linguaggi e libreria specifici della Microsoft si ha il vantaggio di 
poter seguire l'ultima moda, ma si hanno i seguenti svantaggi:
* Il software prodotto non e' portabile ad altri sistemi operativi.
* Se la Microsoft decide di non sviluppare piu' quel linguaggio, come e' 
successo recentemente con Visual Basic 6, si e' costretti a rimanere con 
una vecchia implementazione del linguaggio o a cambiare linguaggio.
* Non e' possibile passare a un'altra implementazione del linguaggio.
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 linguaggio.
Il problema della portabilità del codice esiste per tutti i sistemi 
operativi, per tutti i linguaggi e più che in altri per C++, proprio perché 
è un linguaggio di basso livello.
Ho provato a ricompilare OpenExchange su diverse distro Linux/nix ed è 
venuto fuori il finimondo. Esempi di questo genere è pieno ed è normale 
perché C++ è un linguaggio che per esempio non è stato pensato per il cross 
process.
Così quando devi passare un buffer, il puntatore è un informazione troppo 
scarsa. In COM e CORBA hanno sopperito con IDL. Il passo successivo sono 
stati la JVM e il Framework.
E personalmente sono convinto che il problema del versioning sia il più 
grosso problema del software e ce lo porteremo dietro ancora per un bel 
pezzo.
Insomma, concordo con te che C++ sia un linguaggio potente ma:
- alcune volte è come sparare con un cannone su una mosca
- il developer di backup non è così semplice da trovare
- la portabilità è limitata a task piuttosto semplici perché la dipendenza 
dall'OS va ben oltre al mero mapping delle API di sistema
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

 rispetto a c++ e viceversa?
VB e' ritenuto piu' semplice imparare e da utilizzare, sempre che
tu non debba attaccarti direttamente ad una dll, altrimenti e' un
bagno di sangue.
Il C++ e' (generamente) piu' veloce, si collega a tutte le dll con
meno paturnie, e fa molto piu' figo dire "programmo in C++" che dire
"programmo in VB". :-)
C:\>iao Angelo
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 dall'OS va ben oltre al mero mapping delle API di sistema
La portabilita' deve essere pianificata. Esistono decine di esempi
di applicazioni multipiattaforma scritte in C/C++, tutt'altro che
di "basso profilo". OpenOffice, PostgreSQL, FireFox e via dicendo,
ma sono tutte applicazioni o nate per essere portabili (OO e FF)
o riscritte per essere portate (Postgres).


 o riscritte per essere portate (Postgres).
Infatti non dico che non sia possibile o che non vada pianificata. Dico solo 
che molti problemi salteranno fuori a runtime proprio perché 
l'infrastruttura di base è differente e il linguaggio è agnosta di quel 
livello. Questo è un sintomo che non è una strada per nulla semplice. Gli 
errori di compilazione sono la salvezza del developer.


 errori di compilazione sono la salvezza del developer.
Lo so, eccome se lo so... :-)))


 Quello che dici sembra confermare quanto appena affermato
C'č un tool di mono che permette di individuare l'uso di classi che non sono 
supportate.
Fatto questo, non ti resta altro che fare il test a runtime e nulla di piů.
Sulla mia collection che ho pubblicato su codeplex 
www.codeplex.com/rafcollection
 c'č stato solo un metodo che non gli piaceva.
Su 
asp.net
 (chi l'ha provato) mi dice che va tutto liscio come l'olio.
Su Winform le cose possono essere un po' piů complesse principalmente perché 
molti usano interop.
Quindi la valutazione č ovvio sia soggettiva ma i feedback che mi arrivano 
sono molto piů positivo di quanto io inizialmente mi aspettassi.
<megacut>
Comprendo le tue esperienze positive ma la strada di C++ č un vicolo cieco 
perché manca la semantica per poter migliorare qualcosa.
Le altre soluzioni non possono che migliorare, si chiamino esse jvm o 
framework.
ciao


 framework.
Il C/C++ NON e' un vicolo cieco. Sono piu' di 30 anni che di fanno
programmi portabili in C e piu di 20 che si fanno programmi portabili
in C++. Fino a questo momento chi deve ancora dimostrare qualcosa
sono proprio i vari Java e .NET.
In circa 17 anni che esiste, Java e' stato portato su 4 piattaforme
messe in croce (se si escludono i cellulari, che mi verrebbe da
ridere a considerarle "piattaforme").
Su Linux, Java c'e' arrivato quando Sun ha deciso di prendere
in seria considerazione questo S.O. Prima esistevano solo dei
buoni tentativi.
Se e' applicabile quello che e' successo per Java, .NET sara'
utilizzabile fuori dall'ambito Windows, solo quando MS decidera'
di impegnarsi direttamnente, Mono, sempre a mio avviso, sara'
come uno dei "buoni tentativi" di sopra.
.NET al momento esiste solo per Windows e definirla una
piattaforma per fare programmi portabili e' un ossimoro (ripeto,
al momento).
Anche se in un futuro avessero una diffusione esplosiva, ho i
miei seri dubbi che Oracle, DB2 et similia vengano riscritti in
C#,: la penalizzazione di prestazioni che si ha usando una
virtual machine, per molti applicativi e' inaccettabile.
Pertanto io non sarei cosi' tranchant nel definire lo sviluppo
multipiattaforma C/C++ "un vicolo cieco".
C:\>iao Angelo

 virtual machine, per molti applicativi e' inaccettabile.
Non avrebbe senso riscrivere. Ma può aver senso aggiungere codice managed. 
SQL Server ha scelto la strada mixed così come Office 2003 e non l'hanno 
certo fatto solo per fare pubblicità al framework.
In un normale processo nativo, si può hostare il CLR dentro cui far girare 
assembly dotnet controllando in maniera capillare tutti i servizi del CLR 
stesso: come allorare memoria, come creare thread, vietare l'uso di certe 
classi, etc. etc. .... cioè proprio quello che fa SQL Server 2005.


 delle architetture hardware di oggi.
Mi faresti la cortesia di postare riferimenti a ciò?
Perché trovo veramente strano che Stroustrup possa parlare di "rinuncia 
all'uso dei puntatori" nel senso che traspare dal tuo messaggio 
(eliminazione dal linguaggio). Tra l'altro non ne trovo traccia sul suo 
sito.
Se invece intendi dire che i puntatori andrebbero usati il meno 
possibile (solo nelle -piccole- parti di codice a basso livello sulle 
quali costruire astrazioni da usare "normalmente") ed al loro posto 
andrebbero usati una serie di smart-pointer (o qualcosa di equivalente) 
che permettono la gestione automatica della memoria, beh... questo lo 
afferma da *sempre* e sarebbe buona pratica (disattesa nella maggior 
parte dei programmatori C++) del normale programmare in C++.
Ciao.

 programmare in C++.
Per rinuncia non intendevo rinuncia totale, mi spiace per la confusione.
Come dicevo nell'altro messaggio sono convinto che il futuro sia mixed e 
quindi non posso pensare ad una rinuncia totale dei puntatori.
Quello che volevo sottolineare è che adesso è sempre più un'esigenza evitare 
l'uso esplicito delle semantiche legate all'architettura hardware e il 
problema della concorrenza è forse quello che solleva il problema più di 
ogni altro (e che lo rende un problema urgente).
Non vedo quindi perché scandalizzarsi quando si dice che C++ è in un vicolo 
cieco o si parla di framework (o di ambienti equipollenti) come soluzione. 
Ovviamente ri-sottolineo quanto nessuna delle due strade, almeno secondo me, 
non può sostituire l'altra e che il futuro è mixed.
Le estensioni CLI sono "stamina" per C++ e ritengo che tutte le future 
aggiunte/miglioramenti al linguaggio siano indispensabili per farlo 
continuare ad essere il linguaggio con la "L" maiuscola come tutti lo 
conosciamo.
Quanto al link, ho assistito ad un paio di presentzioni di Sutter 
(
http://blogs.ugidotnet.org/raffaele/archive/2005/09/16/26570.aspx
) che 
parlava di questi concetti e dove spiegava come lo stesso Stroustrup ne 
fosse un attivo sostenitore.
Il topic era grosso modo questo ("The Concurrency Landscape", vedi link) e a 
questo link puoi vedere che nelle conference gli speaker sono loro due: 
http://www.gotw.ca/sands2.htm
.
Lo slideset era simile a questo:
http://irbseminars.intel-research.net/HerbSutter.pdf
 in particolare la slide 
40
I concetti di Concur sono sviluppati anche da microsoft research ... alla 
PDC ho visto un'altra presentazione su questo topic:
http://blogs.ugidotnet.org/raffaele/archive/2005/09/14/26341.aspx


 realtime, non poco direi. 
Anche io lavoro soprattutto con CE e, AFAIK, non ci sono porting 
java con una diffusione significativa.
Anche il framework .NET è portato in una versione che a priori 
rinuncia (secondo me giustamente) alla compatibilità totale con il 
"fratellone" desktop.
Sul fatto di ridere dei cellulari (e dei device non-PC in genere) 
come piattaforma di programmazione ci andrei cauto... (ma il mio 
parere è ovviamente di parte).
Su piattaforme "desktop" (Windows XP, MacOSX, alcune distribuzioni 
linux) la portabilità può essere utile e interessante (soprattutto 
se i sistemi "alternativi" eroderanno quote di mercato a Windows), 
anche se le applicazioni che tu (giustamente) porti come esempio 
(firefox e thunderbird, openoffice) a livello di GUI perdono (sempre 
IMHO) ancora qualcosina rispetto alle applicazioni native.
La potenza dei PC, anche entry level, è sufficiente per rendere 
l'overhead dato dagli strati che garantiscono la portabilità 
(virtual machine, runtime, librerie) trascurabile, se non in casi 
molto particolari e limitati.
Ormai si parla di sviluppo managed (XNA) e di portabilità anche per 
i videogame che sono le applicazioni più "assetate" di performances 
per eccellenza!
Su piattaforme embedded, invece, spesso il software è sviluppato in 
boundle con l'hardware e questo esclude a priori un concetto di 
portabilità completa. Spesso poi gli strumenti che garantiscono la 
portabilità (virtual machines o comunque le si voglia chiamare) non 
riescono a garantire performances accettabili senza un aggravio dei 
costi hardware (anche se su Windows CE il CF versione 2.0 è un passo 
avanti notevole). In molti casi l'applicazione nasce e muore con la 
piattaforma hardware e una nuova release potrebbe comportare pesanti 
differenze sia a livello hardware che a livello di funzionalità 
(perchè nessuno cambia l'hardware per rifare la stessa cosa... salvo 
disastri) che rendono la portabilità un aspetto marginale anche in 
funzione della riduzione dei costi sul lungo termine.
Il caso dei cellulari e PDA (che stanno sempre più integrandosi) è 
un po' diverso perchè il mercato non ha ancora "eletto" (e forse non 
avrà mai) uno standard per le applicazioni. Java è diffuso molto sui 
telefonini (anche se per la mia poca esperienza devo dire che per 
ora è valido il motto "Write Once, Debug Everywhere" e non lo slogan 
originale "Write Once, Run Everywhere"), ma Windows Mobile ha una 
quota di mercato significativa soprattutto nella fascia di mercato 
dei PDA/smartphones dove le possibilità applicative sono più 
interessanti. Dall'altro lato restano i device symbian (su cui però 
lo sviluppo nativo è, sempre IMHO, piacevole come partorire la 
statua della libertà) e java (limitato, paradossalmente, 
dall'incompatibilità tra le diverse implementazioni MIDP).
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)

 "fratellone" desktop.
Io ho scritto diverse applicazioni per pocket e windows. È vero che le 
classi non sono tutte disponibili su CE (per ovvi problemi di memoria ma ti 
assicuro che è molto semplice fare il porting.
[...]
concordo.... e poi credo che entro pochi anni vedremo delle nuove belle 
cose.
Anche se è solo all'inizio ti consiglio di dare un'occhiata al 
MicroFramework (ex "SPOT") che è targettato a device estremamente piccoli. 
Il primo esperimento è stato fatto su alcuni orologi. Adesso ci sono già le 
breadboard di freescale e altre marche che permettono di far girare il 
microframework che pilota ad esempio gli LCD con un livello di astrazione 
che ricalca le stesse classi di WPF.
Ormai le routine per l'hitachi le ho scritte da anni, ma vuoi mettere 
pilotare un lcd grafico con lo stesso look&feel di WPF in una applicazione 
desktop?... Tutto in embrione ma è già impagabile ora :)


 impagabile ora :) 
Visto al MEDC2006 di Nizza. 
Tra l'altro il sistema è stato presentato da un italiano (l'unico 
italiano tra gli speaker...) di cui al momento non ricordo il nome.
E' stato molto interessante farci quattro chiacchiere (probabilmente 
anche lui era felice di esprimersi nella lingua natia :)). 
E' un sistema interessante, soprattutto se (come pare) apriranno la 
virtual machine alle customizzazioni.
Ormai i processori a 32bit a basso costo (ARM7) hanno costi non troppo 
lontani da quelli dei microcontrollori "tradizionali" e strumenti come 
il microframework possono essere utili per velocizzare lo sviluppo ad 
alto livello.
Anche in questo caso si parla di una virtual machine (quasi un mini 
S.O.) e questo la rende interessante per applicazioni complesse 
(display "accessori" sui portatili di gamma alta, user-interface ricche 
per elettrodomestici) dove i tempi di risposta e le performances non 
sono determinanti.
Su applicazioni davvero real-time o dove è fondamentale risparmiare 
anche le frazioni di centesimo (o di watt) il microframework è ancora 
troppo pesante e, comunque, rappresenterà sempre un overhead.
Però anche in questo caso la portabilità è relativa, visto che 
(ovviamente) le funzioni del framework variano da device a device.
Anche la tecnologia SPOT è interessante ma, da quanto ho capito, è 
basata sulla trasmissione in FM e da noi quei dispositivi non 
funzionano perchè le bande utilizzate non sono libere e, comunque, non 
c'è nessuno che trasmette informazioni.
Se si va su sistemi ancora più "piccoli" ci sono sistemi interessanti 
come Arduino (
www.arduino.cc
) che possono essere molto utili 
soprattutto in fase di prototipazione o test (spesso mi capita di 
scrivere il software senza l'hardware corrispondente e poterlo simulare 
rapidamente è manna dal cielo :)) e garantiscono un buon livello di 
astrazione (non devi scrivere i bit nei registri delle periferiche!) 
senza perdere troppo in termini di performance.


Raffaele Rialdi [MVP] ha scritto:
[...]
Diventando Mixed il linguaggio però una domanda sorge spontanea .... sui 
sistemi unix cosa fai ?  ti appoggi a mono ottenendo un linguaggio semi 
funzionante e sempre indietro rispetto alla controparte microsoft ? 
Secondo me la libreria standard del c++ andrebbe estesa e forse 
dovrebbero creare qualcosa di simile alla libreria di classi java ma 
pensare di sposare in uno standard di un linguaggio il framework di un 
OS .... la trovo una scelta perdente

 wrote in news:ep7rvv$d9o$
1...@stargate1.inet.it
:

Il problema non sarebbe solo e soltanto su unix, dove bene o male le 
funzionalità ci possono essere e quindi possono essere "rimappate" in 
una libreria molto ricca (quello che già fa Java).
Il problea è quando devi girare su device limitati dove rischi di avere 
un sacco di varianti e versioni ridotte delle librerie (come già 
succede con Java).


 come Arduino (
www.arduino.cc
) che possono essere molto utili
bello :)


 bello :)
E, tra l'altro, sviluppato in parte in Italia (perlomeno 
l'hardware).



Il problema di C++ come è ora è che i fattori che stabiliscono una buona 
convivenza tra due lib (o tra dll) sono troppi e troppo spesso problematici.
Se è tutto materiale tuo è facile venirne a capo (anche se può essere lungo) 
ma se c'è di mezzo il lavoro di altri la cosa può complicarsi oltremodo.
Questi problemi sono tra le motivazioni della nascita di COM e Corba.
I problemi di portabilità delle porzioni di codice nativo in questi casi 
ritorna ad essere quella di oggi e vedo difficile soluzioni che possano 
risolvere il problema. Le librerie standard non risolvono un gran che. Per 
l'adeguamento alle safe crt ci sono problemi persino tra le CRT di VC6 e 
quelle di VC2005.
Alla fine il tutto la portabilità è tanto più difficile se il codice che 
scrivi ha tante dipendenze. Se scrivi per esempio solo algoritmi di calcolo 
che lavorano su bufferi un memoria (compressione, elaborazione immagini, 
etc.), la portabilità è decisamente più semplice e il problema CRT non è più 
un problema.
Credo quindi che al codice nativo vada il ruolo di quello che è oggi 
l'assembler dentro i driver: se ne fa uso ma solo in porzioni limitate 
proprio per garantire la portabilità.


 l'hardware).
:-))


 tutte le casistiche ma penso una buona parte.
Ok. Però questa roba arriverà su CE tra un po' (speriamo, adesso non ho 
tempo per studiarmela :)) e sui device embedded ancora dopo...
Il dubbio che ho è cosa succede se il GC ha poco tempo ma molta memoria 
da dover liberare per soddisfare una richiesta di allocazione.
Comunque il GC resta una palla al piede per il realtime (sai che ci 
metterà poco, ma non sai quando!).


 decisamente più semplice e il problema CRT non è più un problema.
Il problema è che pochi scrivono gli algoritmi di calcolo senza 
prendere i dati da qualche parte e visualizzarli da qualche altra :)


 metterà poco, ma non sai quando!).
Tranquillo, l'implementazione sui device di quel genere non è così invasiva


 prendere i dati da qualche parte e visualizzarli da qualche altra :)
... e quella parte ha molto più senso farla managed che nativa ;-)


 ... e quella parte ha molto più senso farla managed che nativa ;-)
Ma anche se la fai managed difficilmente sarà portabile tra device 
diversi. I software che provano a mantenere la compatibilità a 
livello di GUI tra PC e palmari o smartphone, IMHO, riescono solo a 
essere scomodi da utilizzare su tutte le piattaforme.


 essere scomodi da utilizzare su tutte le piattaforme.
certo, se è ben strutturata (pura ui da una parte e logica della ui 
dall'altra) è relativamente semplice ... altrimenti è più difficile proprio 
per i limiti dei device


 difficile proprio per i limiti dei device
Symbian ha questa filosofia, ma il suo sistema assomiglia in modo 
preoccupante all'architettura documento/vista di MFC che va 
benissimo per certi tipi di applicazione ma per altri spesso diventa 
un intralcio più che un aiuto.
La separazione tra UI e "logica" del programma è in astratto molto 
positiva ma, secondo me, se non è implementata davvero benissimo, a 
volte porta a comportamenti (ex: lasciare nei combo e nelle liste 
dati non validi in funzione di quanto scelto in altri combo/liste) 
che rendono l'utilizzo del programma frustrante. 
Da questo punto di vista anche il web ha le sue colpe...


 Da questo punto di vista anche il web ha le sue colpe...
Più che il document view mi piace la specializzazione dei controlli.
Odio vedere una datagrid sulla form, voglio vedere un controllo custom 
(derivato dalla datagrid) che la specializza per la funzione specifica che 
svolge in quel contesto.
Migrare questo approccio è decisamente più semplice.


 Migrare questo approccio è decisamente più semplice.
Questo è vero.
In questo caso però, più che "staccare" UI e logica le devi far 
interoperare bene e i controlli custom dovranno "conoscere" bene la 
struttura dati su cui lavorano.
In molti casi, invece, si segue l'approccio "alla web" in cui le 
tipologie di controlli sono molto ridotte e comunque fisse, le 
interazioni a runtime limitate o inesistenti e tutte le validazioni 
demandate al submit, magari condite con messaggi che invece che 
spiegarti cosa devi fare per sistemare il problema sono conditi di 
punti esclamativi, icone rosse etc. che servono solo a aumentare il 
senso di frustrazione dell'utente.
Il problema è che la UI migliore è quella di cui nessuno si accorge... 
e così nessuno ti farà mai i complimenti!


 e così nessuno ti farà mai i complimenti!
verissimo... infatti imho WPF è uno dei fattori che farà scattare la voglia 
di upgrade agli utenti. In fondo dell'applicazione la UI è l'unica cosa di 
cui si accorgono. Un utente base non si accorge della differenza tra una app 
win3.1 e XP (temi a parte) ... tragico ma vero.


 tragico ma vero. 
Quello che temo è che molti programmatori (spinti dalle aziende) 
cureranno soprattutto l'aspetto visuale cercando una UI visivamente 
attraente senza curarsi troppo dell'utilizzabilità dell'applicazione. 
Temo che vedremo form di inserimento dati svolazzare e roteare per lo 
schermo rompendo però sempre i maroni con le message box con scritto 
"dato non valido!" e l'icona rossa.
Non sto dicendo che WPF sia inutile o dannoso, sto dicendo che è uno 
strumento potente che usato bene può davvero migliorare l'interazione 
tra utente e applicazione ma usato male può renderla un inferno peggio 
di quanto non sia già ora.


 di quanto non sia già ora.
Non c'è dubbio, e di fatti la separazione netta tra grafica e codice ed i 
prodotti expression servirebbero proprio a valorizzare la figura del grafico 
che eviti questi assurdi. Certo nelle piccole applicazioni il rischio del 
sig. sviluppatore/grafico/assistenza/tester/architetto/so_tutto_io è 
altissimo :-)


 altissimo :-)
Veramente anche passare la gestione della UI a un grafico, per quella 
che č la mia esperienza, non č il massimo. E milioni di siti flash sono 
lě a darmi ragione :)
Servirebbe una figura di mezzo in grado sia di capire come deve 
funzionare l'applicazione (che dati servono, come č meglio organizzarli  
per seguire sia il flusso "mentale" dell'utente sia per consentire 
all'applicazione di presentare il piů possibile solo dati validi) sia 
di presentare le cose in modo graficamente piacevole.
-- 
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non č valido)

 conosciamo.
Io invece sono piuttosto convinto che le estensioni CLI rappresentino 
piuttosto la morte del C++. E per questo non posso che vederle 
negativamente.
Ciao.

 validi) sia di presentare le cose in modo graficamente piacevole.
eh magari :)
con WPF soprattutto il grafico deve cominciare a capire che la grafica č 
vettoriale e non bitmap... e qui cascano quasi tutti


 negativamente.
Nessuno ti obbliga ad usarle se non ti piacciono anche se però non ti 
capisco...
Il framework (o piattagorma analoga che offre i servizi dichiarati nel CLI) 
offre solo cose *in più* rispetto a quello che hai ora.
Perché dovrebbe essere negativa una cosa che ti viene in aiuto senza nulla 
togliere a tutto quello che hai già oggi?


 togliere a tutto quello che hai già oggi?
Già il C++ è prevalentemente usato in modo poco "corretto" (intendo con 
questo che non si adegua alla sua "filosofia" e non ne sfrutta a fondo i 
suoi punti di forza), queste estensioni lo stravolgono parecchio e 
secondo me non faranno che portare un uso sempre meno "corretto".
Per fare un esempio, l'uso dei puntatori è *da sempre* sconsigliato se 
non nelle (piccole) parti di basso livello, mentre nel "normale" codice 
vanno usati degli smart-pointer (o qualcosa di simile) quando serve 
sfruttare il polimorfismo; avere però il GC (che diventa inutile -anzi, 
io direi dannoso- in C++ se si usano gli accorgimenti di cui sopra) come 
estensione non può che portare ad un maggiore uso di puntatori anche nel 
codice che non fa uso delle estensioni stesse, perché in caso contrario 
si avrebbero due pattern di sviluppo troppo diversi (poco coerenti e 
conciliabli) tra la parte managed e quella non-managed.
Concludo con una risposta di Stroustrup a chi gli chiedeva cosa avrebbe 
fatto se avesse oggi ridisegnato da zero il C++:
"I'd try to create a relatively small core language-containing key 
abstraction features along the lines of classes and templates-and put 
much more of 'the language' into libraries. However, I'd try hard to 
make the core language powerful enough for those libraries to be written 
in the core language. I do not like the idea of having standard library 
writers rely on extra-linguistic facilities not available to 'ordinary 
users'. I'd work on getting this core language very precisely defined".
Ciao.

 precisely defined".
Bene, ma C++/CLI non è un ridisegno.
Inoltre Stroustrup ha dato la sua benedizione a C++/CLI e non per niente sta 
andando nelle conferenze con Sutter il quale riconosce a Stroustrup di aver 
dato un contributo non indifferente al progetto.


 dato un contributo non indifferente al progetto.
Da cosa trai queste tue conclusioni?
Io leggo 
http://www.research.att.com/~bs/bs_faq.html#CppCLI
:
C++/CLI is [...]. It has been standardized by ECMA (ECMA-372).
I am happy that it makes every feature of the CLI easily accessible from 
C++ and happy that C++/CLI is a far better language than its predecessor 
"Managed C++". However, I am less happy that C++/CLI achieves its goals 
by essentially augmenting C++ with a separate language feature for each 
feature of CLI (interfaces, properties, generics, pointers, inheritance, 
enumerations, and much, much more). This will be a major source of 
confusion (whatever anyone does or says). The wealth of new language 
facilities in C++/CLI compared to ISO Standard C++ tempts programmers to 
write non-portable code that (often invisibly) become intimately tied to 
Microsoft Windows.
[...]
I prefer a binding to be a few primitives, expressible as simple 
function calls and simple data structures in any language, possibly 
encapsulated in language-specific libraries.
[...]
As ever, I place a heavy emphasis on portability and recommend people to 
design applications so that access to system-specific facilities are 
through well-defined interfaces specified in ISO C++ (e.g., not to use 
C++/CLI directly). On Windows, this will sometimes be inconvenient 
compared with using C++/CLI facilities directly, but it's the only way 
to gain portability and a degree of vendor independence.
e da un documento raggiungibile da uno dei link presenti 
(
http://www.research.att.com/~bs/uk-objections.pdf
):
[...]
We consider that C++/CLI is a new language with idioms and usage 
distinct from C++. Confusion between C++ and C++/CLI is already 
occurring and is damaging to both vendors and consumers.
A new language needs a new name. We therefore request that Ecma withdraw 
this document from fast-track voting and if they must re-submit it, do 
so under a name which will not conflict with Standard C++.
[...]
we believe C++/CLI has effectively evolved into a language which is 
almost, but not quite, entirely unlike C++ as we know it. Significant 
differences can be found in syntax, semantics, idioms, and underlying 
object model. It is as if an architect said, “we're going to bind a new 
loft conversion on to your house, but first please replace your 
foundations, and make all your doors open the other way.”
[...]
C++/CLI adds more than two dozen new keywords to the 63 keywords of C++ 
syntax -- making the basic language more than a third larger.
[...]
An argument can be made therefore that on the evolutionary family tree 
of programming languages Java is a closer relative of C++ than is C++/CLI.
[...]
C++/CLI adds considerable complication to the already complicated rules 
in Standard C++ for parsing and name lookup
We feel that much of the functionality of C++/CLI could have been 
achieved without doing so much violence to standard syntax.
[...]
C++/CLI changes the behavior of constructor and destructor functions.
[...]
The angle-bracket syntax of generics is very similar to the Standard C++ 
mechanism of templates, but the semantics are different
[...]
C++/CLI syntax sometimes blurs the boundary between language features, 
library classes, and even coding conventions.
[...]
C++/CLI introduces new idioms which conflict with long-standing idioms 
used in Standard C++ code.
[...]
C++/CLI makes extensive use of garbage collection for allocated memory, 
a feature which is under discussion for Standard C++. But the approach 
adopted by C++/CLI has been considered and (at least tentatively) 
rejected as providing no benefit to existing source code. If Standard 
C++ adds a form of transparent garbage collection (instead of using a 
special kind of pointer type, like C++/CLI), the differences between the 
two languages will only grow larger.
Io non avevo letto prima di oggi né la FAQ di Stroustrup né questo 
documento, ma pare che io sia giunto a conclusioni molto simili (persino 
più positive direi) a quelle di Stroustrup, e che quest'ultimo non abbia 
propriamente dato quella benedizione di cui parlavi tu sopra. Mi pare 
piuttosto che abbia un'opinione alquanto negativa del C++/CLI (inteso 
come estensione del C++).
Ciao.

 (
http://www.research.att.com/~bs/uk-objections.pdf
):
Queste non hanno nulla a che fare con Stroustrup. Sono state discusse anche 
in conferenza da Sutter e sono in sostanza le opinioni degli antagonisti "lo 
zoccolo duro" in UK.
Non ho la pretesa di convincerti.
C++ nativo probabilmente migliorerа come linguaggio anche senza estensioni 
CLI ma difficilmente senza queste potrа risolvere i problemi attuali come la 
portabilitа (OS e hardware), la sopravvivenza alle versioni dei compilatori 
e alle CRT. Da anni il problema si risolve cercando di andare sulla 
compatibilitа binaria di componenti (COM, Corba, .net o java) e 
personalmente credo che questa sia l'unica soluzione percorribile.


 compatibilità binaria di componenti (COM, Corba, .net o java) 
Già, fino a pochi anni fa COM era il futuro... che fine ha fatto?
Ciao.

 Già, fino a pochi anni fa COM era il futuro... che fine ha fatto?
LOL l'infrastruttura del framework è COM.
COM è ancora validissimo come concetti ma ha dei problemi che non possono 
essere risolti facilmente.
Non si può costruire un palazzo di 100 piani se già al quinto piano il 
livello di difficoltà è molto alto.
Con il framework attuale il livello di difficoltà è alzato al 50esimo piano.
A dimostrare questo basta vedere le applicazioni MFC e Winform. Quelle MFC 
hanno un livello di complessità maggiore e sono meno curate nei particolari 
... che sono quelli che rendono più piacevole l'applicazione.


 poter seguire l'ultima moda, [...]
il vantaggio dell'ultima moda ha nome e cognome: massima integrazione con
la piattaforma. (massima è il nome :PPP)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 sviluppo. O si ha l'una, o si ha l'altra.
parlando in generale di bytecode che gira tramite una virtual machine, non
è necessariamente vero che sia meno performante dell'assembly generato da
un compilatore C o C++. chiaramente lo sarebbe (e di tanto) se fosse
interpretato, ed infatti solitamente si preferisce l'approccio della
compilazione (cioè traduzione in assembly nativo) all'avvio.
ciò che piuttosto secondo me tende spesso a venir sacrificata con la
facilità di sviluppo è la potenza, alla cui perdita però si rimedia spesso
con strumenti di libreria.


 facilitą di sviluppo [...]
ho scritto una frase ambigua; intendevo dire: "che tende a venire
sacrificata _in favore della_ facilitą di sviluppo".


 hanno un livello di complessità maggiore e sono meno curate nei particolari
MFC è sempre stata una delle peggiori librerie in circolazione, quindi 
non mi pare sia corretto prenderle ad esempio.
Ciao.

 non mi pare sia corretto prenderle ad esempio.
Peggiori magari è esagerato ma certamente non bella. E questo conferma solo 
quello che dico. Le alternative in giro non sono poi tante. E il framework 
ti permette invece di scrivere codice molto più pulito, requisito essenziale 
in qualsiasi applicazione.


 necessariamente COM per ovvi motivi.
Uno dei principi cardine di COM (se non *il* principio) era la rinuncia 
all'ereditarietà come forma di riuso, principio abbondantemente smentito 
(forse fin troppo) in .NET.
Ciao.

 abbondantemente smentito (forse fin troppo) in .NET.
L'ho già detto prima... il framework è costruito su COM. Questo non 
significa che gli oggetti dotnet seguano quelle stesse regole.
E poi è ridicolo che critichi l'ereditarietà sia come è stata affrontata da 
com che da dotnet pur essendo soluzioni opposte.


 com che da dotnet pur essendo soluzioni opposte.
Forse perché "In medio stat virtus"?
Ciao.

 Forse perché "In medio stat virtus"?
LOL... non ti sta bene proprio nulla


 LOL... non ti sta bene proprio nulla
Questa si chiama esperienza :P
Ciao.

 Questa si chiama esperienza :P
ROTFL
