Newsgroup: it.comp.lang.c++
Titolo: STL che passione...se funzionassero...

Salve a tutti,
come si capisce dal topic ho qualche problema con le stl e anche
guadando la documentazione fornita col Visual C++ 5.0 non sono
riuscito a trovare una soluzione...
Il problema č che quando vado a compilare una classe  che contiene un
membro di tipo std::list<MYSTRUCT> mi da un sacco di errori come "non
riesco a trovare un metodo per fare T__ < V__" ...insomma mi dice che
mancano un sacco di operatori... mi č venuto il dubbio che dovessi
definire io tali operatori ma ho pensato che una classe stl non
potesse essere cosě "cattiva" da farmi fare tutto stň lavoro...
Insomma devo definire tutti i metodi id confronto assegnazione ecc...
o ho tralasciato qualcosa???
Visto che ci sono mi sapreste indicare dei link e/o libri di
riferimento per stl?
Grazie a tutti!
Francesco Pischedda
Coder - Siderion


Nel sito dove trovi Thinking in C++ c'e' anche un brevissimo tutorial
alle STL,
che io trovo molto carino.

riferimento per stl?
Vedi faq su 
www.programmazione.it
Paolo
--------------------------------------------------
  Paolo Marotta
  Computer Science, University of Pisa
  home:   
http://www.cli.di.unipi.it/~marotta
--------------------------------------------------

 
Per qualche ragione, mi ero convinto che questo requisito (definzione di
operator<) esistesse soltanto per quei container che contemplassero un
parametro con funzione di comparatore (tipo std::map, per intenderci, che
ha una classe "funzionale" come terzo parametro, con default less<T>).
Per questa ragione mi aspettavo che std::list, che mi risulta prevedere
soltanto i parametri relativi al tipo e all'allocator, non esigesse
l'esistenza di operator<. In effetti con il gcc riesco a creare oggetti
list<T> di classi prive di quell'operatore.
Max

list<T> di classi prive di quell'operatore.
Serve perche` se non erro std::list possiede un metodo per il
sorting della lista (oppure e` una feature di qualche compilatore?).


