Newsgroup: it.comp.lang.c++
Titolo: What's New in C++00X?

Segnalo l'articolo:
http://www.codeguru.com/cpp/misc/misc/versioninfo/article.php/c14201__1/
Tutte cose tremendamente comode, e nessuna rivoluzione, mi pare.
-- 
partecipa anche tu:  
http://www.beppegrillo.it/vaffanculoday/

 Tutte cose tremendamente comode, e nessuna rivoluzione, mi pare.
Perche' le cose piu' rivoluzionarie le ha lasciate fuori, come i
reference a rvalue e soprattutto i concetti. Vale la pena di spulciare
direttamente il documento cui si riferisce:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2007/n2336.html
Ciao,
Nicola



Curiosità: a che punto sono i vari compilatori?
Non è che magari si ripeterà la "pazzia" dei primi anni del post standard 
C++ in cui i compilatori non implementavano tutto lo standard, oppure lo 
facevano a modo loro?
Saluti  Manlio Perillo

 facevano a modo loro?
g++ relativamente a buon punto, vedi 
http://www.generic-programming.org/software/ConceptGCC/
Comeau sembra un po' piu' indietro, Microsoft non lo so, perche' non
ho trovato indicazioni su cosa conterra' di nuovo il nuovo VC++,
Borland e' attualmente 4-5 anni indietro a Microsoft, degli altri non
so niente.
Ciao,
Nicola


concordo, ma quando diavolo si siedono e capiscono che devono creare
un set di API serie come
ce l'ha Java? non dico di reinventare la ruota ... per la GUI ad es.
possono prendere WXWidget per
altre API BOOST (mi sembra che qualcosa prendereanno...)
i creatori del C++ dovrebbero finirsela di menersela con concetti
astrusi e guardare di più
allo sviluppo moderno. Caspita gli anni 70 sono passati da un
pezzo.........
Bye

 astrusi e guardare di più allo sviluppo moderno.
Forse stai semplicemente dicendo che C++ non e' linguaggio che fa al 
caso tuo (senza polemica).
Se quello che cerchi e' un linguaggio semplice, con pochi concetti e di 
uso immediato, questo non e' C++.
 > Caspita gli anni 70 sono passati da un pezzo.........
Certe esigenze non cambiano pero'...
  bye
	av.

astrusi e guardare di più allo sviluppo moderno. 
Troppi riflessivi e usati male. Che intendi per "concetti astrusi"? e
sopratutto che intendi per "sviluppo moderno"? 

 Certe esigenze non cambiano pero'...
ovvero?
Regards

 ovvero?
Quella di avere un linguaggio efficiente, portabile, che consenta di 
produrre codice mantenibile, che sia adatto sia a scrivere software di 
basso livello o embedded, sia a scrivere applicazioni di alto livello.
Non sto ovviamente dicendo che C++ debba fossilizzarsi come e' adesso, 
anzi ci sono parecchie cose che mi e' capitato di cercare e non trovare.
Ho semplicemente detto che inserire una GUI non e' in linea con la 
filosofia che il linguaggio ha seguito finora e che quindi probabilmente 
non ce la troverai mai. La "modernita'" non c'entra nulla.
Delle due mi rammarico di piu' che non abbiano per ora intenzione di 
standardizzare la gestione dei thread.
Dal tuo post mi e' sembrato che tu cercassi in C++ qualcosa che non ci 
troverai (tu stesso facevi il paragone con Java). Per questo ti ho 
voluto dire che forse sbagli strada e potresti trovare piu' utile 
rivolgerti ad altri linguaggi.
  bye
	av.

Caspita gli anni 70 sono passati da un pezzo.........
Buttiamo nella spazzatura il TCP/IP perché è vecchio? Che razza di modo 
di ragionare.
Potrei capire una discussione se mettere o no nella libreria standard 
qualcosa per gestire il multithreading, ma lamentarsi dell'età mi 
sembra irragionevole.


 conterra' di nuovo il nuovo VC++,
Guardando la lista delle features sembra abbian puntato su librerie
proprietarie e CLR, l'unica nota che potrebbe interessare gli
sviluppatori C++ non-microsoft-only e' la minimizzazione dello scope
delle variabili nella standard library, ma anche li' forse non e'
grancosa... di C++0x neanche l'ombra.
 
--
Marco
 
-- 
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at 
http://www.malcom-mac.com/nemo

 pezzo.........
Se ci fossero librerie esterne adatte ad essere incluse nello standard
i membri del comitato sarebbero ben contenti di farlo, ma Boost a
parte non e' cosi'.
Ciao,
Nicola

 sembra irragionevole.
in alcuni sistemi però il multithreading non è gestito allo stesso
modo e quindi bisognerebbe
creare un framework comune e poi a basso livello fare dei distinguo? e
allora
perché non avere anche altre librerie????? perché fossilizzarsi solo
sul "core" del linguaggio???
Infine se vai sui siti come sourceforge o simili mi sembra che il nr.
di sviluppatori/programmi
in C++ è in declino Ora dopo aver speso anni per imparare decentemente
il C/C++ non voglio
buttare al water le mie conoscenze solo perché il MIO linguaggio di
elezione non si evolve di pari
passo con l'evoluzione dei tempi.
Regards

 era scontenta di come il C++ facesse certe cose? o sbaglio ancora?)
