Newsgroup: it.comp.lang.c++
Titolo: Da oggetto string a int

Scusate, magari la domanda e' banale, ma non riesco a trovare la
funzione che mi serve e sono 20 minuti che la cerco :) (sorry,
sto imparando). Mi potreste dire come converto in int un oggetto
string? Ovverio io ho una string = 123 e voglio che l'int contenga
123. Grazie mille.
-- 
Saluti,
 Francesco Cipriani - 
http://village.flashnet.it/~rm03703

123. Grazie mille.
Con il metodo ToInt() della classe String.
String S = "123";
int x = S.ToInt();

Con il metodo ToInt() della classe String.
E se ti dicessi che tale metodo non ce l'ho ne' sul gcc 2.8.1 (os/2)
ne' su egcs della redhat 6.1? E non e' nemmeno riportato su c++ primer..
Apposta non lo trovavo :)


Ciao, e se provi con itoa ??
SISMA

 Apposta non lo trovavo :)
Infatti, la classe string prevista dallo standard C++ non ha
nessun metodo del genere.
Meglio usare approcci standard, come applicare una qualsiasi
di atoi, strtol, ecc, al c_str() del tuo oggetto std::string,
oppure ricorrere a std::stringstream e i suoi operator>>
(quest'ultimo e` piu` flessibile, ma se sei in un punto critico
del codice bisognera` verificare le prestazioni).
Alex

]

Ciao, e se provi con itoa ??
Casomai sarà atoi,e lo si capisce anche ad occhio.
Il Ghenio

123. Grazie mille.
Prova cosi':
--
#include <string>
int main()
{
string stringa="123";
char *carattere;
carattere=stringa.c_str();
int numero=atoi(carattere);
}
--
Un pò complicato ma funziona.
Il Ghenio

 123. Grazie mille.
  #include <string>
  #include <sstream>
  std::string str = "123";
  int i;
  std::istringstream is( str );
  is >> i;
	Mauro

Si puo' semplificare con
#include <string>
using namespace std;
int main()
{
string stringa="123";
int numero=atoi(stringa.c_str());
}
Ciao
GG


del codice bisognera` verificare le prestazioni).
Per adesso sono molto molto all'inizio e comunque per un bel po'
non mi preoccupero' delle prestazioni :).
A proposito, grazie dei consigli sui libri, alla fine ho comprato
c++ primer 3d edition, in inglese appunto.


 a char.
A char?  Un char non puo` tenere tutti i valori che un unsigned
long puo` avere.  Intendi forse che devi formattarlo come
stringa?
Se il tuo compilatore (specificamente le tue librerie) e`
ragionevolmente vicino allo standard, usa anche per
questo uno stringstream (in questo caso uno di output,
cioe` std::ostringstream.
Usa prima #include <sstream>, poi eventualmente
un using std::ostringstream; per comodita`, poi
std::string formatta(unsigned long iltuoulong)
{
    ostringstream oss;
    oss << iltuoulong;
    return oss.str();
}
La funzione membro .str() delle ostringstream ti
torna la std::string contenuta.
Alex

a char. Il brutto e' che sto studiando il c++ ma non conosco il C
Mi rispondo in parte da solo, ma poi e' uscito fuori un altro
problema: ho trovato la funzione _urltoa, precisamente:
char *_ultoa (unsigned long, char *, int);
), ma ho letto anche qualcuno che parlava di ultoa, senza underscore.
Ora.. e' il mio compilatore che e' strano o perche' le funzioni da
char* a numerici sono senza underscore mentre cio' non vale per
numerici -> char* ?


 numerici -> char* ?
A rigor di standard, l'#include di header standard non puo`
"inquinare" lo spazio dei nomi disponibile per l'utente con
identificatori non previsti dallo standard.
Gli identificatori che iniziano con _ (con certe condizioni)
sono nello spazio dei nomi riservato all'implementazione,
quindi possono essere liberamente introdotti.
Visto che atoi, ecc, sono standard, mentre itoa, ecc, no,
questi ultimi, se introdotti via header standard, non
possono chiamarsi cosi`, ma piuttosto _itoa, ecc.
In C++ esistono anche altre possibilita` (i veri e propri
namespace previsti dallo standard!), ma questa parte
e` in comune con il precedente standard C, quindi...
Alex

atoi! L'unico l'inimitabile!
--
Diego Pettenň
diego...@hotmail.com
May the Force be with you!

cioe` std::ostringstream.
E invece stavolta mi attacco, perche' i compilatori che ho
non hanno gli ostringstream. Ma per sapere, visto che i miei
sono relativamente aggiornati, quale compilatore li supporta?


