Dotaz: long long int - jak ho deklarovat?

[Ondra]

Jak v céčku deklarovat long long int (int mi nestačí, zato tento je prý většinou osmibytový), jak ho nastavit unsigned/signed ? A jak ho vytisknu přes printf? (u intu je to "%d"). Nebo si musím pro uložení větších celých čísel naprogramovat nějaké vlastní funkce? Dík.

---

---

Odpovědi

[l4m4]

long long int deklaruješ jako long long int. To je překvapení, že?

long long int i;
signed long long int j;
unsigned long long int k;

Pokud nechceš long long int, ale přesně 64bitový integer, tak (špičaté závorky nepíšu, protože to je tu k naštvání)

#include stdint.h
int64_t i;
uint64_t j;

Pokud nechceš long long int, ale alespoň 64bitový integer, tak

#include stdint.h
int_least64_t i;
uint_least64_t j;

Pokud nechceš long long int, ale co nejdelší integer, tak

#include stdint.h
intmax_t i;
uintmax_t j;

long long int má formátovací modifikátor ll, (u)intmax_t má modifikátor j, vše uvedené vyžaduje alespoň ISO C99 (případně rozšíření kompilátoru ve starším C), pro typy s přesnou délkou formátovací modifikátory neexistují.

Pokud potřebuješ fakt velké integery, použij GMP.

[Ondra]

Diky moc. Budu testovat v ISO C++, pujdou na to Tebou uvedene varianty? (je ISO C++ rozsireni ISO C99 ?) A jeste otazecka: jaky je formatovaci modifikator unsigned long long?

[l4m4]

Žádná verze C++ není rozšíření žádné verze C, i když snaha o určitou kompatibilitu samozřejmě existuje. V C++ je long long až v C++11, tudíž opět viz rozšíření kompilátoru...

Pokud programuješ v C++, tak proč se ptáš na formátovací funkce ze standardní knihovny C? V C++ se pro vstup a výstup normálně používají takové ty trhlé dvojité zobáčky. V každém případě integer bez znaménka má samostatnou základní konverzi, u (tj. není to na rozdíl třeba od ll modifikátor).

By mě zajímalo, jak dlouho jsi zkoušel odpovědi na tyto věci například vygooglit. Bylo to déle než 2s?

[l0gik]

Puristo. Spousta lidí dělá v C++ a používá printf, protože ty trhlé zobáčky jsou dosti trhlé.

[Šangala]

Pokud by se pořádně naučili ty trhlé zobáčky používat, bylo by to mnohem snazší na kódu dále pokračovat.
Taky někdy se „snižuji“ jen k „C+“, ale zrovna přetížený operátor << na ostream je super věc a kdo si to komplikuje používáním rodiny fcí print je v 90 % blázen, nebo to nepochopil…

[Luboš Doležel (Doli)]

Na kejkle typu %.02f mi přišlo printf vždy zapamatovatelnější (a hlavně míň ukecané).

[Šangala]

Zapamatovatelné - je subjektivní, skoro vždycky se musím dívat do nápovědy protože si nepamatuji všechny formátovací znaky - je jich roj, což při používaní << není třeba si nic pamatovat (nebo velmi málo).
Míň ukecané - v případě jednoho základního typu/čísla může být. Ale když se jedná o vektor (3-4 čísla) nebo o matici (3×3, 4×4), datum, telefonní číslo, či nějakou strukturu atd. tak je jednoznačně lepší mít správně přetížený operátor <<.
Když je pak výstup namixovaný, jak se co hodilo, je to opravdu radost.

[Luboš Doležel (Doli)]

Vám opravdu přijde

cout << setiosflags(ios_base::fixed) << setprecision(2) << x << setprecision(0);

jako hezčí oproti

printf("%.02f", x);

To se mi nechce ani věřit.

Přetěžování operátoru << je dost jednoúčelové, přijde mi lepší mít u objektu něco, jako je obvyklý javovský toString().

[Šangala]

Nepřije a takto není.
Ale to je to, pokud se jedná o jedno číslo a jen jednou, tak to není kratší, jenže ono to kouzlo je jinde, podívejte se třeba na tento zdrojový kód, je dlouhý, ale zas to hezky vynikne.

#include <iostream>
#include <float.h>