Veramente Boost e' nato da membri del comitato di standardizzazione
come campo di prova per librerie da inserire nello standard e se
consideri che qualcosa come il 90% delle librerie che entreranno nel
nuovo standard viene da li' mi pare che il comitato stia facendo
parecchio. Pero' se tutto questo dev'essere realizzato sostanzialmente
nel tempo libero delle persone e' chiaro che i risultati saranno
limitati.
Ciao,
Nicola

 secondo me possono tranquillamente essere coperti da librerie esterne.
Sě, ma avere una base standard su cui appoggiarsi sarebbe tutta un'altra 
cosa. Con le librerie esterne invece ognuno fa come gli pare e la scelta 
risulta sempre molto delicata.
EMG
--
EMAG Software Homepage:     
http://www.emagsoftware.it
The EMG's ZX-Spectrum Page: 
http://www.emagsoftware.it/spectrum
The Best of Spectrum Games: 
http://www.emagsoftware.it/tbosg
The EMG Music page:         
http://www.emagsoftware.it/emgmusic
 

 qualcosa per gestire il multithreading,
Il multithreading secondo me è molto meno importante della grafica.


 drammaticamentelibrerie standard che risolvano problemi pratici.
Un RTTI decente e un po', anche una piccola parte, della reflection 
di Java non ci sarebbero stati tanto male =)


 librerie standard che risolvano problemi pratici.
Appunto. E doversi rivolgere per ogni cosa anche banale a librerie esterne 
apre una serie di problemi importanti per il futuro dei prodotti sviluppati 
in questo linguaggio.


 Il multithreading secondo me è molto meno importante della grafica.
Pur concordando con te che non sarebbe male avere qualcosa anche per
la grafica, in realta' non so se la "quantita'" di utilizzatori di C++
per la grafica sia maggiore della "quantita'" di utilizzatori del C++
per il multithreading. 
Io faccio sicuramente parte di coloro che, nella propria esperienza
professionale (ormai decennale), hanno avuto molto piu' a che fare con il
multithreading che non con interfacce grafiche.
Ciao,
Marco.

 di Java non ci sarebbero stati tanto male =)
Decente per farci cosa? per abusarne, come, di fatto, avviene in Java?

 molto da invidiare a Java e C#.
Sottoscrivo e aggiungerei: non scherziamo, per piacere. Ormai a chi mi
dice che Java è *evoluto*, non rispondo neanche più. Io uso Java tutti
i giorni da un bel po' di tempo a 'sta parte e rimpiango la natura di
un linguaggio come il C++. Forse alcune persone sono troppo
concentrate a guardare le librerie e non si accorgono di quanto pecchi
il linguaggio in sé (almeno, in questo senso, il comitato standard del
C++ fa un buon lavoro). Java, per quanto l'odore del caffè sia
gradevole, a volte irrita per le sue astruse caratteristiche e risulta
veramente, veramente odioso. Ora finalmente, scopiazzando i template
di C++, hanno aggiunto i generics, ma io non posso usarli, perché
Oracle (il cui sistema è installato sui server HP del mio cliente)
garantisce supporto solo per certe versioni della virtual machine e
quindi sono costretto a ricorrere agli assurdi container della
libreria standard (bestemmiando come un turco). Java ha un modo
veramente odioso di implementare certe caratteristiche (vedi le
enumeration!!) che in C++ si tirano giù con uno schiocco di dita. I
programmatori Java sono abituati a scrivere codice altamente
inefficiente e vorrebbero che tu facessi altrettanto. La gestione
della memoria sfugge facilmente al controllo, non c'è distruzione
deterministica e devi andarci coi piedi di piombo, ti poni problemi a
cui non penseresti neanche in altri linguaggi e se parli di ricorsione
(cosa che un programmatore mediamente esperto si trova ad usare in
certi contesti) i javisti ti guardano con un sorrisino dicendoti: be',
java e ricorsione non è che vadano molto d'accordo. Ma andate a fare
in culo!...

 Il multithreading secondo me è molto meno importante della grafica.
Evidentemente non è così per chi scrive programmi server, demoni e
quant'altro.

 multithreading che non con interfacce grafiche.
Che il multithreading sia spesso utilizzato a sproposito anche quando se ne 
potrebbe tranquillamente fare a meno è un altro discorso... :-)


 quant'altro.
Perň quel tipo di applicazioni č un po' di nicchia mentre programmi che 
necessitino di un'interfaccia grafica li fanno piů o meno tutti.


 necessitino di un'interfaccia grafica li fanno più o meno tutti.
Be', per chi sviluppa in C++, l'ambito server non è poi così di
nicchia. Almeno, io, tutte le volte che ho lavorato in C++, l'ho fatto
in un contesto del genere e mai per applicazioni utente (scritte,
perlopiù, con altri sistemi come Delphi, più rapidi e intuitivi).
Oggigiorno, molti di coloro che scrivono programmi che necessitino di
un'interfaccia grafica (e magari non di performance esagerate), non
usano il C++.

 usano il C++.
permettimi di dissentire e di farti un esempio di quanto sia
importante avere
un set di API per la grafica (o altre):
tutto l'ambiente desktop KDE è un eccellente esempio di come sia
stupendo
e piacevole programmare con il C++. (certo le Qt hanno delle
idiosincrasie con il C++ standard...ma basta non usarle)

 ha scritto nel messaggio 
news:1188476851.7...@57g2000hsv.googlegroups.com...


Come ho già detto, probabilmente il motivo è proprio la carenza di un 
supporto per questo tipo di applicazioni.


 idiosincrasie con il C++ standard...ma basta non usarle)