--------------------------------------------------
Francesco Pischedda
Coder - Siderion

 sorting della lista (oppure e` una feature di qualche compilatore?).
No, e' standard (ISO 23.2.2.4).  Garantita stabile e N*ln(N).  Usa
operator < o una funzione fornita dall'utente.
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

 sempre -1 in ogni caso e mi levo il problema...
Visual C++ 5.0 aveva questa deviazione dallo standard che gli faceva
"compilare" metodi template non istanziati (cosa che un compilatore
conforme non deve fare). Questa cosa, descisamente scomoda e i cui
effetti sono quelli descritti, e' stata per fortuna rimossa nella
versione 6.0sp3.
Ovviamente questo orrore era venduto (nella documentazione VC++5) come
"feature".
Non e' comunque buona cosa usare VC++ 5.0 con STL in quanto mi e' stato
riferito di altri problemi piu' subdoli nell'implementazione (compresi
crash usando std::string in modo lecito).
Restano alcune deviazioni dallo standard anche nel VC++6 (es. new non
genera bad_alloc ma ritorna NULL) ... speriamo per il futuro.
----------------------------------------------------------------
 <\___/>  Andrea        email: agriff at tin dot it
 / . . \  "6502"          irc: _6502_@EFNET#italia
(  (")  ) Griffini   homepage: 
http://www.netservers.com/~agriff
Sent via Deja.com 
http://www.deja.com/
Before you buy.

 
Non mi è chiara una cosa. Il problema iniziale riguardava la mera
instanziazione di un list<T> o l'uso del metodo sort?
Il gcc riesce a instanziare list<T> con T privo di operator<, diversamente
a quanto accade, ad es, con map<T>.
Prevedibilmente, se il codice contiene un riferimento a list<T>::sort(),
la compilazione non va a buon fine. Evidentemente il compilatore non
tenta di instanziare tutti i metodi se questo non è necessario.
Mi chiedo: è standard questo comportamento? Se lo è, un compilatore non
può pretendere la definizione di T::operator< per instanziare un list<T>.
Max

 conforme non deve fare). 
Ah, questo risponde implicitamente alle perplessità che ho espresso nel
mio precedente post. Grazie.
Max

 pu=F2 pretendere la definizione di T::operator< per instanziare un list<T>.
Lo e'.  *Sarebbe* richiesta la definizione di operator< solo se tu
volessi usare metodi che lo richiedono; ma il compilatore di chi ha
fatto la domanda non si comporta cosi'.
Ecco un esempio corretto: (g++ 2.95.2 con libstdc++ 2.90.8): il
programma
#include <iostream>
#include <list>
using namespace std;
class quux {
  private:
    bool operator< (const quux &);
  public:
    int a;
    quux(const int A = 0) throw() : a(A) {};
};
int main() {
  list<quux> l;
  l.push_back(666);
  l.push_back(42);
  for (list<quux>::const_iterator i=l.begin(); i!=l.end(); i++)
    cout << i->a << endl;
}
usa una classe con operator< privato (e mai definito); g++ compila il
tutto senza una piega e stampa 666 e 42 in successione.  Invece, se
metti un l.sort(); dopo l'ultimo push_back e prima del for, sputa
fuori:
/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-v3/bits/stl_list.h: In method `void std::list<quux,std::allocator<quux> >::merge(std::list<quux,std::allocator<quux> > &)':
/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-v3/bits/stl_list.h:765:   instantiated from `std::list<quux,std::allocator<quux> >::sort()'
foo.cxx:18:   instantiated from here
foo.cxx:8: `bool quux::operator <(const quux &)' is private
/usr/local/gcc/lib/gcc-lib/i686-pc-linux-gnu/2.95.2/../../../../include/g++-v3/bits/stl_list.h:726: within this context
e muore miseramente.  Lo Standard (17.3.1.3) si riserva di specificare
per ogni metodo "... Requires: the preconditions for calling the
function"; e poi (23.2.2.4) "void sort(); template <class Compare>
void sort(Compare comp); Requires: operator< (for the first version)
or comp (for the second version) defines a strict weak ordering."


sempre -1 in ogni caso e mi levo il problema...
Ho avuto un problema simile con delle classi per le quali non era lecito
definire un costruttore di default, e come nel tuo caso un operatore
di confronto. Ho risolto utilizzando il contenimento indiretto
(memorizzo cioe` puntatori agli oggetti), anche in considerazione
del fatto che gli oggetti sono tutti allocati e costruiti a run time.
Ritengo che questo problema sia uno dei limiti della GP, d'altronde
se esistesse un approccio universalmente valido, non avremmo
un C++ multiparadigma.


 wrote in message
Pine.LNX.4.10.100041...@c64.comm2000.it...
    [snip]
Il gcc riesce a instanziare list<T> con T privo di operator<, diversamente
a quanto accade, ad es, con map<T>.
Prevedibilmente, se il codice contiene un riferimento a list<T>::sort(),
la compilazione non va a buon fine. Evidentemente il compilatore non
tenta di instanziare tutti i metodi se questo non è necessario.
Mi chiedo: è standard questo comportamento? Se lo è, un compilatore non
può pretendere la definizione di T::operator< per instanziare un list<T>.
Si`, pienamente standard.  Vecchi release di vari compilatori
C++ avevano questa limitazione (richiedere operator< per le
list, ecc), ma lo standard non l'ammette e i release recenti
sembrano avere obbedito.
Alex

versione 6.0sp3.
Esiste anche un sp3 per VC++5.0, downoladabile gratuitamente (ma assai
pesante, saranno 40M), che risolve questo problema.
== Aldo Brucale =====================================