Newsgroup: it.comp.lang.c++
Titolo: Compilatore veramente standard: quale scegliere?

Dopo tante tribolazioni, ho *quasi* deciso di mettere via il VC++ per
passare a un compilatore che non mi costringa a programmare male perché
possa compilare. Vorrei un compilatore che aderisca il più possibile allo
standard, ma che compili eseguibili WIn32. Inoltre presto mi potrei trovare
nella necessità di fare un porting verso Linux/Unix, e quindi pensavo a un
prodotto gnu. Solo che per lavorare non bastano editor e capacità, serve
anche un ambiente che offra un serio sistema di help, un project manager in
grado di gestire progetti molto strutturati, un class browser che faccia
ciò che deve fare, e un sistema di sviluppo visuale. 
Qualcuno ha avuto modo di lavorare con qualche IDE che si appoggi magari su
compilatori standard (es. gnu)? Se si quale?
Vedo che diverse persone di questo NG usano il djgpp. Non capisco quale
mercato possa interessare la piattaforma DOS, tuttavia questo fatto mi fa
pensare che per questo compilatore esista per lo meno un sistema di help in
linea... che so: <SHIFT+F1> alla Norton Guide (eh... buon vecchio Clipper!!
:)
<Nota>
Io utilizzo ancora VC++ 5.0 (no service pack, STL proprietaria), e non ho
mai provato la versione 6.0, perciò non so se MS ha risolto almeno qualche
problema di compatibilità (o se ha invece deciso di allontanarsi per sempre
dallo standard). Se c'è qualche volenteroso difensore dei poveri e degli
oppressi, vorrei invitarlo a compilare questo codice ANSI con il proprio
fedele compilatore, per poi raccontare com'è andata, e gliene sarò
eternamente grato. 
Il compiler va in crisi nella funzione binder di oggetto funzione
<mem_fun_ref> , che effettivamente usa delle caratteristiche tra le più
avanzate del linguaggio. 
//////////////////////////////////////////////////////////////
// Tratto da "Tinking in C++" - Bruce Eckel
//
//: C21:MemFun2.cpp
// Applying pointers to member functions
#include <algorithm>
#include <vector>
#include <iostream>
#include <functional>
using namespace std;
class Angle {
  int degrees;
public:
  Angle() : degrees(0) {} //aggiunto io per compatibilità con VC++
  Angle(int deg) : degrees(deg) {}
  int mul(int times) {
    return degrees *= times;
  }
};
int main() {
  vector<Angle> va;
  for(int i = 0; i < 50; i += 10)
    va.push_back(Angle(i));
  int x[] = { 1, 2, 3, 4, 5 };
  transform(va.begin(), va.end(), x,
    ostream_iterator<int>(cout, " "),
    mem_fun_ref(&Angle::mul));
  cout << endl;
} ///:~
Intanto grazie, e aspetto notizie :)
Roberto Cavada

>     mem_fun_ref(&Angle::mul));
Il mio VC++ 5.0, non patchato, si arrabbia parecchio.
--
Alessandro Monti

 eternamente grato.
Il mio DJGPP lo digerisce perfettamente stampando come risultato
0 20 60 120 200
EMG

Si incazza anche il VC6.0, SP3:
error C2784: 'class std::mem_fun_ref_t<_R,_Ty> __cdecl std::mem_fun_ref(_R
(__thiscall _Ty::*)(void))' : could not deduce template argument for
'<Unknown>' from 'int (__thiscall Angle::*)(int)'
Ciao,
Gianfranco

]

 eternamente grato.
egcs 1.1: dopo aver corretto la libreria (quasi) standard,
compila perfettamente.
Il problema e' la SGI STL definisce le funzioni  mem_fun1_ref
invece di  mem_fun_ref  per i metodi con un argomento. Forse
si basa su una versione precedente dello standard (oppure si
sbagliano Eckel e Stroustrup ma non penso).
Cambiando le dichiarazioni in stl_function.h (incluso da functional),
funziona tutto.
	Mauro