Che programmare con il C++ sia "stupendo e piacevole" è opinabile
tanto quanto il fatto che sia indispensabile avere un'API standard per
la programmazione grafica. Non si capisce bene, poi, su cosa tu stia
dissentendo. Io ho fatto presente che molto sviluppo C e C++ avviene
lato server, per applicazioni che elaborano in modo tale da non
necessitare un'interfaccia continua con l'utente e che quindi
l'urgenza di avere un sistema standard per fare certe cose è meno
sentita.

 supporto per questo tipo di applicazioni.
Secondo me non è così. Di toolkit grafici per C e C++ ce n'è a
bizzeffe, per qualunque piattaforma. Se qualcuno vuol sviluppare un
software in C++ che faccia uso di finestre e bottoni lo fa
tranquillamente (wxWidgets è un esempio di framework, oltretutto cross-
platform). Non è la mancanza di supporto da parte dello standard a far
sì che questo tipo di applicazioni non siano diffuse, ma la natura
stessa del linguaggio, più adatto per altri ambiti più di
"background". D'altronde, la grafica è legata strettamente alla
piattaforma e chi vuol sviluppare per Windows o per Linux ha tutto ciò
che gli serve. Standardizzare la costruzione di una GUI che è un
processo *ortogonale* al linguaggio, mi sembra inutile. Tieni presente
che neanche nel tanto adorato Java hanno "standardizzato" nulla.
Esiste SWING, ma chi lo usa? stendiamo un velo pietoso.

 piattaforma.
Secondo me potrebbe anche entrarci, vorrei pero' sapere quale
linguaggio ha *una* (e una sola) libreria grafica standard.
Ciao,
Nicola

 potrebbe tranquillamente fare a meno è un altro discorso... :-)
Concordo su questo punto, anche se dire questo non implica
necessariamente che il multithreading sia poco importante. Andrebbe
usato nelle situazioni giuste e con cautela, questo sì. Java, tanto
per battere dove il dente duole, è un pessimo esempio a riguardo.

 processo *ortogonale* al linguaggio, mi sembra inutile.
Non intendevo suggerire di standardizzare l'intera GUI ma di offrire un 
supporto standard stabile di base. La cosa è ben diversa.




Python ha Tkinter (wrapper per Tcl/Tk) nella libreria standard (quindi si 
può considerare come la sola e unica libreria grafica standard).
Che sia un bene non lo so.
E' troppo "rozza" per fare qualcosa di professionale, ma permette agli 
applicativi di aggiungere un pò di GUI (ad esempio è quanto fa Mercurial, 
che prevede un comando per visualizzare in modo interattivo e grafico la 
storia del repository, senza tirare in ballo dipendenze esterne).
Saluti  Manlio Perillo

 "background".
scusami cosa centra la natura del linguaggio con gli ambiti di
programmazione.
Un linguaggio detta delle regole base (core) e poi attorno ad esse si
creano
framework. Non credo che il C++ sia più orientato ai software come
li chiami tu: di background. Semplicemente data la mancanza di
framework standard ed evoluti
grafici, di rete ecc. i programmatori più "puristi" lo utilizzano con
quello che ha!

 supporto per questo tipo di applicazioni.
Sarà, ma a forza di scrivere applicazioni grafiche con librerie non 
proprietarie oggi le scrivo con altri linguaggi. Più che per carenze 
del linguaggio per carenze dell'ambiente di sviluppo.


 investono fior di quattrini nella loro evoluzione.
Non mirisultano siano chiusi, anzi tutt'altro, sono standar EMAC e
essitono anceh implementazioni completamente aperte (vedi mono). Poi
che siano nati sotto lo spunto di aziende è verissimo, ma non lo vedo
necessariamente un male.
Ciao
	Mavimo
-- 
htp://
mavimo.netsons.org

>>>>
non capisco, se anche l'inventore del linguaggio vorrebbe un minimo
set di API grafiche da parte
di chi, del comitato, è osteggiato?  mah ...

 supporto standard stabile di base. La cosa è ben diversa.
Troppo diverse, a mio avviso, le varie piattaforme grafiche, perché ci
sia qualcosa di comune e sarebbe troppo complicato aggiornare il
supporto all'evoluzione delle GUI. Sotto Windows possono esserci
"concetti" visuali che sotto i window manager di Linux vengono
implementati in modo diverso e in modo diverso ancora sotto Mac OS X,
ecc... ecc... L'espressione "interfaccia grafica" può voler dire tante
cose.

Semplicemente data la mancanza di framework standard ed evoluti grafici, di rete ecc. i programmatori più "puristi" lo utilizzano con quello che ha!
Quindi tu mi stai dicendo che ci si sta accontentando di usarlo per
quelle 4 caratteristiche che ha?

 di chi, del comitato, è osteggiato?  mah ...
Forse il fatto che non è una cosa così semplice come sembra, da
realizzare?
E poi, non è che perché una cosa la chiede Stroustrup, bisogna farla.
D'altronde, lui stesso nelle ultime righe mette le mani avanti: "The
success depends on adaptation from developers of graphics libraries."
e questo, secondo me, è un obiettivo difficile da raggiungere.
Secondo me ci sono dei "concetti" nei vari sottosistemi grafici che
potrebbero discostarsi anche di molto, dall'uno all'altro, e non
capisco come si potrebbe "standardizzare" questa complessità.

 di chi, del comitato, è osteggiato?  mah ...
Dal fatto che nessuno mette i soldi per sviluppare una simile
libreria. Come ti ho gia' detto se esistesse una libreria adeguata, il
comitato sarebbe felicissimo di includerla.
Ciao,
Nicola

 Assembly?