e` in comune con il precedente standard C, quindi...
Quindi compilatori come un vecchio borland C++ del '93 che ho
sbagliano a rendere disponibili funzioni tipo ultoa?


 sbagliano a rendere disponibili funzioni tipo ultoa?
Se questi nomi vengono iniettati nel namespace
dell'applicazione a fronte dell'include di un header
file standard, c'e` una violazione degli standard
(sia quello C, sia quello C++); lo standard C++ e`
piu` recente, ma quello C esisteva gia` da anni.
Alex

 sono relativamente aggiornati, quale compilatore li supporta?
Per esempio, Visual C++ (mi pare sin dal release 4.2, che a
sua volta dovrebbe datare da circa 3 anni fa).
Se devi usare compilatori piu` vecchi, forse ti conviene
ricorrere a vecchie funzionalita` del C, come sprintf.
Alex

 sbagliano a rendere disponibili funzioni tipo ultoa?
No, e perché? Il fatto che non siano standard non significa che un
produttore di compilatori non le possa implementare o che non possano
essere utilizzate dal programmatore. Solo che, facendolo, bisogna essere
ben consci che la loro portabilità, persino tra compilatori diversi,
potrebbe essere molto bassa.
EMG

 piu` recente, ma quello C esisteva gia` da anni.
Il DJGPP mette la dichiarazione di itoa() nello stdlib.h ma
racchiudendolo tra #ifdef in modo tale che sia accettato solo se non si
sono attivati gli switch che permettono la compilazione solo di codice
strettamente ANSI/ISO. E' comunque in violazione dello standard?
EMG

ricorrere a vecchie funzionalita` del C, come sprintf.
In realta' i compilatori sono piu' nuovi, ma non implementano
comunque quelle classi. Per esempio il gcc e librerie relative)
sotto OS/2 sono del dicembre 1998, ma evidentemente non essendo
commerciale lo sviluppo prosegue lentamente. Quello che
mi sembra molto strano e' che l'ultimo egcs che e' distribuito
con la redhat 6.1 non abbia le ostringstream nemmeno lui


piu` recente, ma quello C esisteva gia` da anni.
Beh nel namespace ci vanno eccome, e questo succede includendo
se non sbaglio stdlib.h che e' standard, quindi penso se ne
siano un po' fregati dello standard C. Quando parli di
standard C++ ti riferisci a quello del 98, giusto?


No, e perché? Il fatto che non siano standard non significa che un
Boh, mettetevi d'accordo, per Alex Martelli se tali nomi di funzioni
vanno nel namespace dell'applicazione allora la borland non ha
fatto le cose per bene


 con la redhat 6.1 non abbia le ostringstream nemmeno lui
Il tema e` sempre "lentezza del gruppo che fa le librerie
standard C++ per gcc/egcs".  Naturalmente, chi non fa
parte di quel gruppo ma si limita a coglierne i benefici non
e` in una gran bella posizione per lamentarsi:-).
Alex

 fatto le cose per bene
