Newsgroup: it.comp.lang.c++
Titolo: metodi classe string

scusate ragazzi ma sono proprio un caprone...
come e' possibile effettuare operazioni "complesse" con la classe
"string"?? per esempio concatenazioni, cast ricerche....
ci sono dei metodi specifici o bisogna usare le funzioni classiche C?
per esempio i vari cast tra *char e string come si fanno?
tra int e string? e' possibile che non riesca a fare un cast ancher
esplicito tra int e string??
Grazie per l'aiuto ad un vero Caprone!!
ciao by il Caprone
--
Posted from 
alquanto.nextra.it
 [193.43.2.90] 
via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 esplicito tra int e string??
"Ma siamo matti"?  Cosa ti aspetteresti da "un cast" del
genere?!  Se vuoi FORMATTARE un int in una std::string
puoi usare std::ostringstream, e per PARSARE da una std::string
un int puoi usare std::istringstream, cosi` come useresti
qualsiasi altro analogo stream se volessi andare su/venire
da file, stdin/stdout, ecc ecc.
Alex

     if(dove == std::npos) {
Non dovrebbe essere string::npos invece di std::npos?  Ma queste
istruzioni possono dare fastidi, purtroppo --- bisognerebbe usare
std::string::size_type e non size_t.
Per motivi di tradizione, infatti, lo Standard dice che string::npos
DEVE essere definito come (equivalente a) -1; e quindi e' il piu'
grande valore rappresentabile dal tipo (unsigned) string::size_type.
Se size_t e string::size_type sono due tipi unsigned differenti,
operator == restituisce il risultato sbagliato.
Nei due compilatori che ho a disposizione, l'allocator di std::string
definisce string::size_type come size_t; ma non mi risulta che ci sia
alcuna garanzia in proposito.
-- 
Maurizio Loreti                         
http://www.pd.infn.it/~loreti/mlo.html
Univ. of Padova, Dept. of Physics - Padova, Italy            
lor...@pd.infn.it

 operator == restituisce il risultato sbagliato.
A rigore, hai ragione: non so che vincoli ci siano su
std::string::size_type,
e non riesco a sognarmi un caso pratico in cui potrebbe mai differire da
size_t, ma e` probabilmente possibile costruire una implementazione
formalmente conformante di compilatore e libreria in cui questi due
tipi possano differire.
Se size_t e` piu` ampio di std::string::size_type, nessun problema,
naturalmente, con lo specifico uso che stavo facendo: non puo`
esistere, neppure concettualmente, nessun caso in cui questo codice
produca risultati erronei sotto questa ipotesi.
Se size_t e` meno ampio di std::string::size_type, cioe` se e`
possibile definire stringhe che sono piu` lunghe del massimo
oggetto che puo` esistere ed essere sottoposto a operatore sizeof,
il mio codice potrebbe teoricamente dire (erroneamente) che "ago"
non e` stata trovata, se viene trovata all'offset "sfortunato"
corrispondente esattamente ad npos ristretto a size_t e poi di
nuovo allargato.
Non capisco pero` come una simile ipotetica implementazione
potrebbe essere mai compliant.  Ad esempio, come potrebbe
mai definire una corretta funzione membro .c_str(), confacente
allo standard, una std::string il cui size_type e` piu` ampio
di size_t...?  Non so se si possa rigorosamente dimostrare che
questo e` impossibile (a occhio si direbbe di si`, ma e` lavoro
da avvocati...), e quindi che il rilevante size_type non puo`
essere piu` ampio di size_t, e quindi il codice nel mio esempio
non puo` mai fallire su nessuna implementazione compliant.  Sai
mica come accedere al set completo delle correzioni che dopo la
pubblicazione dello standard sono state accettate dal comitato?
Un chiarimento del genere sarebbe sicuramente "del tipo" che in
queste correzioni viene appunto gestito.
...::size_type e` fondamentale per un allocator e per tutti quei
contenitori che possono trarre pieno vantaggio dalla generalita`
di un allocator, ma la mia impressione e` che, visti i limiti dati
dall'esistenza di .c_str, basic_string usa un size_type solo per
ragioni di uniformita` (come pure vector, che grazie ad uno dei
suddetti chiarimenti ha oggi un vincolo di allocazione in un solo
blocco compatto di memoria di tutti gli argomenti).  Al limite,
l'esistenza del size_type permette di _restringere_ rispetto a
size_t la capacita` di questi contenitori, ma questo, come gia`
abbiamo detto, non cambia la funzionalita` del mio esempio.
Alex

 esplicito tra int e string??
Potresti utilizzare uno std::ostringstream (tanto per darti un idea,
simile alla vecchia sprintf()) e poi copiare o swappare sulla
std::string.
EMG

 queste correzioni viene appunto gestito.
No, non lo so (sul sito ANSI da cui ho acquistato lo Standard non
risulta nulla, su comp.lang.c++.moderated non ho trovato nulla); la
cosa interessa anche me.  Mi dispiace di non poter leggere la risposta
a questa lettera (saro' impossibilitato ad usare le news per diverso
tempo), se avrai tu notizie me le darai piu' avanti.
                Ciao
[*] Nello Standard, in 5.3.3, si dice che size_t e' un "tipo atto a
    rappresentare ...", e non si dice ad esempio "tipo _aritmetico_".
    Per quanto posso capire, e' legale un size_t definito, ad esempio,
    come struttura composta da 2 unsigned long; quello che serve e'
    l'esistenza di operatori di conversione, di costruttori opportuni
    e di operator << per l'output su uno stream (ma non sono sicuro di
    questo).


 sprecate.
Questa in particolare puo` essere controproduttiva, perche` inibisce
l'uso del costruttore di default se il "diventare" della variabile,
invece che da lifetime static a lifetime auto (sai benissimo che non
e` una questione di globale o locale, cioe` di scope, ma una di static
o auto, cioe` lifetime), e` da POD a tipo con costruttore di default.
E` come la pessima idea di scrivere, per "ridondanza mai sprecata",
if(xx!=0) invece di if(xx).  Forse era una buona idea ai tempi del C.
In C++, molto meglio lasciarla perdere, perche` operator!=(int) e
operator bool() sono cose cosi` diverse.  La "difensivita`" in se`
non e` cosa malvagia, ma oramai bisogna difendere la difensivita`
stessa a fronte di tante cose implicite che un dato tipo potrebbe
portarsi dietro in una futura revisione.
Alex

 wrote in message:
[si parlava dei metodi della classe string]
[cut]
intervengo anch'io visto che ho avuto problemi analoghi.
Nei libri su cui studio (Lippman e Lajoie, Eckel) tutte queste cose non mi
sembrano siano scritte, o almeno se vi sono non sono certo comode da
trovare. Allora vi chiedo:
Dove trovare un manuale didascalico (sia cartaceo che, meglio, in rete) con
classi, membri, metodi, qualche esempio ecc... del C++ standard? Vorrei
qualcosa di simile alla guida di riferimento di Java, in cui tutto e'
veramente chiaro!!! Uno strumento di uso che permette di trovare anche cose
che uno non si apetterebbe mai! non come le guide dei vari ambienti, che,
almeno per Borland  e Microsoft, sono utili se uno non ricorda qualcosa che
pero' gia' sa esistere. Spero che mi possiate essere utili, in quanto
secondo me e' un' ostacolo non da poco non sapere tutte le caratteristiche
che un simile linguaggio puo' mettere a disposizione!
--
Ciao by Beppe
Solo chi č stupido non cambia mai idea
(Aldo, "Cosě č la vita")

 classi, membri, metodi, qualche esempio ecc... del C++ standard?
Su 
www.borland.com
 trovi dei file HLP che mi sembrano veramente ben
fatti.
EMG