i videogames in Java si scrivono. I cellulari, ad es., ne sono zeppi!
In assembly si scrivono persino i S.O. 
http://www.menuetos.net/
insisto, e non per polemica ma solo per scambiare diversi punti di
vista (ogni tanto
si può divagare dalla programmazione fine a se stessa), ma se per
natura
di un linguaggio intendi quello che hai scritto forse non ti sei
spiegato bene o
forse io non ho capito!
Prova a dirlo con qualche esempio...
Bye

 
In realtà MS nell'evoluzione del C++ ci ha investito: vedi C++/CLI che è 
stato standardizzato ECMA.
Poi d'accordo che lo abbia fatto per "adeguare" c++ con il proprio 
framework, comunque questa (che piaccia o no) è una evoluzione del C++
Anzi a dirla tutta a me sembra che MS creda parecchio nel C++ come 
linguaggio di sviluppo (per chi vuoloe fare "seriamente"). Ovviamente 
sulla piattaforma MS...
Come spesso sento dire: il futuro è "mixed" (che in termini MS significa 
c++ nativo + .NET)
GM

 Java?
Scusa la mia lentezza nel comprendere, ma non mi e' chiaro dal
discorso dove, in java, ritieni che venga fatto un abuso della
reflection e fin dove invece sia lecito spingersi ad usarla.
--
Marco
 
-- 
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at 
http://www.malcom-mac.com/nemo


non so se MS creda molto nel C++ a me sembra che invece creda molto
nel C#
guarda, ad es., il framework XNA per sviluppare i videogames e come
spinga a
programmarli nel suddetto linguaggio.

Prova a dirlo con qualche esempio...
Già fatti.

 in culo!...
Sottoscrivo in     7 lingue .... condivido in pieno lavorando anche io 
diviso
tra c++ e java .... poi il j2ee per alcune cose lo trovo assolutamente 
odioso ....
(EJB in primis) fare una cosa semplice.... è sempre un casino ... 
platform indipendend ma sovente application server dependent ...

 supporto standard stabile di base. La cosa è ben diversa.
Il supporto di "base" servirebbe a poco. Se la necessità è quella di
sviluppare un'applicativo con GUI probabilmente la GUI deve essere fatta
bene ;)
Sarebbe IMHO sbagliato forzare uno ed un solo paradigma di sviluppo
(e.g. QT e GTK usano filosofie diverse per costruire un'applicazione
grafica, non si tratta solo di avere classi con nomi diversi).
Sempre IMHO il massimo livello di standardizzazione potrebbe essere
un'API di disegno (vettoriale? direi di sì), su cui verrebbero comunque
costruiti diversi toolkit; nessun grosso vantaggio rispetto ad oggi.
Luca
-- 
Un apostolo vedendo Gesu` camminare sulle acque:
- Cazzo se e` buono 'sto fumo!!!

 investono fior di quattrini nella loro evoluzione.
Non si tratta di corporazioni, ma di aziende. Dietro Java c'e' l'azienda 
"Sun Microsystems, Inc." e dietro C# c'e' l'azienda "Microsoft Corporation".
La parola "corporazione" in italiano e la parola "corporation" in 
inglese britannico, non signficano "azienda", ma "consorzio". In inglese 
statunitense, invece, la parola "corporation", contrazione di "business 
corporation" mi pare che significhi "societa' commerciale di capitali".
-- 
     Carlo Milanesi
 
http://digilander.libero.it/carlmila

 per battere dove il dente duole, è un pessimo esempio a riguardo.
Ecco. Appunto. Ora va di moda J2EE,  JMS, le code  e gli EJB.
Il tutto per i "vantaggi" derivanti dall' evitare il multithreading.
Sono reduce da una esperienza relativamente recente in cui qualcuno
aveva scritto un metodo di un EJB in cui (semplificando moltissimo):
1) si chiamava una altro metodo dell'EJB che provvedeva a 
   1.1 mettere un messaggio in una coda
   1.2 restituire un valore di ritorno
2) si andava a mettere il valore di ritorno di cui in 1.2 in una 
   tabella di un DB Oracle
 
3)  l'MDB che prelevava il messaggio dalla coda di cui in 1.1. faceva nmila
cosa (tra cui recuperare dei file via ftp). Poi, una volta
recuperati i file, andava nella tabella di cui al
punto 2 a cercare l'id del messaggio.
Ovviamente nessuno si era preoccupato del fatto che se l'MDB che
recupera i file ftp (punto 3) e' piu' veloce di quello che deve inserire l'id 
nel database e/o se l'AS schedula il secondo prima del primo o revocando
il primo, l'id nel database potrebbe ancora non essere stato scritto al
momento in cui l'MDB lo va a cercare
e quindi si potrebbe avere un errore dovuto alla velocita' relativa degli
MDB. Questo perche' *ovviamente* "c'e' l'AS BEA weblogic che
ci pensa lui a sincronizzare i vari EJB".
In realta' gli EJB coinvolti non erano 2, ma 10-20 perche' l'MDB
che recuperava dati dalla coda di cui al punto 1.1 metteva poi in 
un'altra coda, dalla quale un altro MDB recuperava messaggi, e li metteva in
un'altra cosa e cosi' via fino a recuperare
i file ftp (e altrettante code e MDB per tornare indietro). E anche
l' EJB da cui partiva il tutto (cioe' quello che faceva gli inserimenti
in coda di cui al punto 1.1) usava altri EJB (ad esempio un Entity Bean per
scrivere nel DB).  
E poi devo sentire gente che si lamenta dei sistemi che permettono
di fare preemption perche' secondo lui non e' giusto farla.
W l'abolizione del multithreading che riduce la complessita' :-)
Ciao,
Marco.

 necessitino di un'interfaccia grafica li fanno più o meno tutti.