int main(int argc, char **argv) {
  std::cout.precision(FLT_DIG);
  std::cout.flags(std::ios::scientific);
  std::cout << "float:" << std::endl;
  std::cout << "              min: " << FLT_MIN << std::endl;
  std::cout << "              max: " << FLT_MAX << std::endl;
  std::cout << "  10 exponent min: " << FLT_MIN_10_EXP << std::endl;
  std::cout << "  10 exponent max: " << FLT_MAX_10_EXP << std::endl;
  std::cout << "           digits: " << FLT_DIG << std::endl;
  std::cout << "          Epsilon: " << FLT_EPSILON << std::endl;

  std::cout.precision(DBL_DIG);
  std::cout << "double:" << std::endl;
  std::cout << "              min: " << DBL_MIN << std::endl;
  std::cout << "              max: " << DBL_MAX << std::endl;
  std::cout << "  10 exponent min: " << DBL_MIN_10_EXP << std::endl;
  std::cout << "  10 exponent max: " << DBL_MAX_10_EXP << std::endl;
  std::cout << "           digits: " << DBL_DIG << std::endl;
  std::cout << "          Epsilon: " << DBL_EPSILON << std::endl;

  std::cout.precision(LDBL_DIG);
  std::cout << "long double:" << std::endl;
  std::cout << "              min: " << LDBL_MIN << std::endl;
  std::cout << "              max: " << LDBL_MAX << std::endl;
  std::cout << "  10 exponent min: " << LDBL_MIN_10_EXP << std::endl;
  std::cout << "  10 exponent max: " << LDBL_MAX_10_EXP << std::endl;
  std::cout << "           digits: " << LDBL_DIG << std::endl;
  std::cout << "          Epsilon: " << LDBL_EPSILON << std::endl;

#if defined FLT_ROUNDS
  std::cout << std::endl;
  std::cout << "Type of rounding floating numbers: ";
  switch(FLT_ROUNDS){
    case -1 : std::cout << "indeterminable"; break;
    case  0 : std::cout << "towards zero"; break;
    case  1 : std::cout << "to the nearest number"; break;
    case  2 : std::cout << "towards positive infinity"; break;
    case  3 : std::cout << "towards negative infinity"; break;
    default : std::cout << "? - no standard definition"; break;
  }
  std::cout << std::endl;
#endif

  return 0;
}

a vynikne to, že kód je stejně čitelný jako jeho výstup. Styl formátovaní lze nastavit jen 1×, ne opakovaně pro každé číslo. Pak se jedním přepnutím formát všech čísel změní dle potřeby.

A když si představíme třeba vektor:

//trhlé zobáčky
cout << v << endl;
//print metoda to string
printf("%s\n",v.toString().c_str());
//printf po jednom
printf("%.02f,%.02f,%.02f\n",v.i,v.j,v.k);
//nebo
printf("%.02f,%.02f,%.02f\n",v.getI(),v.getJ(),v.getK());

Obecně metoda toString() je trochu něco jiného, ta pracuje se stringem, ale zobáčky se stream-em a ten může být cokoliv, string, stdout, stderr, soubor…, takže zaměněním std::cout za ukazatel typu std::ostream, jedním přehozením ukazatele zapisujete do souboru nebo na stdout, nebo cpete data do parseru, je to daleko flexibilnější.

[l4m4]

Nikdo se nepře, že možnost definovat I/O operátory pro libovolné třídy je velmi užitečná, obzlášť je-li člověk zaměřen na to, aby bylo všechno pěkně objekto-frameworkovité, což programátoři v C++ zjevně jsou, a proto si ten jazyk i vybrali.

Nelze ovšem ani popřít, že i při vypsání intu nebo doublu z toho zbytečně na všechny strany trčí frameworky a pochybná přetížení operátorů, což člověka, který je zvyklý vypisovat[*]

print x

nadchne stěží.

Uvedený příklad je vtipný, protože (a) v C lze napsat přinejmenším stejně čitelně (b) polovina využívá velké zlo z C, tedy preprocesor (všechna ta FLT_xxx jsou jakási makra, nemají žádný namespace, prostě hrůza hrůzoucí).

[*] Taky funguje s libovolnou třídou.

[Šangala]

Nepřu se s Vámi a nadchnout kohokoli, mě popravdě nenapadlo ... sorry
Že jsou makra preprocesoru zlo, to víme, to slyšíme pořád, ale že by zrovna tato makra bylo nějak zlá, že by měla nějaký vliv na uvedenou problematiku. Prostě jsem použil program na výpis, některých parametrů datových typů s plovoucí desetinou čárkou.

[Ondra Holub]

Hezčí to možná není, ale zase nemusím pečlivě prohledávat všechny výstupy, pokud v rámci nějakého refaktoringu musím změnit vypisovaný typ, protože se to zapíše vždycky stejně.

Nebo pokud musím pracovat s typy pevné velikosti, tak pro výpis přes printf se musí ve formátu používat nějaké ty divoké

PRIx64

apod., což tu čitelnost a stručnost trošku zhoršuje.

Ale ať si každý používá, co chce. Čím víc se toho musí opravovat (a je jedno, jestli zbytečně, nebo odůvodněně), tím více je pro nás práce

[l0gik]

Ehm: vytáhl jste jediný případ, kdy se to vcelku dá používat. Jenže je hromada dalších případů, kdy je to jak drbat se levou rukou za pravym uchem, např.:

