Newsgroup: it.comp.lang.c++
Titolo: La tesi naufragante è stata soccorsa !!!

Questo messaggio è in realtà un pubblico grazie da parte mia a tutti coloro
hanno partecipato alla discussione che io ho "virtualmente" intavolato,
titolo "Tesi in Naufragio" !!!!
Grazie ad Andrea Griffini, Nicola Musatti, Enrico Maria Giordano, Manlio
Perinlio, che mi hanno risposto più volte, anche privatamente, mostrando una
pazienza enorme, nonchè, ma di questo voi del NG già ve ne siete accorti, un
livello di preparazione notevole, ma anche a Max M., che credo sia stato
l'unico a vederci su una cosetta... in pratica il Borland, non aderendo
perfettamante allo standard nell'implementare la STL richiede
obbligatoriamente che siano implementati gli operatori < ed == per gli
elementi memorizzati nella lista.
Sicchè anche se creo una
std::list<Patate> stupida_lista;
devo (anche se è una cosa logicamente priva di senso) definire degli
operatori < ed == per Patate.... cose allucinanti !!!!!!!!   (P.S. Non ho
niente contro le patate !!!)
Quindi, riassumendo, dopo aver aggiunto, come funzione inline, le seguenti
righe di codice all'interfaccia della classe sack_list_element, le cui
istanze sono gli oggetti memorizzati nella lista contenuta in ogni istanza
della classe Sack_pac (Per gli addetti ai lavori si sa di cosa stò
parlando...... li ho fatti vomitare e spazientire abbastanza con le mie
insistenti richieste) si è risolto il problema di assurdi Errors che non
sapevo spiegarmi.
Le righe "magiche" sono state:
------------In sack_list_element.h------------
bool operator==(const Sack_list_element&){
                  return(true);}
            bool operator<(const Sack_list_element&){
                  return(false);}
----------------------------------------------
Dopo questa correzione, per zittire il compilatore, si manifesta una lista
di warnings, che credo non dovrebbero preoccuparmi più di tanto, e che vi
riporto in calce:
Warn :  list.h(676,1):Condition is always true
Warn :  list.h(691,1):Condition is always true
Warn :  list.h(693,1):Unreachable code
Warn :  list.h(708,1):Condition is always false
Warn :  list.h(710,1):Unreachable code
Una cosa ancora. Ho postato un messaggio analogo a quelli che avevo inserito
in questi giorni su questo NG anche su comp.lang.c++ (no, non ho dimenticato
it... ma è proprio quello in Inglese).
 Ebbene, due persone diverse hanno concordato entrambe sulla soluzione
propostami da Max M.
Bye,
Sebastiano.
P.S. Che ne pensate ??
Mi piacerebbe che la discussione in merito allo standard continuasse, ed in
particolare se mi conviene definitivamente abbandonare il Borland per
passare ad un altro compilatore.

perfettamante allo standard nell'implementare la STL richiede
Attento al fatto che la STL NON e' la libreria standard.
Sono due cose ben distinte, che vivono di vita propria, ormai.
--
Andrea Laforgia (
andrea_...@bigfoot.com
)
--------------------------------------------------------------
"Partire e' un po' morire e morire e' partire un po' troppo !"
--------------------------------------------------------------

 elementi memorizzati nella lista.
Scusa, non ho capito bene. Il seguente programmino viene compilato
perfettamente dal Borland C++ 5.5:
#include <iostream>
#include <list>
#include <cstdlib>
using namespace std;
class A
{
    public:
        A(): n( rand() ) {}
        int getN() const { return n; }
    private:
        int n;
};
int main()
{
    list < A > l;
    for ( int i = 0; i < 10; ++i )
        l.push_back( A() );
    for ( list < A >::const_iterator i = l.begin(); i != l.end(); ++i )
        cout << i -> getN() << endl;
}
Ho capito male io il problema che esponevi?
EMG

Perdona eventualmente le fesserie che potrei ora scrivere... ma tu nel
"programmino" che mi mostri non memorizzi interi nella lista? Se è cosi su
questi è definito un ordinamento, dove l'operatore < ed == hanno un senso
logico.
Il mio problema, che pare essersi risolto, è dovuto al fatto che nella lista
memorizzo oggetti in generale (nel mio caso si trattava di istanze di una
classe le cui variabili membro sono due Unsigned long int ed un double),
quindi puoi vedere ciò che è memorizzato in questa lista come delle
"struct", su cui mica è definito un ordinamento!
Esempio stupido:
list<ack_packet> lista_ack;
dove
class ack_packet{
                        double time_to_live;
                        double time_tx,time_rx;
                        unsigned long int id_ack;
                        /....../
                       public:
                       ack_packet(double,int,int);
                       void Set_time_to_live(void);
                       /..../
                      };