Io nella mia vita professionale, in C/C++ ho fatto:
- software per simulatore motociclistico (diciamo che c'erano dentro
architettura client/server, TCP/IP+FDDI, moltissimo multithreading, molta
preemption. In altre parole, molto hard real time. Anche qualcosa relativo 
ad una interfaccia grafica per la gestione del circuito virtuale,
condizioni atmosferiche, ecc. ma infinitamente meno "pesante" rispetto
alla parte precedentemente nominata)
- software per simulatori di sistemi di telecomunicazione basati su umts.
Praticamente nessuna interfaccia grafica, abbastanza multithreading, molta
architettura client/server TCP/IP. In pratica un sistema "soft" real time
- software per la simulazione su rete TCP/IP di autenticazione GSM (moltissima
architettura client/server TCP/IP, HTTP, un po' di multithreading, 
qualche libreria di cifratura (TDES,RSA), poca roba a livello di
interfaccia grafica e comuqnue fatta in html)
quanto sopra mi ha impegnato per almeno 3/4 dei miei circa 10 anni lavorativi.
Il resto... qualche sito web, qualcosa con J2EE (vedi post precedente) in
cui le interfacce grafiche non le facevo io, qualche lavoro non da programmatore
(come adesso e come negli ultimi anni mi capita sempre piu' spesso)
Ciao,
Marco

 Io nella mia vita professionale, in C/C++ ho fatto:
Per me è anche "peggio".
Io, negli ultimi 10 anni, mi occupo principalmente di server. Gli unici 
programmi con interfaccia che faccio mi servono per testare i server. 
Ma spesso uso script in python.
Andando oltre i 10 anni programmavo PLC, e non c'è molta interfaccia in 
quell'ambiente, ma anche poco C/C++.


 capisco come si potrebbe "standardizzare" questa complessità.
Sì, però, però...
insomma, qualunque sia il sottosistema grafico che si consideri non
credo che non contempli una funzione tipo "apri una finestra grande
tot", al limite intesa come semplice rettangolo di pixel nudo e crudo. E
nemmeno credo che non possieda una funzione per scrollare l'area interna
di una finestra, o una per cambiare font. Sono funzioni che avrebbero
perfettamente senso perfino in una GUI su un terminale a caratteri.
Hai ragione sui concetti diversi, e sono cosciente del fatto che
implementare un sistema completo, universale e valido per tutte le GUI è
praticamente impossibile (Java si limita a portarsi dietro la SUA GUI
dovunque va come una lumaca la casa, per cui... non vale!), ma alcuni
meccanismi di base si potrebbero (almeno iniziare a) supportare. Come tu
stesso dicevi poco sopra, C++ supporta i file anche su macchine senza
nessun filesystem, per cui non vedo problemi nel supportare anche le
primitive grafiche di una GUI, almeno quelle più base-base...
In più, il paradigma a oggetti si è dimostrato molto adatto alle GUI:
secondo me la possibilità di mettere in piedi una "GUI Standard Library"
alla fin fine ci sarebbe.
Uhm e se proponessimo di adottare le QT nel C++, come stan facendo con
boost?? :-D

 primitive grafiche di una GUI, almeno quelle più base-base...
Proprio ciò che intendevo.


 primitive grafiche di una GUI, almeno quelle più base-base...
Definisci primitive. DrawLine, FillRect, BitBlt? Queste sarebbero più o
meno quelle che ti servono per costruire "tutta" la GUI ;)
Ma chiaramente perderesti la connessione con i sistemi che hanno
conoscenza nativa di concetti di più alto livello.
Luca
[1] A dire il vero sto pensando più il C, perché ho meno familiarità con
lo standard del C++.
-- 
"L'amore consiste nell'essere cretini insieme." -- P. Valery

 In assembly si scrivono persino i S.O. 
http://www.menuetos.net/
Come sarebbe "persino" ?
La scrittura di parti di S.O. e' probabilmente il tipo di 'applicazione'
che piu' si adatta all' utilizzo di assembly.
Ciao,
Marco.

 "mio" linguaggio si evolvesse con i tempi.
Cosa abbiana di innovativo Java mi rimane un mistero. Forse Java sarebbe
stato innovativo se lo avessero creato 10-15 anni prima. Nel 94 non
aveva nulla di nuovo (come non lo ha adesso).
Oh, ma nemmeno C++ era *estremamente* nuovo nel 1984. D'altra parte non
è che si giudichi un linguaggio da quanto è innovativo, ma da quanto
bene svogle il suo mestiere.
-- 
blog:  
http://www.akropolix.net/rik0/blogs
 | Uccidete i filosofi,
site:  
http://www.akropolix.net/rik0/
      | tenetevi riso e
forum: 
http://www.akropolix.net/forum/
     | bacchette per voi.

 puň considerare come la sola e unica libreria grafica standard).
Vero. Ma direi che nei fatti non lo č: mi spiego, non č che il 51% delle
applicazioni grafiche in Python sia fatto con Tk. Anzi. Č solo che č una
delle piů facili da buttare dentro e pacchettizzare ovunque.
Salvo poi che spesso ha dei bachetti, ma lasciamo perdere.


 di Java non ci sarebbero stati tanto male =)