standard, ma che compili eseguibili WIn32.
CygwinB20 che e` il porting per windows dell'ottimo gcc 2.95 (il 
compilatore piu` standard attualmente in circolazione).
Unica nota dolente per le GUI devi affidarti ad altri, non fornisce sue
librerie e soprattutto niente editor visuale di risorse. Devi affidarti 
a prodotti di terze parti.
Per l'ide tra le faq in costruzione ne sono stati nominati diversi...
Paolo
-----------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
-----------------------------------------------

Infatti io non lo uso per sviluppare ma solo a scopo didattico.
Io solo per sviluppare.
Se uno vuole il programmino per giocare al lotto, e gli dici che in dos
spende la meta' (vero perche' io con winzozz faccio ancora a pugni).....
Marco

 
La Cygnus ha dei prodotti molto validi, sia per windows che per linux
http://www.cygnus.com
Io utilizzo il Source Navigator su Linux e mi trovo abbastanza bene.
Ultimamente e' uscito anche Code Fusion (non so se ne esiste anche una
versione per Windows)
*Fabio*
-- 
Hate is like acid.  It can damage the vessel in which it is stored as well
as destroy the object on which it is poured.

 Il gcc e' uno dei compilatori piu' standard che esistano.
Non tanto; manca il supporto per i namespaces, la stream library non
e' assolutamente standard.  I miei files sono pieni di cosine tipo
#ifdef __GNUG__; mai provato a dare in pasto un #include <sstream> o
un std::ostringstream s; a g++?
Se vuoi la vera portabilita', spendi qualche quattrino e vai per KCC;
e' l'unico che sia _veramente_ standard.  Esiste solo per piattaforme
serie, pero' :-)
http://www.kai.com/index.html
 ; ne vale la pena.  
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

 Se vuoi la vera portabilita', spendi qualche quattrino e vai per KCC;
Sono d'accordo.
EMG

un std::ostringstream s; a g++?
Non hai una versione molto recente. Oggi queste cose sono tutte a
posto.
Nota: e' un po' OT, ma forse interessa. Pare che RedHat sia
intenzionata a comprare la Cygnus. Se fosse vero, non vedo l'ora di
avere magari boundled con Linux il SurceNavigator... tutte le mie
esigenze da sviluppatore sarebbero accontetate :)