- chci střídat formát výstupu (ne vše potřebuju na stejný počet desetinných míst)

- jeden typ objektu má dvě možné řetězcové reprezentace

- formát výstupu se neřídí samotným objektem, ale něčím z vnějšku

- potřebuju sypat různé hodnoty do předpřipravených šablon (genialita printf)

- potřebuju skládat data "nelineárně"

atd...

Koneckonců: to, že nejde o dobrý koncept je naprosto jasné z toho, že žádný z jazyků, který po C++ vznikl, tento koncept univerzálního vstupního a výstupního operátoru nepřebral. Myslím, že praxe je nejlepším kritériem pro to, co je povedený a nepovedený "návrhový vzor".

[Šangala]

- chci střídat formát výstupu (ne vše potřebuju na stejný počet desetinných míst)

Ano, pokud musíte střídat nastavení výstupu čísla, napíšete toho více. Ale setkávám se daleko častěji s opačným požadavkem.

- jeden typ objektu má dvě možné řetězcové reprezentace

Popravdě toto jsem čekal jako první námitku, ale řešení je identické jako když máte metody toString() a podobné, prostě předem přepnete formát výstupu. Nemyslím, že je to cout vs. printf, protože to řeší daný objekt interně a je sám odpovědný za formát výstupu. To je prostě jiný problém.

- formát výstupu se neřídí samotným objektem, ale něčím z vnějšku

Tak buď je to zodpovědnost toho objektu nebo jiného objektu a když je to „nedefinovné“ skládání „něčeho“ venku, tak ano asi si napíšete toho více, ale je otázkou, jestli když se bavíme o C++, není-li někde chyba návrhu (netvrdím, že je), ale jste ve stejné situaci a je jedno jestli to sypete pomocí cout nebo printf, krom toho, že platí „námitka“ první.

- potřebuju sypat různé hodnoty do předpřipravených šablon (genialita printf)

Souhlasil bych, kdyby byly parametry očíslovány.

- potřebuju skládat data "nelineárně"

Nevidím asi rozdíl, malý příklad by nebyl?

Neřekl bych, že se to řídí tak jednoduchými principy, řekl bych totiž (nebijte mě), že mezi programátory v C++ je tento koncept oblíbený.

[l0gik]

formát: nu, já třeba v matematických aplikacích to řeším - často pro různé kontroly chci zběžně zkouknout hodně čísel na pár desetinných míst.

reprezentace: pokud mám výstup z objektu řešený pomocí metody toString(), není problém tuto metodu rozšířit o další parametr s implicitní hodnotou popisující styl výstupu. Rozdíl oproti přepnutí formátu výstupu je ten, že přepnutí formátu je globální změna, ovlivňující další chování programu, což je věc veskrze zavrženíhodná. Takové věci pak aby prase ladilo.