Permettimi, ma se devo pensare a reflection fatta bene, non penso certo
a quella monca di Java.


 linguaggio ha *una* (e una sola) libreria grafica standard.
Credo Java, in realtà ne ha due, ma in pratica una è vista come quella
'vecchia'.
Poi alcuni linguaggi/ide tutto in uno. Che so, VB. RealBasic.
Immagino ci siano altri esempi.
ObjectiveC. Cambia il nome, sotto OS X si chiama Cocoa (ed è più
estesa), sotto GNUStep si chiama appunto GNUStep. E non è maturissima.
Io rispondo solo alla tua domanda, eh :)


 Io rispondo solo alla tua domanda, eh :)
Anch'io :-)
Ciao,
Nicola

 a quella monca di Java.
Il punto e' che secondo me tu non pensi alla reflection, tu pensi al
Meta Object Protocol (vedi ad es.: 
http://en.wikipedia.org/wiki/Metaobject
).
O no?
Ciao,
Nicola

 meno quelle che ti servono per costruire "tutta" la GUI ;)
Prima dici che con le primitive grafiche non ci fai niente e poi che con
quelle tre ci fai tutta la GUI? Deciditi, perchè una delle due è una
cazzata :-)
Per quanto riguarda le differenze fra le funzioni per i file e i metodi
(ipotetici) delle classi della GUI C++, io tutto sto gran problema non
lo vedo. Una finestra è una finestra dappertutto, e alcuni suoi
attributi e possibili azioni su di essa sono ovvi e universali. Si può
cominciare da lì. Lo stesso vale per i controlli e il resto delle entità
grafiche. Poi, in seconda battuta, si potranno aggiungere i metodi e gli
attributi che sono diversi da sistema a sistema, rendendoli opzionali o
inventandosi qualche meccanismo unificatore. E non dire che è
impossibile: le funzioni file sono GIA' diverse da sistema a sistema,
per quanto marginalmente... ci sono funzioni di libreria che esistono su
windows ma non su Unix e viceversa, per esempio.
L'utilità di questo lavoro si vedrebbe al momento di scrivere codice
multipiattaforma. O di scrivere librerie grafiche come le QT. Saresti
meno vincolato al particolare sistema grafico e/o avresti meno bisogno
di librerie esterne: quel che ti servirebbe sarebbe già nel linguaggio.

 Meta Object Protocol (vedi ad es.: 
http://en.wikipedia.org/wiki/Metaobject
).
In effetti no, quello č il 'passo successivo'. Purtroppo in un ambiente
statico e compilato infilare in modo ragionevolmente efficiente la
modifica a runtime di metaclassi e classi base č piů un problema.
No, mi riferivo al fatto che un problema abbastanza semplice come quello
della reflection (dove con 'semplice' intendo che sia facile fare
un'interfaccia semplice) passa per un macello di metodi, metodini,
checked exceptions e tutto.


 risulta sempre molto delicata.
Cose intendi per base standard?
Secondo me diventerebbe molto difficile stabilire un limite in tal senso e 
in questo momento faccio davvero fatica ad immaginarmi a come potrebbe 
essere.
Se grafica base vuol dire accedere alla memoria videa puo' servire ma non 
piu' di tanto... la grafica raster nelle interfacce sta per morire per 
diventare tutto vettoriale e  poi se ci mettimao di mezzo pure il 
multimediale e' un mondo molto vasto.
Non lo so, non riesco proprio a vedermela questa cosa.
-- 
Gugu
OIBABOI! (Tutti insiem OiBaBoi)

 bene svogle il suo mestiere.
perdonami la boutade, ma, se per questo, non c'e' niente di nuovo sotto il
sole, dal lisp in poi...
-- 
Under construction

 sole, dal lisp in poi...
In parte si e in parte no. Mi spiego meglio: Lisp è un linguaggio per
certi versi geniale. Estremamente potente, flessibile, agile e comodo.
Tuttavia ha anche diversi handicap.
In primo luogo ci sono voluti diversi anni per avvicinare le performace
di Lisp a quelli dei linguaggi più performanti. Questo chiaramente vale
solo nel codice pesantemente algoritmico, io sono un Pythonista, sono
perfettamente conscio che non sempre e non in ogni pezzo di programma le
performance sono vitali.
Ma per dire facendo un confronto di performance fra Ocaml e Lisp è un
massacro. Purtroppo io ho a disposizione solo implementazioni open di
Lisp, dicono che ci siano alcuni compilatori commerciali che fanno molto
di meglio.
Inoltre Lisp è in pratica un linguaggio per programmare linguaggi. È
metaprogrammazione all'ennesima potenza. Per quanto io adori la
metaprogrammazione, non è certo per tutti.
Per cui linguaggi che in qualche modo perdono un po' di generalità di
Lisp per essere più facili da utilizzare, sono in qualche modo utili e
'nuovi'. Mi spiego meglio, è vero che usano concetti nati per la prima
volta in ambiente Lisp, tuttavia li usano in modo nuovo e diverso.
Poi potremmo parlare delle Monadi di Haskell. È vero che non ho dubbi
che si possano implementare pure in Lisp, ma per come sono fatte sono
una cosa 'nuova' di Haskell. Poi è indubbio che globalmente Haskell
prenda tantissimo da Lisp.
Invece quello che vedo in Java è una cosa diversa. È un: ok, C++ è
abbastanza cool. Fico. Ma è tosto. Facciamolo più semplice. Hey, ma
perchè non lo facciamo su una macchina virtuale? È in qualche modo un
incontro un po' azzoppato fra Smalltalk/ObjectiveC e C++.
In questo senso non lo vedo particolarmente innovativo.
Allo stesso modo vedo Ruby meno innovativo di Python, pur apprezzandoli
entrambi. Ruby 'ripulisce' Perl, mutuando da Python e Smalltalk. Python
invece continua a importate features sintattiche e semantiche da altri
linguaggi, fondendoli in modi e contesti nuovi.
Vuoi la valutazione lazy, che in contesto imperativo non è certo una
cosa poco originale. Ma quello che aggiunge soprattutto Python è
l'attenzione maniacale per la sintassi. Questa è l'idea al cuore del
linguaggio, assieme alle altre 'massime teoriche' presenti nello zen.
Insomma, il design, non le features.
Allo stesso modo OCaml non lo vedo particolarmente originale. Haskell
molto di più. Prolog a suo tempo è stato parecchio originale, Mercury
direi anche, pur conoscendolo poco.
Torniamo a C++? Originale? Direi che i templates di C++ sono, seppur
migliorabili e 'inutili' in un contesto dove è possibile fare
type-inferencing e tutto e appunto parametrico a-la Haskell, una cosa
piuttosto innovativa nel contesto in cui nascono. E comunque sono in se
e per se una cosa ben più complessa (nonchè turing-completa) del
semplice meccanismo di derivazione ML di Haskell e OCaml.
Per il resto viene da altri linguaggi, ma insomma, sti template sono una
cosa piuttosto originale.
Di Java invece a livello di linguaggio non vedo *nulla* di nuovo.


 E qui ti credo sulla parola.
Caruccio Cocoa. È in pratica la GUI che mi piace di più. Già dal fatto
che per violare pesantemente l'approccio MVC uno deve metterci del suo
apprezzo, rispetto agli IDE che invece ti incoraggiano in tutti i modi
ad andare contro il tutto.
Aggiungo che ora che finalmente Objective-C++ è entrato definitivamente
dentro il gcc la cosa porta vantaggi notevoli anche per i programmatori
C++, in pratica permettendo di scrivere tutto il Model in C++ e poi
Objective-C/C++ come semplice Controller.
Non che sia necessario, Objective-C funziona bene anche da solo.
Tuttavia per i programmatori C++ può essere un plus, permettendo di fare
il pezzo tosto in C++.


 certoa quella monca di Java.
Ucapi', ma meglio poco che niente...
Comunque, viste le reazioni, credo ci sia un'allergia di fondo
allaparola "Jxxa", che mi guardero' bene dall'usare in seguito.
Rileggete il mio messaggio come:
"Qualche miglioria sostanziale a RTTI sarebbe stata opportuna, ma e'
stata purtroppo scartata durante il processo".
Ciao,


 allaparola "Jxxa", che mi guardero' bene dall'usare in seguito.
Non e' una questione di allergia. Dal momento che Java e' nato
togliendo pezzi al C++ e' inevitabile che esca maluccio dal confronto.
E' vero che in Java c'e' la reflection che di tanto in tanto sarebbe
utile anche in C++; meno che in Java pero', grazie ai template.
E' altrettanto vero che c'e' la garbage collection, ma a parte il
fatto che in C++ sta per arrivare, tra dover scrivere
p = null;
e dover scrivere
delete p;
la differenza non e' tanta. E' vero che annullare i puntatori non e'
sempre indispensabile in Java, ma e' piu' facile ricordarsi una cosa
che va fatta sempre rispetto a una che in molti casi si puo' anche non
fare. Senza contare che per darci la GC ci hanno tolto la distruzione
deterministica; almeno in C++ in molti casi il delete posso metterlo
nel distruttore e non ci penso piu'.
Ciao,
Nicola

 nel distruttore e non ci penso piu'.
Io mi auguro che la distruzione deterministica rimanga sulle cose a
stack. Se no sarebbe demenziale. In buona sostanza verrebbe a cadere uno
dei motivi cardine per scegliere C++. Per lo meno per come la vedo io,
eh.


 nel distruttore e non ci penso piu'.
Come ci hanno tolto la distruzione
determinista!?!?!?!?!?!?!?!?!?!? E come si fa senza!?
Ma è proprio cosi indispensabile sto GC!? Quali sono le motivazioni per
cui lo vogliono inserire?
Ciao
-- 
Andrea Corradi | Debian User | 
www.debian.org
Fingerprint: A41E F6B0 DBDB F04C 4940 E411 30F3 CD62 57B1 8458
gpg --keyserver 
keyserver.linux.it
 --recv-key 57B18458
Please avoid sending me Word or PowerPoint attachments.
http://www.gnu.org/philosophy/no-word-attachments.html

 cui lo vogliono inserire?
Calma, calma, mi riferivo a Java, non al C++!
Ciao,
Nicola

 eh.
Assolutamente.
Ciao,
Nicola

 Calma, calma, mi riferivo a Java, non al C++!
ah OK!


 posso metterlonel distruttore e non ci penso piu'.
Ecco, questo e' un altro grande errore, che se non erro in C# e'
statocorretto. Ho letto qualcosa dei paper di C++, ma non mi e' parso
di scovare niente riguardante deterministicita' della distruzione
dipuntatori "leaked"... e' sfuggita a me, o proprio e' UB?
--


 'applicazione'che piu' si adatta all' utilizzo di assembly.
Fai bene a dire "Parti", ma...
"MenuetOS is an Operating System in development for the PC written
entirely in 32/64 bit assembly language"


 alla fin fine ci sarebbe.
su questo non saprei. Lo spero, ma non conosco molti sistemi per 
cui non so giudicare la trasferibilità dei concetti.
In ogni caso mi pare che questo compito, per avere qualche 
speranza, non possa essere sorretto esclusivamente da chi 
sviluppa il linguaggio (se non ai costi che hai citato) : 
bisognerebbe che anche chi sviluppa i sistemi operativi (o i 
relativi sottosistemi grafici), implementi una serie di elementi 
di base con API simili, e quindi supporti una certa convergenza 
almeno a livello di base.
Ho per caso visto l'interfaccia di AERO (che non uso), e la 
frase appena scritta mi fa abbastanza ridere cmq ... :-)
ciao
Soviet


 l'universo.
