Dotaz: c++ převod string na int

[tuzka]

když mám v objektu string uložen řtězec např. "4587" jak ho mám převést na číslo int

myslím tim nějakou metodou třídy string ( i = retezec.prevednacislo();

Odpovědi

[podlesh]

Asi špadná odpověď, osobně preferuji plain C

i = atoi(retezec.c_str());

[podlesh]

Tedy ani ne tak špatná, jako "nekorektní".

Pro robustnější parsování (rozpoznání, zda řetězec je vůbec číslo, nebo kde číslo končí) slouží funkce strtol .

[unchallenger]

Zaleží na tom, co se má stát, když řetězec nerepresentuje číslo v desítkové soustavě. Pokud ti vyhovuje ,věci, které začínají jako číslo, jsou toto číslo, a věci, který vůbec jako číslo nevypadají, jsou nuly`, tak je atoi() v pohodě.

[#Tom]

Někteří lidi C++ nesnáší kvůli věcem, jako je tato:

#include <sstream>
#include <iostream>
#include <string>

using namespace std;

int main() {
  string s = "1234";
  istringstream is(s);
  int num;
  is >> num;
  cout << "Číslo je " << num << endl;
  return 0;
}

[tuzka]

díky, přesně to sem hledal

[elviin]

Právě modularita, na které je vaše řešení založené je na tom to pěkný. Problém není to, jak to lze vyřešit, problém c++ je ten, že neexistuje specializovaná metoda, která převádí řetězce na čísla, přesto že to je jeden z nejčastějších převodů reprezentace informace. Obecně mohu pracovat s informací, jak je libo, můžu napsat metody na převod čehokoliv na cokoliv, pokud to má význam a nějak mě to nesvazuje. To umožňuje přetížení operátoru <<,>> pro různé typy. Navíc díky přetížení můžu vytisknout informaci kamkoliv.

[unchallenger]

No, nevím. Proč vytvářet nějaký stream namísto obyčejného konstruktoru integeru z řetězce?

[Michal Kubeček]

Výhodou je fakt, že stejný postup mohu použít pro jakýkoli typ, pro který je definován operátor >>. Takže kdykoli si zavedu novou třídu X, ať už je to komplexní číslo, matice nebo cokoli jiného, stačí zadefinovat std::istream& operator >>(std::istream&, X&) a nemusím extra definovat funkci pro konverzi ze stringu. No a kdo chce funkci, může si zadefinovat template void string_to_anything<class X>(const std::string&, X&) nebo X* anything_from_string<class X>(const std::string&).

[#Tom]

Sice se mi nechtělo číst zdrojáky třídy istringstream, ale řekl bych, že tyhle vlastnosti by se daly zahrnout klidně do třídy string, vypadalo by to líp. A nebyl by potřeba konstruktor navíc.

[unchallenger]

Nerozumím. Výkonnou část konverze napsat musíš. A normálně, když chci z nějakého typu jný, tak to udělám:

i = int("1234")

nebo spíš

int i("1234");

abyste to měli se syntaxí C++, kde to ale takhle nejde. A celá ta konstrukce se streamy je jen složitý workaround.

[billgates]

Ja som asi strasny barbar, ked pouzivam:

if(sscanf(a.c_str(),"%d",&x)!=1) printf("neda sa\n");

Stary C-ckar sa vo mne nezaprie :)

[#Tom]

To je dobré. Já mám zase rád toto:

char line[256];
while (cin.getline(line, sizeof(line))) { ... }

[elviin]

Už jsem to napsal dříve/výše. V C++ metoda pro konverzi ze stringu na typ int ve třídě std::string nebo konstruktor pro int(basic_string<char>) neexistují:

int mujInt = mujString.prevedNaInt(); //nenajdem
i int("1234"); //taky ne

Proc neexistuje? Vzdyt je to častý způsob konverze! Pokud se na to podíváme z pohledu návrhu, tak IMHO myslim, ze to je velmi konzistetní a obecné řešení - nevkládat konverzní metody. S takovým přístupem bychom mohli rovnou zaimplemetovat např. do std::string i metody pro např. formátování. A to se mi na C++ libí, oddělení odlišných úloh tak, abych mohl v budoucnu použít opravdu jen to, co chci, nechci stavět na něčem, co nepotřebuji. Nepotřebuji konverzní funkce jako

TypRimskaCisla mojeRimskeCislo = 
  mujString.prevedNaRimskeCislo();

a nezastavíme se mohli bychom generovat další konverze. Když budu mít následující problém

TypVelkaBrambora mojeVelkaBrambora = 
  mojeBrambora.prevedNaVelkouBramboru();

To jak interpretuju velikost brambory přeci nezáleží na bramboře, ale na mě, to jak interpetuju cigarety, jestli jsou proclené nebo ne, nezáleží na cigaretách, ale na celníkovi nebo na mě, to jak interpretuju pasažera v tramvaji, jestli jede načerno nebo ne, nezáleží na něm, ale na tom, jestli se za přepravu zrovna platí, to jak interpretuju čísla, nezáleží na typu std::string nebo typu int, ale na tom, jak je interpretuje istringstream, a právě istringstream definuje formátování, interpretuje informaci např. jako int pro třídu std::string. Istringstream jen čte řetězce a interpretuje je s použitím formátovacích flagů, manipulátorů, nic víc po ní nechci.

Naopak funkcemi z istringstream bych nechtěl zanášet std::string nebo int.

Co chybí v <sstream> je obecná konverzní funkce, něco jako:

    template<typename T>
    inline T prevedDo(const string& st) {
        T t;
        istringstream(st)>>t;
        return t;
    } 

Pro typy, pro které jsou přetížené operátory << a >> ve třídě istringstream pak můžu napsat:

int myInt = prevedDo<int>("12345");
double myDouble = prevedDo<double>("13245");
float myFloat = prevedDo<float>("13245");

Jedna z dobrých vlastností v C++ je modularita (tím nějak nechci komentovat jiné jazyky), která se bude ješte prohlubovat. Bohužel díky pozdnímu standardu existuje dosud mnoho FUDu.

[unchallenger]

Houby. Zapomeň na streamy, stringy a čísla.

Máme třídu A a třídu B. Jak má vypadat a kdo má definovat metodu, která vytváří z typu A typ B?

Zkus si dosadit:

- za A string, za B istream

- za A int, za B double

- za A datum, za B datum+čas (nějaké typy, které je representují)

- a konečně za A string, za B integer

[elviin]

... s octem;)

Máme třídu A a třídy B, C, D, E .... mám pokračovat? Kolik konverzí se musí definovat?

Datum je prostě jen jeden. To jak bude vypadat není jeho věc. To je věc třídy XY, která od něj dědí a interpretuje ho. Přesně tak např. ostringstream, istringstream nebo stringstream interpretují std::string. Mně se takovej přístup líbí. Ale určitě by se mi líbilo i něco lepšího, proč ne.

[unchallenger]

Konverzí se musí definovat tolik, kolik je jich zapotřebí. Nechceš mi snad tvrdit, že při postupu se streamem žádná konverze není zapotřebí a integery v stringstreamu nějak samy magicky vznikají?

Ve skutečnosti máš konverze dvě:

1. Interpretace stringu jako stream.

2. Převod stringu na int -- ta se děje uvnitř >>, ale definovat ji nekdo musí.

Tu první děláš zbytečně.

[unchallenger]

Ještě jinak. Když nebudu mít to číslo jako string (tedy sekvenci znaků, což je věc, kterou přirozeně lze interpretovat jako stream), ale v nějakém obskurním typu MyType, jak ho převedu na int? Budu se pokoušet definovat mytypestream -- což je věc, která nedává smysl, protože MyType sekvence znaků vůbec nepřipomíná, takže ho na ten interface nenacpu -- abych mohl použít ke konverzi streamy?

[podlesh]

Už jsem to napsal dříve/výše. V C++ metoda pro konverzi ze stringu na typ int ve třídě std::string nebo konstruktor pro int(basic_string<char>) neexistují:

Samozřejmě, pokud to vezmeme obecně: tyto metody nepatří do třídy string (tedy zdroje, nositele dat bez informace o struktuře), ale do třídy cílové, která umí data zakódovat (a nejen do řetězce). Tedy do třídy int ...

Jedna z dobrých vlastností v C++ je modularita (tím nějak nechci komentovat jiné jazyky), která se bude ješte prohlubovat. Bohužel díky pozdnímu standardu existuje dosud mnoho FUDu.

Tento trik s isstringstream je prostě hack. To samozřejmě mnoho lidí obdivuje, některé jazyky na tom stojí. Ale mnoho lidí zase stojí v úžasu nad takovým overheadem u jedné z nejběžnějších operací vůbec.

Navíc, i jako obecný princip to není moc užitečné. Protože to předpokládá, že nějaké obecné objekty budou mít jednoznačnou znakovou reprezentaci - a to mít nebudou. Ani u těch čísel to není zcela jednoznačné, můžu chtít ta čísla hexadecimálně, nebo v různé soustavě podle C notace...

[Michal Kubeček]

Ale mnoho lidí zase stojí v úžasu nad takovým overheadem u jedné z nejběžnějších operací vůbec.

Ten overhead ve skutečnosti není zdaleka tak velký, jak to opticky vypadá.

Navíc, i jako obecný princip to není moc užitečné. Protože to předpokládá, že nějaké obecné objekty budou mít jednoznačnou znakovou reprezentaci

On to také obecný princip není. Jde jen o to, že má-li objekt svou textovou reprezentaci (jako třeba int), je obvykle operace jeho přečtení ze stringu přesně totéž jako jeho přečtení z jiného streamu (soubor, socket, …). A byl by tedy nesmysl implementovat ji dvakrát.

[podlesh]

Nemusí se implementovat dvakrát; stačí ji mít přístupnou přes dvě rozhraní, která se liší použitím i smyslem. Nehledě k tomu, že "obykle" nemusí znamenat vždy a reprezentace ve stringu a v obecném streamu se může lišit (do souboru se například bude ukládat binárně).

Ano, chápu že zobecnění a modularita je pěkná věc, ale tento konkrétní případ mi přijde dotažené doslova "ad absurdum" . Nebo možná spíše "znouzecnost"

[Michal Kubeček]

stačí ji mít přístupnou přes dvě rozhraní

A to je přesně to, co vyřešíte jedním jednoduchým templatem. Pouze se (v rozporu s tradicí) za primární interface považuje ten streamový, protože je obecnější.

do souboru se například bude ukládat binárně

Což je přesně to, co se v dokumentaci k libstdc++ velmi důrazně nedoporučuje, protože to téměř garantuje nepřenositelnost toho datového formátu. Ne že by to nešlo udělat i přenositelně, ale dalo by to podstatně víc práce.

[podlesh]

stačí ji mít přístupnou přes dvě rozhraní

A to je přesně to, co vyřešíte jedním jednoduchým templatem. Pouze se (v rozporu s tradicí) za primární interface považuje ten streamový, protože je obecnější.

Nevyřeším. Ta šablona totiž obsahuje i implementaci, která nebude optimální. A tím nemyslím jenom to, že se vyrábí wrapper stream. U složitějšího parsování je i rozdíl ve zpracování a rozhodně nebude výjimkou, že se data z toho streamu načtou do řetězce a pak se parsují. Ony ty tradice nemusí být nemysly

No, už se trochu dostáváme mimo.

Celá tato diskuse pro mě velmi překvapivá. Jsem ze strany zastánců C++ zvyklý na argumenty vyzdvihující efektivitu výsledného kódu a šetření cyklů procesoru. Že to někdo bere zcela naopak a pojímá C++ spíše jako typovaný LISP, to bych ani ve snu nečekal. Holt - pokrok