Newsgroup: it.comp.lang.c++
Titolo: STL e Microsoft

Già dopo la prima riga di codice mi sono accorto che l'ambiente MS non è
esattamente standard (vedi messaggio su scope),ma oggi ho provato ad usare
il tipo string e mi sono accorto con un po' di amarezza che, se ad esempio
uso il metodo string::find(), il valore ritornato è unsigned int, mentre mi
sarei aspettato un signed, dal momento che il valore di default se non c'è
l'occorrenza cercata è -1.
Questo comporta che al posto di -1 viene ritornato il valore 2^32-1.
Mi chiedo se sia una mia cattiva interpretazione oppure se l'implementazione
della libreria standard sia carente.
In questo secondo caso, esistono implementazioni con cui sostituire quella
di VisualC++?Quelle di SGI e STLPort sono buone candidate?
Ringrazio chi ha già risposto ai precedenti messsaggi e chi risponderà.
Alessandro Chiarini

 valore di default se non c'è l'occorrenza cercata è -1.
Per essere precisi la funzione find restituisce un valore di
tipo string::size_type, ed in caso non ci fosse alcuna
corrispondenza restituisce il valore speciale string::npos.
Ciao.
--
BSD is for UNIX-lovers -- linux is for Windows-haters.

di VisualC++?Quelle di SGI e STLPort sono buone candidate?
Anche quelle sono convinto usino degli unsigned
(purtroppo e' lo standard a richiederlo).
HTH
Andrea

l'occorrenza cercata è -1.
No, il compilatore della Microsoft ha le sue non conformità, ma su
questo si comporta in modo corretto.
Come ti ha già detto HPL, il tipo del valore di ritorno delle funzioni
membro find() di std::string é std::string::size_type, ed é buona
regola utilizzarlo quando si dichiara una variabile che deve contenere
il risultato di una di queste funzioni, in quanto il tipo effettivo
potrebbe variare da piattaforma a piattaforma(per esempio su alcune
potrebbe essere unsigned int , su altre invece unsigned long).
Secondo punto, non sta scritto da nessuna parte che il valore di
ritorno per una find() che non ha trovato nulla sia -1, lo standard
dice che il valore ritornato deve essere std::string::npos, chi scrive
il codice si deve solamente attenere a questa banale regola ignorando
l'effettivo valore di std::string::npos, in quanto lo standard ha
progettato queste funzioni in modo che i programmatori possano
utilizzarle senza arrovellarsi con i problemi delle conversioni di
tipo, e se tali problemi emergono significa che si sta sbagliando
qualcosa.
Ti posto un esempio di codice corretto che dimostra quello che ho
appena detto:
#include<string>
#include<iostream>
int main()
{
std::string a="CIPPA LIPPA";
std::string::size_type pos;
pos=a.find("PERO");
if(pos==std::string::npos)
	{
	std::cout<<"sottostringa non trovata\n";
	exit(0);
	}
std::cout<<"sottostringa trovata dalla posizione "<<pos<<"\n";
return 0;
}
questo codice cerca la sottostringa "PERO" su una stringa "CIPPA
LIPPA", e come puoi vedere in tale codice non si fa alcun riferimento
a variabili signed o unsigned( il codice ovviamente può essere
ulteriormente compattato, ma io l'ho tenuto slegato per mostrare
meglio i vari passaggi).
Il Ghenio
---------
// TODO: Place your ass here

Sicuramente ho interpretato male la descrizione di string.
Grazie per l'"illuminazione"?
Per quanto riguarda l'implementazione della stl, è consigliabile quella di
microsoft, oppure ad esempio STLport?
Mi spiego: le incompatibilità si mostrano solo al programmatore esperto
oppure anche a quello alle prime armi come come me?
Alessandro Chiarini

   sono pericolose.
Perfettamente d'accordo, ma non dimentichiamoci che gli warning del
compilatore sono stati messi li apposta per fare notare certe cose. Il
Borland ad esempio tali situazioni non se le lascia sfuggire a costo
di diventare antipatico(a differenza del VC++, i cui warning a volte
hanno dell'assurdo, ma non voglio fare polemiche fra compilatori
diversi), e se una persona che si ritrova nel suo codice un trentina
di
warning: comparing signed and unsigned values...
non prende provvedimenti, ha tutte le colpe nel caso che succeda
qualcosa di imprevedibile.


compilatore sono stati messi li apposta per fare notare certe cose.
Non tutti i compilatori segnalano la cosa (e lo standard
tratta la conversione int->unsigned e int->long alla
stessa stregua ... e' una "integral conversion") ma
anche supposto che sia carino segnalarlo (solo per il
confronto e comunque facendo casi particolari per le
costanti, perche' altrimenti anche a=2*v.size()
genererebbe inutili warning) resta il problema che
statement come
   if ( v.size() > x )
diventano in questo caso sospetti se x e' un intero e
obbligano di conseguenza a inserire innaturali cast
per zittire il compilatore.
Tutte rogne che non esisterebbero se v.size() fosse
un int/long e non un unsigned.
Andrea

 microsoft, oppure ad esempio STLport?
Noi in ditta usiamo la versione SGI.
http://www.sgi.com/tech/stl/
-- 
Luc.

microsoft, oppure ad esempio STLport?
La lib. standard fornita con il VC++ é un pò vecchiotta, ha qualcosa
che non va( ad esempio, per qualche strano motivo non sono mai
riuscito a far funzionare std::mem_fun_ref , e ci sono altre cose che
non funzionano come dovrebbero) ma complessivamente non é poi molto
disastrata, anche se la STLport é meglio ed é più aderente allo
standard.