Per due istanze di ack_packet non ha senso dire ack_1< ack_2, oppure ack_1
==ack_2.... almeno normalmente non dovrebbe averne di senso.
Come faccio a definirne un ordinamento? In base a cosa? La risposta è che
non c'è nessun ordinamento.
Basta pensare all'esempio dei numeri complessi, su cui non è possibile
definire alcun ordinamento, e, volendo, ogni numero complesso lo posso
pensare come una istanza di una classe Numero_complesso.
Definendo un operatore overloaded < ed uno == frego invece il compilatore
del Borland, che si aspetta ancheper le liste che siano definiti questi
operatori (forse).
Fatto stà che da quando ho aggiunto le "righe magiche" il problema di prima
è scomparso.
Bye,
Sebastiano

Questo significa che andava fatta quella "manovra" per aggirare l'ostacolo?

 logico.
Rispondevi a me? Se si, io nella lista memorizzavo oggetti di una certa
classe A, non interi.
EMG

 pensare come una istanza di una classe Numero_complesso.
Al volo mi vengono in mente almeno due tipi di ordinamento possibili. Se
A={x1,y1} e B={x2,y2} sono numeri complessi posso definire un
ordinamento lessicografico:
A>B iff x1>x2 or x1=x2 and y1>y2
Oppure:
A>B iff x1^2+y1^2 > x2^2+y2^2
Ciao,
Nicola


Probabilmente stai usando il 'vecchio' Borland C++ 5.02.
Ho provato anche io e mi da gli stessi problemi.
In effetti, coma ha detto Max M., tale comportamento non è conforme allo
standard (a meno che, ovviamente non stai chiamando delle funzioni che richiedono
un ordinamento).
Prova con il Borland C++ 5.5 (lo puoi scaricare gratis dal sito della Borland, sono circa
7.976 KB).
Anche il DJGPP non da questo problema.
Per precauzione ti consiglio ti fare una cosa del genere:
    bool operator<(const Sack_list_element&)
   {
      assert(false);
      return false;
   }
In questo modo risulta più charo che Sack_list non ha ordinamento e che tale
funzione è messa solo per compatibilità.
Manlio Perillo

Per contro, visto che hai dovuto scriverlo, tanto vale che definisci:
bool Sack_list_element::operator == (const Sack_list_element & rhs)
{
  return this == &rhs;
}
Ovvero due Sack_list_element sono uguali se e solo se coincidono.
Ciao,
Nicola

Si, ma in matematica non è definito !!!

Thank you  everybody!!!
Siete mitici !!! Tutti quanti...

Una cosa, ma il 5.5 non è il C++ Builder?
Se lo è non è un pochino diverso?
Bye,
Sebastiano


Il BCC 5.5 è il solo compilatore a riga di comando che la Borland offre gratis.
(In più ci solo altri tools come il Turbo Debugger, il Turbo Lib sempre a riga di comando).
Manlio Perillo

 wrote in message 39AA1C99...@divalsim.it...

Io preferisco l'uso di assert in quando esprime 'a vista' che l'ordinamento non ha senso.
E' anche più chiaro per chi deve leggere il programma (almeno a mio avviso).
Nel caso di Sebastiano questo è importante in quanto il programma in questione
gli serve per la tesi.

Nel caso dell'ordinamento non ho particolari obbiezioni, anche se in
generale non sono un grande fan dell'assert. Nel caso del confronto di
uguaglianza tanto vale implementarlo effettivamente, visto che la
definizione in base all'identita' e' sempre valida.
Ciao,
Nicola

 wrote :
| Si, ma in matematica non è definito !!!
mmm. non e' definito l'operatore <, pero' il != si.
inoltre ponendo due numerazioni su N come coppia, e mettendoli in relazione
0,0 0,1 0,2 ...
1,0 1,1 1,2 ...
2,0 2,1 2,2 ...
.   .   .
.   .   .
.   .   .
e prendeno le diagonali 0,0 1,0 0,1 2,0 1,1 0,2 .... possiamo ordinare
almeno i complessi interi. basta estendere il concetto ai complessi
compresi tra due complessi successivi nella nostra numerazione, e sei a
cavallo :) ( peccato che siano aleph(1) )

 Se lo è non è un pochino diverso?
Dovrebbe essere solo il compilatore a linea di comando senza l'ambiente
visuale.
EMG

 wrote in message 39AA4A26...@divalsim.it...

Io infatti ho usato assert solo per <.
Manlio Perillo

Te la stai inventando tu questa....
citami una fonte in cui si dice che il corpo dei complessi č un insieme
ordinato e cambio opinione (Ehi, si tratta solo di una amichevole
controbattuta.. non voglio fare il polemico, anche perchč su certe cose non
me lo posso permettere)
Per definizione il corpo dei complessi non ammette operatori relazionali !!!
Si possono confrontare i moduli, le parti reali... tutto quello che vuoi, ma
č solo una convenzione stabilita da te.
Comunque, ritornando alla traccia originale (finiremmo per parlare di
matematica alla fine), il problema che ho avuto, a cui, ripeto , tutti avete
gentilmente collaborato alla sua soluzione, pare sia un bug del Borland
5.02, tanto piů che io ho una versione presa da una rivista.
Bye,
Sebastiano

 wrote:
| Te la stai inventando tu questa....
Emm, non hai visto lo :-) in fondo...
si possono ordinare solo i complessi con valori interi (arbitrariamente,
certo).