Newsgroup: it.comp.lang.c++
Titolo: Provocazione

A quando delle api per la grafica nello standard del c++?

Non si può fare. Le API sono fornite dal sistema operativo non dal
linguaggio di programmazione. Si perderebbe la portabilità del linguaggio.
"momogiog ilpirata" <gdis...@activenetworkCIAciaCIA.it> ha scritto nel
messaggio news:slrnb6fvqk....@olit.starzanet...


 Si perderebbe la portabilità del linguaggio.
cout << "ciao"
e (ipotetico):
drawline << x1 << y1 << x2 << y2 
potrebbero essere ugualmente "portabili"... no?
;)
-- 
Luc.

guarda un pò chi si vede........un doppio collega! :-)
ciao
max

Il problema é diverso. Il C++ Standard potrebbe (e deve) girare in ambienti
senza grafica.
Inoltre quello che tu chiedi esiste già in librerie non standard che sono
presenti su più piattaforme. Queste librerie sono diverse per ogni sistema
operativo e chiamano le API dei vari sistemi. In compenso mettono a
disposizione un set di istruzioni che é lo stesso per ogni sistema
operativo. In questo modo si può compilare lo stesso codice su piattaforme
diverse. Queste librerie spesso hanno un costo.
Più di quanto ti ho detto non posso aggiungere perché non ho competenza
sufficiente per farlo
Ciao
Emanuele


 senza grafica.
Deve anche poter girare in sistemi embedded senza alcun display testuale!
Eliminiamo la cout/printf ?
PS: comunque sono contrario all'inserimento del concetto di pixel (oltre 
a quello di carattere) in C++... 
-- 
Luc.

 A quando delle api per la grafica nello standard del c++?
Non sarebbe male. Magari definite ad un livello non obbligatorio per
essere full compliant.
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

 ha scritto nel messaggio
news:SVY9a.184203$YG2.5...@twister1.libero.it...


A quando delle api per la grafica nello standard del c++?
A mai, credo, data la diversità degli ambienti in quanto a gestione
della grafica.
-- 
Andrea Laforgia
"640kb of memory should be enough for anyone." -- Bill Gates.

In genere nei sistem embedded si usa il C standard (e comunque anche in C
esiste la printf). .
Inoltre nei sistemi embedded si possono sempre far uscire degli stream di
dati e visualizzarli all'esterno (sempre che non abbia un monitor integrato
come un PALM). Per la grafica é diverso, é troppo legata all'hardware video,
alla risoluzione il numero di colori e per questa ragione é difficile
proporre uno standard grafico. Prendi come esempio un programma per un palm.
Fai la grafica attraverso strumenti standard che per definizione dovrebbero
essere portabili e poi non lo sono perché se gira su un computer non é detto
che giri su un Palm che ha una risoluzione diversa. Se mai riesci ad
ottenere uno standard rischia di essere talmente blando e generale da non
poter essere utilizzato con successo.
E poi dopo aver standardizzato la grafica dobbiamo standardizzare anche
l'audio?
Molto meglio lasciare la grafica alle librerie, magari usando librerie più
portabili.
Chi vuole usare un linguaggio con grafica nativa e portabile dovrebbe
guardare più a JAVA, c'e' una virtual machine che parla con API e altre cose
che non competono ad un linguaggio multipiattaforma.


 A quando delle api per la grafica nello standard del c++?
Dal momento che un comitato di standardizzazione dovrebbe far sue
pratiche provate, piuttosto che inventare cose nuove, bisognerebbe
prima che una o piu' librerie si affermassero su piu' piattaforme.
Tra l'altro non sono convinto che sarebbe una buona cosa
standardizzare una singola libreria per un ambito complesso come
l'interfaccia grafica. L'importante e' che esistano librerie
multipiattaforma.
Ciao,
Nicola

 A quando delle api per la grafica nello standard del c++?
Perche' invece di pensare alla grafica che e' molto system dependent ( X vs
windows )  non si pensa per esempio a versioni standard di:
-sockets
-threads
-IPC
-sincronizzazione
Dato che per tutte queste facilities esistono versione ben poco differenti
da sistema a sistema, quindi facilmente standardizzabili e di ben poco
sforzo per impararle
ciao,
Nids
ps: un sacco di linguaggi hanno interfaccie native se non altro verso i
threads e i sockets (ad esempio ada)
pps: almeno riguardo i socket mi pare si fosse mosso qualcosa, c'e' chi puo'
confermare?

 [07 07:15]:

Come dovevo chiamarla? Interfaccia di programmazione? :)

 chi puo' confermare?
Non lo so.
Ricordo che qualcuno, tempo fa, aveva postato un link con
le proposte prese in considerazione dal comitato di standardizzazione.
Purtroppo non saprei come recuperarlo, ma magari qualcuno
ce l'ha e lo rimanda.
ciao
--
Gerolamo

 ce l'ha e lo rimanda.
Il sito del comitato di standardizzazione e': 
http://wwwold.dkuug.dk/JTC1/SC22/WG21/
Prova a cercare.
Ciao,
Nicola


Se per questo esiste anche il progetto ACE ma ritengo che avere delle
funzioni di IPC e threading nel main stream del linguaggio aiuti molto i
programmatori che si trovano a navigare nalla babele delle librerie non
standard. Ad esempio quando vanno da un posto di lavoro ad un altro si
trovano ad imparare oltre al Coding Standard aziendale librerie che fanno
cio' che fanno altre librerie.
E se un giorno il progetto boost o ace venissero abbandonati? Il main stream
e' "legge" per chi produce compilatori
ciao,
Nids