Non importa molto, nel grande schema delle cose, se siamo
d'accordo io, tu, EMG, e altri frequentatori di questo gruppo;
importa di piu` quello che dicono gli standard.
Gli standard internazionali dei linguaggi C e C++ prevedono
che il compilatore non possa iniettare arbitrari identificatori
nel namespace dell'applicazione a fronte di #include di soli
header file standard.
Sarebbe, altrimenti, impossibile scrivere programmi davvero
portabili, che e` uno scopo primario di questi standard.
Naturalmente la Borland nel '93 non poteva rispettare uno
standard emesso nel '98 (ho gia` parlato di macchine del
tempo in un recente post...:-), cioe` quello C++, pero`
quello C all'epoca c'era gia`.
Alex

 standard C++ ti riferisci a quello del 98, giusto?
Giusto; che io sappia, non esistono altri standard per
questo linguaggio (nel senso "proprio" del termine
"standard"; naturalmente uno puo` sempre dire "io ho
il _MIO_ standard privato e personale":-).
Alex

 strettamente ANSI/ISO. E' comunque in violazione dello standard?
No, lo standard C non prescrive nulla su cosa un dato programma
debba fare quando il programma in questione non sostiene di
essere un compilatore C (e lo stesso mi pare valga per lo
standard C++).
Ad esempio, posso scrivere un programma Pippo.Exe, che,
chiamato cosi`:
    Pippo.Exe -c Pluto.c
e` un compilatore c, mentre se lo chiamo:
    Pippo.Exe -f Paperino.f
e` un compilatore Fortran, e se lo chiamo:
    Pippo.Exe Bologna Fiorentina
consulta un database in rete e calcola le statistiche di tutti
gli incontri di calcio fra le squadre "Bologna" e "Fiorentina"
nella storia.
Questa, ahem, "ricchezza funzionale", non gli impedisce di
essere un compilatore C aderente allo standard (naturalmente
solo nella modalita` ottenuta con l'opzione -c), se rispetta
i vari altri vincoli imposti dallo standard stesso.
Colgo l'occasione per deprecare il riferimento all'ANSI, che,
da una decina d'anni, non ha nessun particolare rapporto
con gli standard C e C++, non piu` di quanto ne abbia
qualsiasi altro "national standards body" aderente all'ISO,
come BSI e tanti, tanti altri.
Vi fu, si`, un breve periodo (un annetto, mi pare?) in cui
l'ANSI aveva gia` approvato un "suo" standard C, mentre
l'ISO ne stava ancora discutendo, ma naturalmente non
appena l'ISO approvo` il suo standard l'ANSI si affretto`
a gettare alle ortiche il proprio per aderire a quello ISO
(simile a quello ANSI ma con alcune migliorie per quel
che riguarda l'internazionalizzazione).  Per il C++, non si
e` mai neppure verificata una transitoria anomalia del
genere -- l'ANSI ha adottato lo standard ISO proprio
come hanno fatto tutti gli altri comitati nazionali.
Non mi sembra giusto continuare a rinfacciare all'ANSI
la temporanea, presto corretta aberrazione di tanti,
tanti anni fa, in cui si pose in violazione delle norme
internazionali relative alla standardizzazione.  Che mai
devono fare, poveracci!, perche` il mondo perdoni
e dimentichi...?!-)
Alex

 potrebbe essere molto bassa.
Non e` solo questo.  E` che questo cavolo di compilatore
non mi permette di compilare un modestissimo programma
perfettamente standard del tipo:
    #include <stdlib.h>
    extern int ultoa;
    int plup(int x) {
        return ultoa+x;
    }
perche` mi ha RUBATO l'identificatore ultoa, usandolo per
i suoi sporchi scopi mentre lo standard lo riserva a *ME*,
il programmatore.
Questa detestabile prassi rende totalmente impossibile la
scrittura di programmi standard se prima uno non si e`
studiato accuratamente gli header di tutti i compilatori,
compresi quelli ancora non scritti.
Ci vuole molto, molto poco a usare invece identificatori
come _ultoa (l'underline iniziale lo consente), ovvero a
porre identificatori come ultoa nello spazio dei nomi
riservato all'utente solo se l'utente lo richiede in modo
esplicito con #include di un header file non standard
(o con un #pragma, al limite:-).
Incidentalmente, considero queste due prassi (che
lo standard sancisce) entrambe molto superiori a
quella di ricorrere invece a switch run-time del
compilatore stesso, settaggi nella registry ovvero
nell'environment, e via elencando, perche` tutti
questi altri modi di "sfuggire allo standard" NON
sono visibili nel sorgente C che viene usato, mentre
i modi sanciti dallo standard lo sono e informano
subito il lettore del codice che questo programma
non e` e non pretende di essere portabile.
Comunque, su questo lo standard non si pronuncia,
e la ragione per cui non lo fa e` tentare di evitare
conflitti con _altri_ standard (specificamente, lo
standard Posix) che prevedono invece che l'#include
di un certo header file standard DEBBA iniettare nello
spazio dei nomi riservato all'utente un certo numero
di identificatori che lo standard ISO gli VIETA di
iniettare.  Chiaramente, questo conflitto non e`
risolubile se non con opzioni runtime, ecc.  Inoltre,
l'esistenza di questo conflitto mostra quanto poco
saggia fosse la passata prassi che permetteva a
vari enti di iniziare indipendentemente le loro
operazioni di standardizzazione senza la saggia
coordinazione dell'ISO - oggi, per fortuna, cio`
non e` piu` ammesso!
Alex

 con la redhat 6.1 non abbia le ostringstream nemmeno lui
