Newsgroup: it.comp.lang.c++
Titolo: filosofia di distribuzione di C++

Salve,
secondo voi non sarebbe meglio se anche per C++ ci fosse un compilatore di
riferimento 100% compliant e free (come il JDK di SUN per Java) piuttosto
che tanti compilatori con ognuno le sue estensioni e che non fanno altro che
aumentare le possibilità che un sorgente non sia portabile?
Alcuni sostengono che sia meglio avere più compilatori... io sono dell'idea
che *indubbiamente* sia più vantaggioso l'esistenza di UN compilatore per
ogni piattaforma.
Ad es.: La società/azienda/centro-ricerca (non so cosa sia) dove lavora
Bjarne Stroustrup, insieme agli altri membri del comitato di
standardizzazione o cmq insime al altri grandi conoscitori di C++ (es.:
Koenig, Lippman, Sutter, Meyers, Schildt, nooooo! :) potrebbero scrivere un
compilatore free e disponibile (tramite vari porting) per Windows/Linux
etc... tutte le altre sottospecie di compilatori che non sono 100% compliant
(come i gcc + frontend vari oppure DEV C++) o escono totalmente di scena,
oppure, se vogliono, si dovrebbe accontentare di compilatore codice C (che
sicuramente rispetterebbero lo standard). Inoltre, i vari IDE come C++
Builder e Visual C++ potrebbero basarsi su quel compilatore standard, e se
proprio devono farsi guerra lo potrebbero fare in termini di miglior IDE,
framework etc... (anche se M$ ama mettere estensioni per windoz :(
Ovviamente non ci sarà compatibilità tra un progetto per C++ Builder e uno
per Visual C++, ma almeno si è sicuri che un sorgente scritto in C++
standard girerà ovunque.
Ma B.S. e/o la AT&T non potrebbero ricorrere ad una soluzione per
standardizzare i compilatori esistenti? Cioè, ogni compilatore che compila
C++, deve essere 100% compliant, se no non deve spacciarsi per compilatore
C++, pena: qualche ricorso legale, sempre che B.S. e/o AT&T abbiano questo
genere di diritti sul C++. O forse, è stato proprio B.S. ad appoggiare
l'esistenza di questa giungla di compilatori, affinché C++ si diffondesse a
macchia d'olio?
--
Luigi
--
void f (OS x) {while (x.getbugs() > 0); destroy(earth);};
f (windows); // Meno male!

 macchia d'olio?
Il C++ si è diffuso a macchia d'olio *sopratutto* perchè è un grande 
linguaggio, non perchè esistono 100 compilatori! E non hanno nessun 
diritto legale, ci mancherebbe solo un copyright sul C++!!
-- 
Andrea Bergia - studente
Linux Registred User #281550

 diritto legale, ci mancherebbe solo un copyright sul C++!!
In questo caso non intedevo che AT&T dovesse avere percentuali o roba simile
su ciò che proviene dal C++, ma piuttosto il potere di non permettere la
diffusione di materiale scadente.
Ciao
--
Luigi

 diffusione di materiale scadente.
Un programma per computer è come un programma per TV: se non ti piace non lo
guardi/non lo compri.
A me sembra che ci siano ottimi compilatori in giro e che non manchi la
scelta sia a chi si vuole rivolgere a prodotti commerciali oppure a
compilatori open source.
Io non la vedo nera come la vedi tu!
Paolo Ferraresi.

 Io non la vedo nera come la vedi tu!
Infatti, io vedo il problema da un punto di vista più critico proprio perchè
chiedo di passare dallo (1) stadio di "compilatori di ogni tipo, con
percentuale variante di conformità" allo (2) stadio di "compilatore unico,
100% compliant". Ovvio che lo stadio (1) è sufficiente per ciò di cui ha
bisogno un programmatore, ma IMHO, è altrettanto vero che lo stadio (2)
sarebbe anche meglio.
Ciao
--
Luigi

 Io non la vedo nera come la vedi tu!
Infatti, io vedo il problema da un punto di vista più critico proprio perchè


Scusa il doppio post!
Ciao
--
Luigi

 problema d'incompatibilità (con lo standard) hai avuto?
	Gli aspetti "non rispettosi dello standard" del g++ sono segnalati nella
faq al sito 
gcc.gnu.org
 . Di veramente "grave" c'e' la mancanza della
keyword "export", ma pare che sia di difficile implementazione e mi sa che
attualmente non e' supportata da nessun compilatore.
	Giusto per precisare, per il resto sono d'accordo con te.
_dave_

 Lavora al laboratori AT & T.
	Per pura curiosita': adesso ha accettato un lavoro come professore in
un'universita' del Texas.
_dave_

 stadio (2) sarebbe anche meglio.
	Ti sfugge un dettaglio: SUN ha potuto farlo con Java perche' il suo
"compilatore" produce byte code. Il C++ non e' mica stato scritto per
l'Intel, il povero Bjarne dovrebbe scrivere un compilatore per ogni
architettura esistente! Inoltre non vedo perche' ti piace l'idea del
compilatore *unico*: capisco che tu voglia che tutti i compilatori
rispettassero lo standard al 100% (chi non lo vorrebbe), ma ci sara'
comunque spazio, su ogni piattaforma, per compilatori diversi,
ottimizzazioni differenti, ecc. ecc.
_dave_

 ha scritto nel messaggio
news:50tf9.9525$6O4.1...@twister1.libero.it...
cutto su tutto il messaggio, per mettere qualche commento sparso...dal basso
delle mie scarse conoscenze in proposito!!
rigurdo al gcc, questo è stato sviluppato per creare un compilatore
opensource portabile...nel senso che hanno risolto il problema della
portabilità del codice rendendo portabile il compilatore. ovviamente imho, e
ovviamente non basta il compilatore per far funzionare il codice su
architetture o OS diversi da quelli per il quale è stato scritto.
per quanto riguarda la babele di compilatori c che ci sono in giro per il
mondo, penso che così, a naso, tutti i compilatori arrivino fino ad un certo
punto ad avere le stesse caratteristiche. ovvero, se un programmatore è,
diciamo, non professionista, userà funzioni standard supportate grossomodo
da tutti i compilatori.
se invece è un programmatore esperto ad avere bisogno di un compilatore, non
avrà problemi a scegliere il compilatore che meglio risponde alle sue
esigenze di efficienza e portabilità.
se uno scrive codice per linux, senza avere intenzione di portarlo su
windows, per esempio, potrà sfruttare a pieno le funzionalità di gcc, senza
preoccuparsi che alcune features non siano supportate da ambienti ms
in poche parole, ad ognuno il suo!
ciau!
Raffaele

 Lavora al laboratori AT & T.
E' stato assunto come full professor al C.S. Dept. della Texas A&M ...
Negli States, diversamente dall'Italia, pagano bene gli universitari e
finanziano bene la ricerca in ambito universitario.
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Dept. of Physics, Univ. of Padova, Italy          loreti at pd dot infn dot it

 finanziano bene la ricerca in ambito universitario.
La fine di un'epoca...
Ciao,
Nicola

 farlo, ma rende il codice non portabile.
Compila con -W -Wall e avrai il tuo bel warning. Poi se vuoi elimarlo o 
lasciarlo è affar tuo... Io preferisco sempre eliminarli tutti.


 lasciarlo è affar tuo... Io preferisco sempre eliminarli tutti.
Già, ma non tutti la pensano come te.
Ciao
--
Luigi

 ottimizzazioni differenti, ecc. ecc.
Esatto, il problema č proprio questo.
Ciao
--
Luigi

 un'universita' del Texas.
Wow, immaginate BS come docente di programmazione che spiega C++ :D ?
Ma sarebbe veramente obbiettivo? :D (a parte questo, credo sia fantastico :)
Invece immagino se accettasse lavoro in qualche università qui in Italia...
magari gli studenti più presuntosi (A e B) discutendo:
A: "Ma lo sai che il nostro Prof. di C++ è un certo Stroustrup..."
B: "Ah, ci mancava lo straniero... speriamo che capisca qualcosa di C++"
--
Luigi

Luigi wrote:
[SuperSnip]
Mah, non credo che il problema dell'aderenza
allo standard sia dovuto tanto alla mancanza di un compilatore
conforme al 100%, anche se ha il su forte peso.
IMHO molto spesso il problema sta dall'altra parte
della tastiera ;-).
Quante librerie ci sono in giro che per svariati e
poco giustificabili motivi non usano i templates
o la libreria standard per i containers e le stringhe ?
Basta dare un'occhiata anche ai post su questo NG.
Mi sento dire da gente che programma da 20 anni che tanto C e C++
sono la stessa cosa : "Perchè il C++ ha solo le classi in più".
Fa un pò te, qual'è il livello di preparazione e conoscenza.
Poi c'è chi apparentemente fa di tutto per non aderire allo
standard introducendo estensioni proprietarie che non fanno altro
che portare ad ulteriore frammentazione (RogueWave per dirne uno).
Non credo che valga la pena ripartire da zero per creare un compilatore free
100% standard compliant. GCC di Gnu, come è già stato osservato,
è molto vicino e gli sforzi in questi anni sono stati proprio indirizzati
in questa direzione quindi mi sembra assurdo "reinventare la ruota".
-- 
SpeedTech
http://www.speedtech.it

 in questa direzione quindi mi sembra assurdo "reinventare la ruota".
Infatti, se GCC arriverà al 100% della conformità, ben venga. Io dico di
eliminare quelle ruote piene di angoli che non rotolano :D
Ciao
--
Luigi

 ha scritto nel messaggio
news:HU5g9.1759$eG6....@twister1.libero.it...

A parer mio sarebbe un grosso errore.
Lo standard, rimanendo sul tuo esempio, puo' essere inteso come "ruota
perfetta", ma
l'obiettivo principale del C/C++ e' sicuramente la versatilita'.
Se da un lato la "ruota perfetta" gira dappertutto, ci saranno spesso casi
dove si vuole una
ruota di altro materiale, o coi tasselli diversi, per andare su terreni
diversi.
E chi ti vieta di usare una ruota ellittica? Al limite anche quadrata?
Non e' piu' una ruota dici?
Vuol dire che funzionera' solo dove funzionano le ruote quadrate, ma
funzionera' e fara' il suo compito,
magari meglio della ruota rotonda in quel particolare caso e anche se solo
in quello.
E' solo un punto di vista relativo, ovviamente, e l'esempio e' un po'
estremo, ma spero di aver reso l'idea di quello che intendo.
un saluto a tutti :)
Joshi

 l'obiettivo principale del C/C++ e' sicuramente la versatilita'.