IMHO dipende come la vedi. Io sono un 'essere umano', sono uno
'studente' e sono un 'figlio'. Uno 'studente' è un 'essere umano' e idem
un 'figlio'.
Io tuttavia li vedo principalmente come 'aspetti' più che come
'essenza'.
Io sono io e basta, eventualmente io sono un essere umano. E mi
*comporto* da studente. E da figlio. Quando smetterò di studiare, per
esempio, non sarò più uno 'studente' (lasciando stare Goya, :) e
lasciando stare che un computer scientist non smette di studiare,
insomma, capiamoci)
Ma nota che ancora una volta io la vedo da dinamista. Io sono io, so
fare delle cose e alla bisogna le faccio. Non mi sentirei ben colto
dalle 'interfacce'. Eppur tuttavia non la vedo come una soluzione
inerentemente sbagliata.
Le interfacce sono una rottura di palle se non hai modo di ereditare il
comportamento. Da cui parlavo di Interfacce + Mixin.


 piattaforma c'è, meglio è.
Con il risultato di avere un'applicazione grafica che è un cattivo
cittadino ovunque.


 comportamento. Da cui parlavo di Interfacce + Mixin.
E' proprio questo il punto. L'importante e' distinguere le classi
interfaccia dalle classi implementazione. In questo modo i problemi
dell'ereditarieta' multipla scompaiono quasi del tutto.
Ciao,
Nicola

 tabelle e poco altro.