Neanche la libreria fornita con il DJGPP implementa ostringstream.
EMG

 fatto le cose per bene
Aspetta: Alex ha detto che si va fuori standard quando, includendo un
header standard, vengono iniettati nello scope globale anche nomi di
funzioni non standard. Io invece parlavo della possibilità da parte di
un produttore di compilatori di fornire funzioni non standard e questo
non è proibito dallo stesso a patto, appunto, che le dichiarazioni siano
messe in header non standard.
EMG

 standard C++ ti riferisci a quello del 98, giusto?
Perché ne esiste qualcun'altro? :-)
EMG

 e dimentichi...?!-)
Forse si dovrebbero bruciare tutti i libri e gli articoli sui quali si
trova ancora scritto "ANSI". :-)
EMG

]

 wrote in message news:38611595...@flashnet.it...

Giusto.  E` perfettamente accettabile per qualsiasi produttore
di compilatore, cosi` come lo e` per chiunque altro, fornire
gran copia di funzionalita` supplementari, purche` esse vengano
richieste dal programma usando un
    #include "nome_non_standard.h"
o similari; oppure, nel solo caso del compilatore, le funzionalita`
supplementari possono venire rese disponibili da un header
file standard, o anche _senza_ bisogno di accedere a nessun
header file (cioe` come "built-in" del compilatore), purche`
queste funzionalita` supplementari non inquinino lo spazio dei
nomi riservato all'utente (ad esempio e` sempre corretto se
gli identificatori iniziano con due underline, e spesso lo e` anche
se di underline ce n'e` uno solo, dipende da cosa lo segue).
Ad esempio: un compilatore non puo` definire "far" come sua
keyword, perche` il povero utente puo` benissimo avere un
programma strettamente compliant con costrutti come:
    int far = 23;
che ha pieno diritto di compilare correttamente; il compilatore
puo` invece benissimo definire "__far" come keyword, perche`
i due underline iniziali mettono questo identificatore fra quelli
che l'utente non puo` e non deve usare in un programma
strettamente compliant.  In piu`, o in vece, il compilatore puo`
definire "far" come keyword se e solo se l'utente ha usato
un
    #pragma continuiamocosi_facciamocidelmale
oppure un
    #include <nonfacciamocisemprericonoscereda.tutti>