Ma, IMHO essere il piu` aderenti possibile allo standard porta al grande
vantaggio della portabilità e conseguente possibilita` di riutilizzo
del codice sotto altre piattaforme.
Consente inoltre ai programmatori di parlare "una lingua comune" ed
avendo ingoblato ormai da anni la libreria STL nel suo standard,
ci garantisce una solida base per sviluppare gli algoritmi
piu` critici.
Personalmente cmq sento la mancanza di una libreria standard
per tutte le altre necessita` pratiche : FTP, Mail, HTTP, 
e via dicendo, come in Ruby per intenderci. 
-- 
SpeedTech
http://www.speedtech.it

 E chi ti vieta di usare una ruota ellittica? Al limite anche quadrata?
il gcc, una ruota? ma che ruota e ruota, è un CINGOLATO!
hehe!!
Raffaele

 etc... (anche se M$ ama mettere estensioni per windoz :( 
Estensioni per windoz? Spero *vivamente* che tu non parli delle API per 
programmarlo... :-)

 Esatto, il problema č proprio questo.
A questo punto chiedo: posso vedere un esempio *reale* di codice C++ che 
evidenza un differente comportamento fra compilatori?
Sto cominciando a sospettare che stiamo parlando di cose che non 
c'entrano nulla con il linguaggio... 

 gioco, sfoggiando il suo JDK) 