řízení z vnějšku: Např. objekt má svůj krátký a dlouhý název. Který z názvů chci vysypat pak samozřejmě neví ten objekt, ale jeho klient (např. u seznamu objektů stejného typu ho chci bez typu, u různých objektů s typem apod. Ve výsledku to vede k tomu, že rezignuji na operátor << objektu a do coutu stejně posílám jen stringy.

printf: ano, s tím souhlasím, očíslování argumentů schází. Pořád to je ale věc, kterou lze v procedurálním stylu dopsat. V streamovém stylu to prostě nenapíšu, nejsou na to vhodný výrazový prostředky. Ve výsledku to povede k tomu, že jeden objekt bude mít jak metodu toString (abych ho moh implementovat do šablon) tak i operátor <<, což je zjevná duplicita.

nelineárně: no do coutu těžko pošleš nejdřív konec výstupu a pak začátek, stejně tak do stringstreamu. U skládání stringů snadno string předřadíš před zbytek (a máš-li inteligentní řetězce, tak i levně). Takže opět člověk skončí u toho, že si nejprve poskládá celej výstup (řádku) a tu pak vyplivne najednou.

Operátor << se IMHO hodí na rychlé vypsání věcí, u kterých tak nezáleží na kvalitě prezentace: prostě chci něco vysypat, napsat to co nejrychlejc, a nezáleží mi na tom, jak to bude vypadat. Pokud ale chci složitější věci, tak je najednou spousta věcí přes ruku....

[Šangala]

formát: nu, já třeba v matematických aplikacích to řeším - často pro různé kontroly chci zběžně zkouknout hodně čísel na pár desetinných míst.

No a právě tady mi to připadá super, bo vysypu celou matici, vector nebo cokoliv hned a je klid…

reprezentace: pokud mám výstup z objektu řešený pomocí metody toString(), není problém tuto metodu rozšířit o další parametr s implicitní hodnotou popisující styl výstupu. Rozdíl oproti přepnutí formátu výstupu je ten, že přepnutí formátu je globální změna, ovlivňující další chování programu, což je věc veskrze zavrženíhodná. Takové věci pak aby prase ladilo.

To beru kompletně (jakože souhlasím).

nelineárně: no do coutu těžko pošleš nejdřív konec výstupu a pak začátek, stejně tak do stringstreamu. U skládání stringů snadno string předřadíš před zbytek (a máš-li inteligentní řetězce, tak i levně). Takže opět člověk skončí u toho, že si nejprve poskládá celej výstup (řádku) a tu pak vyplivne najednou.

Ale to je stejné i s printf-em. Když je třeba čupr formát, tak to stejně lze akorát poskládat do string-u a je docela jedno kterou funkcí a zas lze používat oba přístupy, ale já rozhodně ten string pak vysypu pomocí << .

Operátor << se IMHO hodí na rychlé vypsání věcí, u kterých tak nezáleží na kvalitě prezentace: prostě chci něco vysypat, napsat to co nejrychlejc, a nezáleží mi na tom, jak to bude vypadat. Pokud ale chci složitější věci, tak je najednou spousta věcí přes ruku....

Ano, určitě to není, stejně jak fce printf, na nějaké složité a třeba i uživatelsky definované formátování, to si každý musí stejně napsat sám a může pro to použít jak stream, tak printf nebo třeba itoa . Ale myslím, že i na „střední třídu“ se to hodí a pokud jsou classy dobře navržené, lze to rozumně skládat a vrstvit na sebe…

[l0gik]

No ale v podstatě tady se mnou souhlasíš s tím, že se to hodí jen na rychlý vyplivnutí objektů a na složitější formát je třeba skládat řetězce.

V tu chvíli ale musím mít u objektu dvě identické funkce, jen jedna plive do streamu a druhá vytváří řetězec (stringstream na pohodlné skládání složitějších věcí z výše popsaných důvodů použít nelze). Takže duplicita, kterou dost lidí z pochopitelných důvodů nemá rádo (byť toto jde vcelku rozumně vyřešit nadefinováním jednoho rozhraní a přetížením operátoru << na toto rozhraní).

Navíc velmi často nejprve stačí jednoduchej výstup a až v průběhu času člověk zjistí, že na danym místě je potřeba výstup složitej. Pokud člověk začne s výstupem pomocí << a najednou zjistí, že je to třeba vysipat nějak složitějc, buď dohromady zamíchá oba dva způsoby, což je nečitelné, nebo to musí celé přepsat. Nedivím se teda lidem, že to hned na začátku dělaj "univerzálně".

[Šangala]

Říkám opatrně ano (na první odstavec), ale i v duchu dalšího odstavce, jak moc to souvisí s fcí printf či cout?
Když skládám data, tak i když je skládání ve výsledku nelineární, tak jednotlivé sekvence jsou lineární a výsledek je také lienární (neberu-li v potaz, že můžeš lítat v souboru tam a zpět jak Čestmír ), takže lze použít jakoukoliv metodu skládání.
Sorry, ale já to úplně nechápu. Co je universálnějšího na fci printf oproti << (>>), printf prostě sype rovnou na stdout, a << může sypat kamkoliv.
Já se těm lidem, sobě, tobě taky nedivím, ale udělat to universálně rozhodně neznamená používat printf, to přece znamená udělat nějaký „formátovač“ a když všechny položky v něm používané budu mít správně nadělané <<, tak je radost jej poskládat (byť se třeba musí použít nějaké buffery díky zmiňované nelinearitě), ale ano může se to udělat i pomocí printf, ale pak to opravdu vyletí jen na stdout, nebo z toho vyplivneš megastring (nepříjemná fce sprintf), ale to je opravdu zas jedno jestli ho pošleš ven přes %s nebo <<.
Jinak ano operátor << může používat fci toString() ale je to super, když se na to nezapomene, protože pak se to musí psát furt znovu.
PS: Fce printf má jednu nespornou výhodu, je o kus rychlejší, což při GiB dat může být zajímavé…

[kuka]

BTW pomoci printf, lepe receno funkcemi z "rodiny" printf lze pochopitelne zapisovat i jinam nez na stdout.

[Šangala]

Já to vím a svou znalost jsem prezentoval větou „nebo z toho vyplivneš megastring (nepříjemná fce sprintf)“
Ale těžko přehodíte výstup z stdout do souboru jedním krokem.

[kuka]

Dopln tedy svou znalost o fprintf

[Šangala]

A mám to , když jsem to psal nedošlo mě, že přes fprintf můžu i na stdout atd. a popravdě kdybych to psal (jakože rodinu printf nepoužívám už 300let), tak bych dělal nějaký switch a volal printf nebo fprintf.
Ale to je snad jediné, do stringu nebo úplně jinam to stejně nejde