(si noti che non e` minimamente necessario che un #include
corrisponda ad un qualche "file" che il compilatore deve
leggere, anche se questa e` una prassi comune; e` diritto
del compilatore trattare certi #include per 'pseudo-header'
da esso definiti, come se fossero in pratica dei #pragma).
Tutto questo non tocca minimamente la questione se sia
giusto o meno, furbo o meno, ecc ecc, per un compilatore
offrire funzionalita` supplettive, e/o per il programmatore
usarle.  Stiamo parlando, strettamente, di "purezza" dello
spazio dei nomi: cosa il compilatore deve garantire in merito
(e quindi, su cosa puo` far affidamento un programma
strettamente compliant), a fronte di quali "comportamenti",
diciamo, _lessicali_, da parte del programma.
Alex

 correttamente con la libreria fornita con egcs
Azz, dev'essermi sfuggito.
EMG

 puo` darsi che questo ti dia funzionalita` altrimenti mancanti.
Di solito la SGI STL viene fornita insieme al gcc.
Le lacune piu' grosse sono nella parte non coperta dalla
libreria SGI (soprattutto iostreams), quindi bisogna cercare
da qualche altra parte.
Per sstream c'e' un link postato su questo gruppo qualche
giorno fa (non mi ricordo da chi):
ftp://ftp.informatik.uni-konstanz.de/pub/algo/personal/kuehl/sstream.tgz
	Mauro

, ma siccome e' Natale,
riporto anche il link (che sforzo!):
ftp://ftp.informatik.uni-konstanz.de/pub/algo/personal/kuehl/sstream.tgz
Basta copiare gli header nella directory dove si ha la libreria
standard. Con egcs e gcc 2.95 rispettivamente su cygwin e linux
funziona benissimo.


 funziona benissimo.
Dunque. L'ho provato con il mio DJGPP (gcc 2.95) ma mi dà una marea di
errori. Sapresti darmi un semplice programmino di esempio da compilare
per vedere se funziona?
EMG


La cosa piu' stupida che mi viene in mente (conversione da stringa ad
int):
#include <iostream>
#include <string>
#include <sstream>
using namespace std;
int main(int argc, char **argv)
{
	string s="100";
	istringstream iss(s);
	int i;
	iss>>i;
 
	cout<<s<<" (string) has been converted to "<<i<<" (int)\n";	
}
Errori di battitura a parte con gcc 2.95 su linux e 2.91 con cygwin
non da' nemmeno warning e funziona correttamente (sembra funzionare
anche su solaris, dove purtroppo con il gcc ho ben altri problemi...)


e` in una gran bella posizione per lamentarsi:-).
Che c'entra, mi faceva piacere che le librerie fossero aggiornata,
ma non c'e' giorno che non ringrazio tra me e me tutti coloro che
hanno scritto software open source che uso :).


per vedere se funziona?
A me con djgpp (gcc 2.952) funziona correttamente, solo che devi
controllare gli include delle librerie con nomi lunghi che sotto
dos non ci stanno :). Anzi, anche sotto os2 (gcc 2.8.1) ha funzionato
bene dopo aver accorciato i nomi degli include, perche' nel gcc di
os2 hanno tenuto la compatibilita' col dos per i nomi


C++ rispetto al precedente standard C.
In effetti i complex non li pensavo nemmeno.. beh certo una
funzione C non puo' supportare oggetti C++ :). Che poi.. i complex
ma quanto si usano nella programmazione "comune"?


Perché ne esiste qualcun'altro? :-)
Eh ma se non lo so.. :)


 int):
Grazie. Purtroppo mi dà tanti errori, i primi dei quali sono:
In file included from include/sstream:2,
                 from sstest.cc:6:
include/sstream.h:70: parse error before `<'
include/sstream.h:75: syntax error before `::'
include/sstream.h:76: syntax error before `::'
include/sstream.h:78: syntax error before `='
include/sstream.h:82: `traits' is not a class or namespace
include/sstream.h:82: `int_type' is not a class or namespace
include/sstream.h:82: warning: using `typename' outside of template
include/sstream.h:82: `traits' fails to be a typedef or built in type
include/sstream.h:83: `traits' is not a class or namespace
include/sstream.h:83: `pos_type' is not a class or namespace
include/sstream.h:83: warning: using `typename' outside of temp
Mi sai dire perché?
EMG

 dos non ci stanno :).
In che senso? Io utilizzo il DOS di W95 e i nomi lunghi ci sono e mi
sembra siano tutti a posto. E comunque in quel caso l'errore sarebbe
stato chiaro e ben facile da risolvere, o no?
EMG

 ma quanto si usano nella programmazione "comune"?
Dipende, credo, dal tipo di programmazione. Se fai programmi matematici
forse li usi. Io, facendo più che altro gestionale, non ne ho mai avuto
bisogno. Forse avrebbero potuto evitare di metterli fra i tipi standard.
EMG

stato chiaro e ben facile da risolvere, o no?
Direi di si.. ma sei sicuro di aver preso il file giusto? Io sono
andato nella dir e ne ho trovati due: uno del '96, uno piu' nuovo,
col suffisso -egcs e ho usato quello.
-- 
Saluti,
 Francesco Cipriani - 
http://village.flashnet.it/~rm03703
Remove TOGLIMI. to reply by email - Rimuovi TOGLIMI. per rispondermi in email

 ma quanto si usano nella programmazione "comune"?
Dipende cosa intendi per "comune".  Molti non conoscono
l'aritmetica complessa, quindi non la usano anche quando
gli farebbe enormemente comodo, perche` non sanno che
gli tornerebbe utile; ad esempio, nelle operazioni di
grafica bidimensionale (ogni movimento rigido del piano,
e vari altri, sono modellati da semplicissime operazioni
aritmetiche sui numeri complessi).
E` come chiedere, quanto si usano std::vector, o i vari
algoritmi dell'header <algorithm>.  La risposta e`, certo
meno di quanto si _dovrebbero_ usare: i programmatori
non li conoscono, non ci pensano, non li usano, anche
quando e` sciocco non usarli.
Alex

 include/sstream.h:70: parse error before `<'
Potrebbe essere che hai una vecchia iostream senza
template, mentre questa sstream richede una versione
con template.
Infatti la riga 70 dice:
  class basic_stringbuf: public basic_streambuf<charT, traits>
e senza un template basic_streambuf non compila.
Gli altri errori potrebbero essere una conseguenza
di questo.
P.S. non so dove trovare una iostream nuova (con
template) se non ce l'hai gia'.
	Mauro

Mi sai dire perché?
Ho provato a vedere l'header, ma l'errore e' in una dichiarazione
uguale ad altre nelle linee precedenti che non sembrano dare problemi
(potrebbe non voler dire nulla perche' magari si tratta di template
non instanziati), quindi non capisco da che puo' derivare. Potrebbe
dipendere dalla versione di libreria standard che usi, ma non so cosa
venga distribuito con djgpp.
Piuttosto mi chiedo una cosa: visto che usi il djgpp con win95, non ti
converrebbe passare a cygwin?



La stl di 
http://www.stlport.com
 ho visto che dovrebbe compilarsi un
po' ovunque, qualcuno sa quanto e' aderente allo standard?


 con template.
Grazie. Forse conviene che vado su 
www.delorie.com
 a vedere se c'è
qualche aggiornamento...
EMG

 col suffisso -egcs e ho usato quello.
Boh, penso di si. Mi pare molto probabile sia giusta l'ipotesi di Mauro
Casini.
EMG

 converrebbe passare a cygwin?
Siccome sono interessato solo allo standard, penso non abbia senso
dotarsi di uno strumento per sviluppare programmi per Windows, o
sbaglio?
EMG

sbaglio?
cygwin e' aderente allo standard; il compilatore e' sempre il gcc
(sono loro gli sviluppatori ufficiali adesso), le librerie standard
sono le stesse. Il vantaggio di cygwin e' poter sviluppare in modo
uniforme sotto qualsiasi piattaforma: tutti i gnu tools che hai sotto
unix con cygwin funzionano pure sotto windows; stesso discorso vale
per praticamente tutte librerie. 


 per praticamente tutte librerie.
Uhm... va bene, ci farò un pensierino. Ma non subito, dato che ho appena
scaricato l'ultima versione del DJGPP. Grazie comunque delle info.
EMG

lunghi (tipo ALGORITHM o STL_RAW_STORAGE_ITER.H).
Abbiamo ragione entrambi :) perche' come avrai visto su 
delorie.com
,
lo zip picker indirizza su diversi pacchetti dipendetemente dal so
scelto. Siccome io ho scelto os/2, le cui sessioni dos non vedono
i nomi lunghi, molto probabilmente lui mi ha dato il djgpp coi nomi
corti