un std::ostringstream s; a g++?
strano a me non risulta... io ho provato gcc 2.95 e i namespace
sono supportati correttamente (almeno sembra).
D'altronde tempo fa ho visto codice standard che solo gcc attualmente
pare compilarlo (non disponendo di ogni possibile compilatore non
sono pero` disposto a metterci neanche una cellula sul fuoco).


 un std::ostringstream s; a g++?
No, perche' non ho un sstream da dargli in pasto (la
solita libreria non standard del gcc).
Pero' sono sicuro che lo compilerebbe senza problemi.
 
	Mauro

Non mi resta che ringraziare tutti... tutte le opinioni sono state davvero
utilissime!
Penso che il mondo Linux abbia fatto passi enormi da quando, dopo due mesi
di tentativi, qualche anno fa riuscivo ad installarlo! Ad esempio il
KDevelop mi sembra davvero un prodotto importante, come il cygnus e KCC,
del resto, che tra l'altro sono presenti per Win32 (NT, per lo meno). Ma in
questo caso, quali librerie vengono adottate per lo sviluppo (GUI, DB,
Thread, Network, ecc.) ?
Grazie.
Roberto Cavada

 posto.
Ho la 2.95.2 .  Ce ne sono di piu' recenti?
MLO@axcdf4 6 $ cat foo.cxx
#include <iostream>
#include <sstream>
int main()
{
  std::ostringstream s;
  int i(2);
  s << i << " al quadrato vale " << i*i;
  std::cout << s.str() << std::endl;
  return 0;
}
MLO@axcdf4 7 $ g++ -ansi -Wall -o foo foo.cxx
foo.cxx:2: sstream: No such file or directory
MLO@axcdf4 8 $ g++ --version
2.95.2
MLO@axcdf4 9 $ KCC -V -o foo foo.cxx
KAI C++ 3.3e (KCC) -- Sep 23 1998 -- (C) Copyright 1994-1998 Kuck & Associates, Inc.
MLO@axcdf4 10 $ ./foo
2 al quadrato vale 4


 sono supportati correttamente (almeno sembra).
Il fatto e' che specifiche tipo std:: o using namespace std; vengono
ignorate (leggi la documentazione).  Se usi -fhonor-std, che secondo
la documentazione stessa dovrebbe considerarle...
MLO@axcdf4 11 $ cat bar.cxx
#include <iostream>
int main()
{
  std::cout << "Hello, world" << std::endl;
  return 0;
}
MLO@axcdf4 12 $ g++ -fhonor-std -o bar bar.cxx
bar.cxx: In function `int main()':
bar.cxx:5: `cout' undeclared in namespace `std'
bar.cxx:5: `endl' undeclared in namespace `std'
MLO@axcdf4 13 $ g++ --version
2.95.2
MLO@axcdf4 14 $ KCC -V -o bar bar.cxx
KAI C++ 3.3e (KCC) -- Sep 23 1998 -- (C) Copyright 1994-1998 Kuck & Associates, Inc.
MLO@axcdf4 15 $ ./bar
Hello, world


 Pero' sono sicuro che lo compilerebbe senza problemi.
Vedi l'esempio gia' fatto per altra risposta.  Sei sempre cosi' sicuro?


 la documentazione stessa dovrebbe considerarle...
Veramente sulla mia documentazione (DJGPP) c'è scritto:
Does g++ support namespaces?
============================
   As of version 2.7.2, g++ recognizes the keywords `namespace' and
`using', and there is some rudimentary code present, but almost nothing
connected with namespaces works yet.  The new versions (2.8.x/egcs)
still lack namespace support, but to help compile standard programs
they make
     using namespace std;
   a no-op.  There is namespace implementation work going on in the egcs
snapshots (but it hasn't been released yet).
Però, come puoi notare, fa riferimento alle versioni 2.7.2 e 2.8.x.
Siamo sicuri che nella 2.9.5 ancora sia questa la situazione? Io avevo
provato tempo fa a creare dei miei namespaces e sembrava che li
riconoscesse regolarmente, non semplicemente come no-op. Posso
sbagliare...
EMG

 Vedi l'esempio gia' fatto per altra risposta.  Sei sempre cosi' sicuro?
L'amico Mauro però parla di compilatore. E' la libreria che non è ancora
aggiornata.
EMG

 sbagliare...
No, gli altri li riconosce; è il namespace std che viene ignorato (a
meno che non si dia l'opzione -fhonor-std, nel qual caso le librerie
sbagliate danno errore).
Che io sappia, una versione compliant della stream library, della STL
etc. dovrebbe arrivare con il prossimo gcc versione 3 (atteso per
qualche giorno della parte iniziale del nuovo millennio).
Per ora, dovendo fare dei programmi che girino sia su workstation che
su sistemi embedded (per cui non è disponibile altro che gcc), isolo
il codice critico in procedure a parte piene di #ifdef per riconoscere
il compilatore.


#include <sstream>
La libreria standard (c'e' la versione 3 in preparazione, forse gia'
anche usabile e 100% standard - e' da un po' che non controllo quindi
non so a che punto stia) non e' parte integrante del compilatore.
Quello di cui si deve occupare il compilatore e' tutto a posto (a
parte qualche baco minore); i namespace ad esempio adesso sono
riconosciuti benissimo.


 Vedi l'esempio gia' fatto per altra risposta.  Sei sempre cosi' sicuro?
Se non lo trova e' naturale che non lo compili.
Nella doc. del gcc (non mi ricordo dove) avevano
detto che se uno si fosse procurato una vera libreria
standard, il gcc l'avrebbe compilata.
Sarebbe interessante vedere cosa succede dandogli
in pasto la libreria del KCC (tutta, non solo sstream,
altrimenti ci sono problemi con gli altri stream non
standard).
	Mauro

 bar.cxx:5: `endl' undeclared in namespace `std'
Infatti le considera, e nota che la sua libreria non dichiara
cout ed endl nel namespace std.
Definendo __STL_USE_NAMESPACES in /usr/include/g++/stl_config.h
parte della libreria (non gli stream) viene dichiarata nel
namespace std.
	Mauro

 qualche giorno della parte iniziale del nuovo millennio).
Bene.
EMG