Java non è un esempio calzante. In primo luogo, ci sono vincoli legali 
perchè java è tm (e non è proprio il suo miglior pregio). In secondo 
luogo, java non è solo linguaggio ma un ambiente (o virtual machine) e il 
suo SDK. La differenza è *sostanziale* perchè le tante librerie associate 
non sono paragonabili alle librerie standard ma sono delle API di questo 
ambiente.

 c'entrano nulla con il linguaggio...
Prendi un compilatore, scrivi un programmino basandosi su le estensioni
offerte dal compilatore, e compila il codice con un'altro compilatore che
non supporta queste estensioni.
Ciao
--
Luigi

 ambiente.
E se quando viene implementato il compilatore, le librerie venissero scritte
per lavorare sul sistema operativo come le API di Java lavorano sulla
macchina virtuale?
Ciao
--
Luigi

 programmarlo... :-)
Direi di si invece, visto che mi riferisco alle estensioni di M$ per windoz.
Del resto, se M$, Borland, etc... vogliono "potenziare" i loro compilatori,
ok... ma almeno supportare lo standard! Le estensioni, dopo!
ciao
--
Luigi

 windoz.
Le API non sono "estensioni", come non lo sono le librerie e i framework
che un ambiente di sviluppo può implicitamente offrire. Voglio dire, non
ha senso chiamare queste cose "estensioni".
Normalmente, invece, con "estensioni" si intendono costrutti del
linguaggio o comportamenti documentati che non sono previsti dallo
Standard.
Ad esempio, la possibilità di avere array nello stack di dimensione
definibile a run-time è un estensione del GCC, che non è prevista nel
C++89. Keyword come "__property" sono estensioni del Managed C++ di MS. Il
fatto che una divisione per zero produca un'eccezione gestibile via
try/catch è un'estensione di VC, in quanto lo Standard prevede soltanto un
comportamento indefinito.
Max

 C++89.