Come ho già detto (rileggere post precedente) il C++ *supporterebbe* le
GUI, ma *non* ne implementerebbe nessuna di suo. Non è che perchè il C++
 supporta i file, debba avere una funzione per aprire qualunque tipo di
file esistente al mondo (JPG, XLS, ZIP ecc.)... ti pare? Si limita a
mettere a disposizione un oggetto "file" e le funzioni "apri", chiudi",
"leggi", "scrivi" e poco altro. Con la grafica sarebbe lo stesso.
Non mi pare affatto una cosa impossibile, nè poco utile: forse perchè il
C++ sui file si occupa solo delle cose base, non lo usi affatto e chiami
direttamente il S.O. per gestirti i file che ti servono? Certo che no!

 Non mi pare affatto una cosa impossibile, nč poco utile
Io una libreria talmente elementare che non possa essere usata per
sostanzialmente nulla, con concorrenti piů complete (o altrettanto
semplici) non la vedo una gran pensata.
Specie tenendo conto del costo di progettare una libreria GUI.


 Specie tenendo conto del costo di progettare una libreria GUI.
Niente, non ci arrivi. Mi arrendo.
Vabbè, ultima prova... tu nei tuoi programmi C++ le classi fstream le
usi? O le funzioni fopen, fwrite, fread ecc. ecc... le usi?
Io dico che chi scrive le QT o le "librerie concorrenti più complete",
dovendo il C++ fornire loro delle funzioni base per le GUI, non
insisterebbero a scriversi da soli le analoghe di quelle funzioni, ma
opportunamente le userebbero nelle loro librerie, evitando di scrivere
tot funzioni per tot piattaforme supportate: le loro librerie GUI
avrebbero una struttura più semplice e la portabilità migliorerebbe.

 avrebbero una struttura più semplice e la portabilità migliorerebbe.
Mi fa piacere che la pensi così. Peccato che sia sostanzialmente una
fantasia. Su OS X la 'base' della GUI è Quartz, su X11 le Xlib.
Quindi tu suggeriresti che chi volesse fare queste librerie userebbe uno
strato *intermedio* (a tutti gli effetti un layer software in più, con
conseguente perdita di performance precisamente nelle cose che
andrebbero a finire nei tight loops?).
Chiaramente ci giochiamo l'antialiasing, che Quartz per esempio supporta
di default. Per cui invece di usare quello (eccellente) di Apple, ce ne
reimplementiamo un altro *sopra* questo strato da te suggerito. E no,
non è che uno può pensare di usarlo sotto Apple si e sotto Linux no,
specie su delle primitive, se no ti trovi con primitive, per l'appunto
diverse.
Non a caso chi scrive librerie multipiattaforma *di rado* va ad usare le
primitive. Per esempio Qt su OS X si appoggia a Carbon, che è una
toolkit C/C++ di livello *nettamente* più alto delle primitive. Su X11
non so che approccio abbiano scelto.
GTK si splitta in GDK. E appunto portare GTK da qualche parte si
trasforma nell'offrire un'interfaccia GDK compatibile.
wxWidget addirittura si appoggia ai widget nativi.
Faccio presente che chi avesse voluto fare una GUI con i criteri da te
descritti, avrebbe potuto usare direttamente OpenGL come primitive. Ma
pare non ci sia stato un grande interesse.