Ehm, ovviamente intendevo "C++98".
MM

 dopo! 
Ok, adesso vedo nomi e cognomi. Visto che ho a portata di mano il MS 
Visual Studio, sono curioso di avere un esempio di codice C++ standard 
che non riesco a compilare.

 compilatore che non supporta queste estensioni.
Beh, per quello che tu intendi per "estensioni"... 
Credo di aver già detto abbastanza a proposito, dovrei ripetermi (e 
ripetere ciò che hanno detto altri).

 lavorano sulla macchina virtuale?
E' esattamente quello che avviene per le librerie standard...

 questo compilatore produce magicamente codice per windows?
Lo so che non può direttamente generare codice per windows, ma che tipo di
modifiche sono necessarie?
Ciao
--
Luigi

 E' esattamente quello che avviene per le librerie standard...
Allora perchè dicevi:
"java non è solo linguaggio ma un ambiente (o virtual machine) e il
suo SDK.
La differenza è *sostanziale* perchè le tante librerie associate
non sono paragonabili alle librerie standard ma sono delle API di questo
ambiente".
Anche se lavorano sulla JVM, tramite esso lavorano sul sistema operativo no?
ciao
--
Luigi

 che non riesco a compilare.
Beh, intato prova l'esportazione dei template :D
Poi mi pare che ultimamente c'era stato un thread in merito ai livelli
d'accesso per i membri da una classe base a una derivata, non ricordo
adesso. Oppure lessi tempo fa un thread dove c'era incompatibilità anche per
la gestione delle eccezioni (per quanto riguarda la dicharazione delle
eccezioni che la funzione può lanciare).
Ciao
--
Luigi

 tipo di modifiche sono necessarie?
Modifiche sostanziali.

 Allora perchè dicevi:
Perchè sono due risposte a due domande diverse!

> Perchč sono due risposte a due domande diverse!
Tu avevi detto che non era possibile paragonare le librerie del C++ alle API
di JAVA perchč sono API fatter per SDK.
Io ho risposto che basta pensare alle librerie del C++ implementate per
funzionare su un OS e alle API implementate per girare sul SDK, e il
paragone si potrebbe fare.
Tu hai detto che č cosě che vengono implementate le librerie.
Forse continui a dire che il paragone non č fattibile perchč per funzionare
su piů OS le librerie e il compilatore devono essere sottoposti a
sostanziali modifiche?
Ciao
--
Luigi

 sottoposti a sostanziali modifiche?
No, sostengo che una libreria deve essere disponibile per quella 
piattaforma a differenza di java dove non è necessario. Che il porting 
sia trasparente, comporti delle modifiche o sia impossibile dipende dalla 
libreria e cosa contiene... 

Ok, grazie.
ciao
--
Luigi

 che non riesco a compilare.
for(int i=0; i<10; i++)
        ;
int i = 10;
Non so se hanno corretto questo bug in VC++ 7, ma fino alla versione 6 
questo codice non compilava.
ciao Anto
-- 
"Computer science is not about computers any more than astronomy
is about telescopes." -- EW Dijkstra

 questo codice non compilava.
Fortunatamente sě.
-- 
Andrea Bergia - studente
Linux Registred User #281550

ma fino alla versione 6 questo codice non compilava.
Mi risulta pero' che con questa variante:
if (1) { for (int i=0;i<10;i++) ; }
int i=0;
compili da ogni parte. O sbaglio?
Joshi

 questo codice non compilava.
Si lo compila.

 int i=0;
Questo non importa. Se č standard, il compilatore deve compilare senza
apportare modifiche al codice.
Ciao
--
Luigi

 B: "Ah, ci mancava lo straniero... speriamo che capisca qualcosa di C++"
Il mio profe non lo conosce *veramente* il C++!!! Eppure è barese
purosangue... Datemi Stroustrup!!! (in subordine mi accontento anche
di K&R... uno l'altro o tutti e due ;o)