C++0x

31.10.2008 14:44 | Jiné

Konečně byl dokončen návrh C++0x. GCC již má pro něj jakousi počáteční experimentální podporu, ale spousta věcí stále chybí. Snad se v blízké budoucnosti dočkáme (GCC 4.5? ). Co nového bude v C++0x se dočtete např. na wikipedii.

       

Komentáře

[Darth Phantom]

Bezva Jardo, ale myslím že to stačilo zadat jenom jednou

[Leoš Literák]

Smazano, nez tam pribude nejaky komentar ..

[Jardík]

Jak zadat jednou, se to postnulo víckrát? Vždyť napoprvé byl náhled a potom publikovat, které jsem snad dvakrát neodkliknul, i když s tím novým noťasem a nezvyklý na touchpad se mi to stát mohlo.

[Luboš Doležel (Doli)]

Mohlo a stalo

[msk]

Hmm zaujimave. Niektore veci maju fakt zmysel, skoda len, ze som uz od c++ viacmenej utiekol prave kvoli jeho uzkoprsosti. Mat tak tieto vlastnosti pred takymi 5 rokmi, situacia by bola mozno trochu ina.

BTW nikde som sa nedopatral, ci uz napriklad taky fstream konecne zacne akceptovat string namiesto const char*. Bolo dost trapne mat v std:: classu na stringy, ktoru vlastne nikto z jej vlastneho namespace neakceptoval :)

[David Watzke]

Ty krávo, to jsou zvěrstva To se mi líbí...

[Jardík]

No mně se tam hlavně líbí lambda, budou se s tím dát dělat prasárničky, což mám rád

[David Watzke]

Taky jsem se u toho zarazil, to je fakt hardcore. Pak se mi líbí taky ten "foreach" ve stylu:

int my_array[5] = {1, 2, 3, 4, 5};
for(int &x : my_array)
{
	x *= 2;
}

[Jardík]

Ten je prakticky okopírovanej z javy (až na to, že u javy to "x" není reference), tak ho tu moc neukazuj, ať neřáděj

[Ladicek]

V Javě ho zase zkopírovali z C#, a co. A v případě referenčního typu je samozřejmě x reference

[Jardík]

No ale obyčejný int byste tam nezměnil, protože ten referencí nebude a Integer je pomalej A v C# je snad foreach: foreach(int i in pole_intu)

[Ladicek]

No ale obyčejný int byste tam nezměnil, protože ten referencí nebude a Integer je pomalej

Integer bych taky nezměnil, protože je neměnitelný A objekt samotný nevyměním nikdy. Což je asi to, co jste myslel tou referencí. Sakra, vždycky zapomenu, že C++ má hodnotové objekty.

A v C# je snad foreach: foreach(int i in pole_intu)

Ále, syntaktická drobnost, prostě v Javě nechtěli zavádět nová klíčová slova. Jinak je to lautr to samý. Hm, teď si nejsem jistý, jestli sýšárpí foreach kontroluje na null, javovský ne a občas mne to pěkně točí.

[Jardík]

"nullové" prvky toho pole se samozřejmě také v iteracích objeví (pokud tam jsou), protože to prostě jsou prvky pole.

[kralyk z abclinuxu]

jj to je pěkné, i když je to spíš frajeřinka...

[Ladicek]

Cože, lambdy v C++? No to mi rve koule. A my javisti pořád nic, ach jo.

[deda.jabko]

a anonymni tridy nestaci?

[Ladicek]

Ale no jo, ono to funguje i s anonymníma třídama. Ale toho syntaktického balastu okolo… A iterátorové metody by nám do kolekcí asi stejně nepřidali (pokud se neprosadí i rozšiřující metody), no prostě je to v háji

[Jakub]

v gcc podobna vec jde uz celkem dlouho

[Jardík]

Cože? Vždyť jsem dal link, na který když se podíváte, zjistíte, že na lambdě se teprve v GCC pracuje (Under development).

[Jakub]

Rozumite slovu "podobne"? Gcc nyni prelozi toto:

bar (int *array, int offset, int size)
{
       int access(int *array, int index){return array[index+offset];}
       int i;
       /* ... */
       for (i = 0; i < size; i++)
               /* ... */ access (array, i) /* ... */
}

[Jardík]

Hustý. Ale neodpustím si rejpnutí - jenom čunča použije int pro index místo size_t. Jenže oni se tak čuňácky chovají i ostatní, např. Adobe díky tomu nevydá 64bit flash a vymlouvá se na "malý zájem", protože by stačila pouhá rekompilace v řádu několika minut.

[Luk]

Ale neodpustím si rejpnutí - jenom čunča použije int pro index místo size_t.

Do této kategorie spadá cca 95 % programátorů. Též většinou používám int (někdy též unsigned - podle toho, k čemu všemu ten index používám) místo size_t, přestože size_t používám častěji než většina programátorů.

[Deleted [8409]]

Vidíte, já jsem vždycky používal ulong s tím, že by to měl být stejně velký typ jako pointer a MSVC mě nějak zklamal (První mě upozornil Jarda ) Od té doby používám sysint_t a sysuint_t. size_t byl sice na mušce dřív, ale někde jsem se dočetl, že některé překladače ho mají znaménkový, což je podle mě šílené :)

[Luk]

některé překladače ho mají znaménkový, což je podle mě šílené

Je otázka, jestli je to šílené. Za dobrý nápad to nepovažuji (pro použití se znamémkem mám ssize_t), ale protože size_t má sloužit pro uložení velikosti a související účely (a ne pro něco jiného), není to až takový problém (když nepočítám poloviční rozsah).

[depka]

jenom čunča použije int pro index místo size_t

co je na tom čunčovskeho?

[Jakub]

Postezujte si vyvojarum gcc, ten priklad jsem okopiroval z dokumentace :-P

[:::]

> jenom čunča použije int pro index místo size_t

- tak to je snad ta nejvetsi kravina kterou jsem kdy slysel...

> Adobe díky tomu nevydá 64bit flash

- a to je druha nejvetsi...

int na 64bit platforme urcite nebude mensi nez na 32bit, takze pokud ho pouzivaji na index tak to nemuze zpusobit zadny problemy... (pokud by ho treba pouzivali ve strukturach ktery potom ukladaji do souboru tak by to asi problemy delalo, ale to uz je neco trochu jinyho)

[Deleted [8409]]

To kravina právě není. Na 64 bit platformách by se měl jako index vždycky používat 64 bitový typ, protože ten 32 bitový vám nemusí pokrýt všechny možnosti (u 32 bitových platforem to ten UNSIGNED int pokryje). To ale nic nemění na tom, že toto nědělá skoro nikdo, a ti co pak ty zdrojáky opravují, musí zuřivě prskat, když něco takového vidí.

Ty typy nevznikly pro srandu, mají své důvody.

Stačí když vidím třeba toto:

char* a = ...;
int i = strlen(a);

a zabíjel bych :)

[Luboš Doležel (Doli)]

To vážně očekáváte, že ten řetězec bude mít víc než 2^31 znaků? Podle mě je to prakticky úplně jedno.

[Deleted [8409]]

No někdy je lepší nic neočekávat:) V tomto kódu je to hodně nevinné, ale představte si, že toho třeba využije potenciální útočník a předsune vám speciální data. Buffer útoky jsou celkově zajímavé.

[kralyk z abclinuxu]

od aničky sem se naučil linkovat tohle :P

[zde]

ale představte si, že toho třeba využije potenciální útočník a předsune vám speciální data.

No, pokud by mi potenciální útočník chtěl během těch 30min, co denně sedím doma u PC, podsunout 4+GiB dat, musel by mi napřed navýšit downlink z 2Mbps na nějaké FTTH, takže takový útok bych a) včas zaregistroval b) docela uvítal.

[Luk]

Stačí když vidím třeba toto: ... a zabíjel bych :)

Tohle je většinou zcela neškodné. Horší jsou legrace tohoto typu:

unsigned char c = ...
const char* s = ...

if (s[0] > c) { ... }

Kompilátor samozřejmě vyhodí warning, jenže lidé ho ignorují a tuto čuňárnu tam s klidným svědomím nechají.

[:::]

tak tohle me nenapadlo, ale pripoustim ze to problem je

ale ten flash by to stejne ohrozit nemelo, protoze pochybuju ze tam nekde maji potencialne vic nez 2e9 polozek aby to mohl byt problem.

[Jardík]

Ale když už ten "čunča" je schopen použít int na indexy, tak bych se nedivil, kdyby pointer přetypoval na int a to pak už je hodně velkej průser, když aplikace obdrží paměť nad 4GB (to býval např. problém 64bit creative ovladačů na vistu, kdy fungovaly pouze když měl člověk < 4GB paměti).

[depka]

neni nahodou int prirozeny typ dane architektury? tudiz na 64bit arch ma 64bit? nebo jsem to blbe pochopil?

[:::]

obecne nemusi. gcc ma treba int 32 bitovy i na 64b platformach

[zde]

Logicky by to tak být mělo, protože např. kompilátory pro 8bit jednočipáky klidně měly sizeof(int)==1, jenže není. Když z nebe spadlo 64 bitů, bylo třeba vybrat co se (krom pointerů, samozřejmě), změní na 64 bitů. Unix vybral cestu LP64, podle mě z nepochopitelných důvodů. Windows použilo LLP64, který je IMHO drobet logičtější. Nejpřirozenější a pro bezpečnost nejlepší je samozřejmě ILP64, jenže ten se skoro nepoužívá.

http://www.unix.org/version2/whatsnew/lp64_wp.html

[Deleted [8409]]

Myslím, že ve Windows zvolili to LLP64 spíše z historických než logických důvodů. Mi osobně se víc líbí to LP64, ale je to individuální. O důvod víc používat typy jako int8_t, int32_t, int64_t ;)

[zde]

Souhlas, inttypes.h tu mělo být mnohem dřív. LLP64 má tu výhodu že sizeof(short) a sizeof(long) jsou pořád v tom "správném" poměru 1:2 .-)

[Jardík]

Jenom škoda, že msvc hlavičkový soubor <inttypes.h> nemá a musí se ručně udělat typedef.

[zde]

Co je to msvc?

[Boris Dušek]

Microsoft Visual C++

[luky]

Prostě nemáš ponětí o tom, co je index, ale stejně nás musíš informovat ;)

[kralyk z abclinuxu]

Neví někdo, jak to bude s přetěžováním operátorů?
páč když mám třeba třídu která obsahuje nějaké to operator++(...)
a pracuju s tou třídou jako Class * c = new Class; tak se pak ty operátory špatně volaj že, de to snad jen přes friends, mám dojem, ale je to dost takový kostrbatý, řeší C++0x nějak tohle? Nebo se to dá ňáko vyřešit i normálně v C++?

[Let_Me_Be]

To samozrejme nebude fungovat nikdy protoze nad ukazateli jsou definovane aritmeticke operace. Jinak co je na tom tak hrozneho? Je to jenom jeden znak navic.

[Jardík]

(*c)++, ++(*c).

---- Mimo mísu ---

Nedávno nám na přednášce z algoritmizace náš přednášející (nevím, jak se jmenuje, ale nesnáší C/C++ a minule seřval jednoho studenta, ať do javy netahá jeho praktiky, jako if (cislo = x) {} a že musí if ((cislo = x) != 0) {}) ukazoval algoritmus na výpočet největšího společného dělitele. No co, trochu jsem ho upravil do přehlednější podoby :

int nsd(int x, int y)
{
  for (int zbytek = x%y; zbytek != 0; x = y, y = zbytek, zbytek = x%y);
  return y;
}

[podlesh]

nevím, jak se jmenuje, ale nesnáší C/C++ a minule seřval jednoho studenta, ať do javy netahá jeho praktiky, jako if (cislo = x) {} a že musí if ((cislo = x) != 0) {})

To bylo, pravda, od něj amatérské. Měl toho studenta nechat seřvat kompilátorem. Ušetřil by si hlasivky a navíc by někteří studenti nezískali dojem, že oddělení celočíselných typů a typu boolean je "praktika".

Co se týká for cyklů bez těla, tak někteří lidé toto nemají rádi ani v C a zastávají názor že cyklus má mít vždy tělo - kvůli přehlednosti zdrojáku. Někdo kvůli tomu definuje makro. Osobně nejse zastáncem - pokud udržuji zdroják automaticky formátovaný (cindent, astyle) tak se na bug se zapomenutým středníkem rychle přijde a jinak je to jedno.

[:::]

> Měl toho studenta nechat seřvat kompilátorem.

tohle me na jave vzdycky pekne prudilo. Ze ten kompilator si mysli ze je chytrejsi nez ja a porad do neceho zvani...

[Luk]

Lepší když řve kompilátor, než když pak řve uživatel, kterému padá program, který "přece bez problémů fungoval".

[default]

Kompilátor Javy (konkrétně ten od Sunu), vůbec ukecanej nejni a to i s -Xlint. Takže jestli ti do díla předčítal jeho pohádky, pak to bylo proto, že jsi mu dal příležitost

[:::]

>pak to bylo proto, že jsi mu dal příležitost

prilezitost jsem mu ani moc nedaval, ale byl stejne strasne preplnenej rozumama . Nevim co me ma treba kompilator co kecat do toho jestli osetrim nejakou vyjimku nebo ne...

Kdyby to vyhodil jako warning tak to pochopim, ale error a dupat a prskat dokud to neopravim to je vazne prehnany...

[default]

Ano, cítím v tom jisté diskriminační praktiky. Ale ber to z druhé strany: když ho přijmeš takovýho, jakej je, půjde ti naproti a pomůže ti. To se mi na klukovi líbí Je to jako v partnerském životě: jednou nedá on, příště zase ty

[luky]

Když partner/-ka nedává, tak se vymění

[podlesh]

> Měl toho studenta nechat seřvat kompilátorem.

tohle me na jave vzdycky pekne prudilo. Ze ten kompilator si mysli ze je chytrejsi nez ja a porad do neceho zvani...

Už jsem viděl přisuzovat Javě ledasjaké vymoženosti: virtual machine, bytecode, OOP, garbage collector, atd. Ale aby někdo považoval za zvláštnost, že si kompilátor stěžuje na chybu syntaxe --- to jsem ještě neviděl. Dávám +10 bodů za originalitu.

[:::]

az na to ze if (cislo = x) {} neni chyba SYNTAXE.

Java ma spoustu zbytecnych omezeni (treba tohle ze cislo je nekompatibilni s bool, nebo ze se musi osetrit vyjimky, atd) ktery ti pri programovani nijak nepomahaj, ale jenom otravujou...

[Ladicek]

az na to ze if (cislo = x) {} neni chyba SYNTAXE.

Jasně že je. Nebo jaká je to teda chyba, když ne syntaktická, že namísto == je tam napsáno =?

[msk]

Programatorska. Syntakticky je to spravne.

[:::]

to jednoduchy = je tam ale (predpokladam) schvalne.

cislo = x priradi 'x' do 'cislo' a vrati hodnotu 'x' a ta se ma pak vyhodnotit jako true/false. Problem ale je ze v jave je int a bool nekompatibilni. Proto to spadne (ne proto ze je tam jednoduchy rovnase, ale proto ze se vlastne ptas jestli ten int je true).

Takze jednoduse receno - chyba je to SEMANTICKA.

A to me mimochodem na jave tak prudi - ze ma zbytecny semanticky omezeni.

[default]

A to me mimochodem na jave tak prudi - ze ma zbytecny semanticky omezeni.

Hele. A on tě někdo nutí v tom něco dělat? Si vyber jiný jazyk (patrně bych se být tebou podíval na Perl či PHP ). Mě taky nikdo nenutí po nocích na serveru "gédébéčkem" debuggovat C++. A až se někdo takový najde, tak půjdu o dům dál.

[:::]

ted uz nastesti ne (zivi me c++) ale ve skole sem s tim parkrat delat musel a nebyl to prijemnej zazitek...

[Ladicek]

Ukazuje se, že if (cislo = x) je prakticky vždy myšleno jako if (cislo == x), čili to lze interpretovat i jako syntaktickou chybu, ačkoliv odhalenou až ve fázi sémantické analýzy

Problem ale je ze v jave je int a bool nekompatibilni.

To bohudíky není problém, nýbrž vlastnost. Mně osobně vadí i to, že přiřazení je v Javě výraz a má hodnotu. Proto mimochodem lze napsat if (x = y), pokud x a y jsou boolean, což je naprosto ideální způsob, jak vyrobit záhadnou chybu.

[:::]

> Ukazuje se,...

a byl by link na nejaky vizkum ktery to ukazuje ? Na fraze typu 'research shows' je potreba byt velice opatrny. Podle mych zkusenosti si jsou programatori rozdilu mezi = a == velice dobre vedomi a nepamatuju si ze bych nekdy videl chybu toho typu

> To bohudíky není problém, nýbrž vlastnost. Mně osobně vadí i to, že přiřazení je v Javě výraz a má hodnotu. Proto mimochodem lze napsat if (x = y), pokud x a y jsou boolean, což je naprosto ideální způsob, jak vyrobit záhadnou chybu.

tyhle ruzny omezeni zachyti jenom velmi maly procento chyb, ktery pri trose soustredeni stejne neudelas. Na druhou stranu daji ale programatorovi jakysi pocit robustnosti a ten pak mnohem snadneji prehledne 'skutecny chyby'...

[default]

Hele, po letech vývoje v Javě musím říct, že možná ta omezení jsou pro někoho nepříjemná, ale podle mě jsou nutná. Všechny zdrojové kódy díky těmto omezením vypadají stejně a není tedy problém se vyznat v cizím kódu. Pro udržování kódu jsou tato omezení velkým přínosem. Ale je to můj pohled na věc. Nic víc, nic míň.

[Jardík]

Stejně ... já si musel překopat netbeans tak, aby mi složený závorky po if, while, for, class, atd. dával na nový řádek a odsazuji tak, jak to mám rád a jsem naučen z C++ a věřím, že to pana vyučujícího irituje, když jsou všechny zdrojáky stejně odsazovaný a jen ten můj je extra. Taky kouká ošklivě na zápisy typu while (--i != 0) a že to mám dát do těla cyklu a ve while testovat to i ... ale je to správně a tak mi za to body sebrat nemůže a já na něj to. A pak ho taky štve, že mu úkoly balím v tar.bz2 a jednou i v tar.lzma (soudě podle toho, že se mě na hodině ptal, jestli to balím v linuxu, ale i když jsem to balil ve win, tak jsem mu řekl, že jo, aby neměl keci, že mu mám vytvořit zip )

[Ladicek]

Na fraze typu 'research shows' je potreba byt velice opatrny.

To je pravda. Stejně tak ale na fráze typu podle mých zkušeností. K dokonalosti to dotáhl tuším Gilad Bracha, který v jednom zápisku ve svém blogu tvrdil, že se nikdy nesetkal s problémem způsobeným tím, že ve Smalltalku aritmetické výrazy nerespektují běžné priority operátorů. Což mu prostě nežeru

Wikipedie např. tvrdí, že This is a common programming problem with languages such as C, where the assignment operator also returns the value assigned nebo Expression-orientation can be confusing in imperative programming languages. Ačkoliv nejde o žádný autoritativní zdroj, já bych s tím celkem souhlasil.

Na druhou stranu musím přiznat, že v jiných situacích je skutečnost, že přiřazení je výraz, zase docela užitečná. Holt si nevyberu. Ale v tom ifu je to pakárna, která se fakt blbě čte. Aspoň že v té Javě je potřeba přidat explicitní porovnání, takže je jasně vidět, že jde o úmysl.

[podlesh]

No, dobře, není to chyba syntaktická, je to chyba statické typové kontroly.

Pointa je ale v tom, že prostě definice jazyka jasně specifikuje, že výraz v příkazu if musí být typu boolean. Zda je to zbytečné nebo ne je vcelku irelevantní, prostě tomu tak je.

A světe div se, Java není ani zdaleka první jazyk který toto vyžaduje. A není ani poslední.

[:::]

ja se ale nehadam o tom jestli to je kvuli definici jazyka nebo jestli se me ten kompilator jen chtel pomstit za vsechny hrichy sveta

ja jenom rikam ze tahle 'vlastnost' je pekne iritujici...

[podlesh]

Já se nechci hádat o tom která vlastnost jazyka je iritující nebo není. Člověk na kterého jsem reagoval prostě označil nezkompilovatelný kus kódu jako "praktiku".

[zde]

Hezké, leč z hovna bič neupleteš. :) Vzbuďte mě až tam bude GC.

[Let_Me_Be]

Garbage collector primo v jazyku? Boze, at se tam nikdy takova blbost nedostane. Na co by ti to bylo? Mame automaticke ukazatele a kdyz uz nic, tak mas spoustu knihoven, ktere poskytuji ruzne Garbage collectory.

[depka]

jak muze byt GC v jazyku pouzivajici ukazatele?

[deda.jabko]

a proc by nemohl?

[depka]

kdyz mi gc znici objek na ktery mam nekde schovany ukazatel, co se stane jakmile ho budu deferencovat?

[Ladicek]

No, tak přesně to konzervativní GC neudělá

[Let_Me_Be]

V C++ je GC principielne nanic, protoze mame chytre ukazatele. Proste si GC v C++ predstav jako uloziste chytrych ukazatelu, ktere umi jeste alokovat objekty na stacku a dealokovat je po skupinach.

[Ladicek]

Chytré ukazatele, pokud se nepletu, implementují počítání referencí, jest tak? Pokud ano, tak bych si dovolil upozornit, že to je asi tak nejhorší technika GC, která existuje

[Let_Me_Be]

No, to zalezi na tom jaky chytry ukazatel pouzivas.

[Ladicek]

No, jen jsem teď trošku potrápil Google a z webu Boostu jsem se dostal k tomuhle článku. Vypadá to zajímavě, a co jsem to tak rychle prolítnul, moc hezky se tam o chytrých ukazatelích nevyjadřují

[Miloslav Ponkrác]

V C++ je GC nanic. GC totiž dělá práci jenom napůl. GC pouze uvolňuje paměť a pak se řeší různé obezličky, jak korektně a pokud možno včas uvolnit i jiné prostředky, například zavřít soubory, uvolnit handly, atd..

V C++ je prostě jiný způsob práce - a namísto GC je tam RAII koncept, který vykryje v běžném programu 99% situací, kde třeba v Javě, Pythonu, C#, či jinde musel zasahovat GC, a navíc uvolní nejenom paměť, ale i cokoli jiného. Jako bonus se objekt uvolní okamžitě, když je to potřeba a s menší režií.

Pro zbylé účely jsou automatické ukazatele, které nedělají nic jiného, než že převádějí ukazatel na RAII koncept, a ten to uvolní za ně. Jejich efektivita je různá podle implementace.

Jinak programuji v C++ od té doby, co vzniknul. Ale za posledních x let si ani nepamtuji, kdy jsem v C++ uvolňoval ručně paměť, tedy použil delete, delete[], nebo free. Prakticky jsem zapomněl, že existují tyto možnosti.

Pokud bych přesto všechno GC v C++ chtěl (jakože je tam při dobrém programování - tedy kdy programujete v C++ jako v C++, ne když se před týdnem přeučený Céčkař považuje za mistra světa v C++ - při dobřém programování v C++ je GC zcela zbytečná věc). Tak pokud bych GC chtěl, je k dispozici jako knihovna a existují i projekty v C++, které jsou založeny na uvolňování paměti pomocí GC. Takže GC v C++ nechybí, chcte-li, můžete ho tam mít, ale s přirozenými prostředky C++ je tam zbytečné.

[Ladicek]

Hmm, tohle je zajímavé. Vždycky jsem považoval alokování objektů na zásobníku za prasárnu, ale koukám, že se z toho dají vyždímat i velmi zajímavé vlastnosti.

[Deleted [8409]]

Alokování na zásobníku se dělá pro maximální výkon. Dynamická alokace paměti je totiž mnohem pomalejší a při vícevláknové aplikaci může zbytečně blokovat ostatní vlákna. Ale nad tím přemýšlí spíš programátoři, kteří dělají něco opravdu critical;)

[Ladicek]

Tak to musí být opravdu critical, protože třeba o alokaci v Javě se v Java Concurrency in Practice tvrdí toto: In fact, allocation in Java is now faster than malloc is in C: the common code path for new Object in HotSpot 1.4.x and 5.0 is approximately ten machine instructions.

[Miloslav Ponkrác]

Tak to je potom lež jako věž, a vidím, že Sun chce udělat P.R. Javě na základě lživých faktů.

Proč je to lež? Protože neexistuje žádná předepsaná malloc implementace a každá runtima knihovna ho má implementovaný jinak. Protože rychlosti malloců v různými kompilátor se klidně liší i více, než o 1000%.

Jinak k různým hláškám ohledně Java versus C/C++ okazuji na svůj článek: Existuje seriózní srovnání rychlosti Javy a C/C++?

Oni totiž testeři kolem Javy jaksi zapomínají svá tvrzení seriózně dokazovat.

[Ladicek]

Ta kniha není od Sunu

Že existují různé alokátory je mi jasné. Nicméně, pokud opravdu alokace v průměrném případě znamená 10 instrukcí (ona je taky otázka, jak dlouhé ty instrukce jsou, ale pro jednoduchost), řekl bych, že to je sakra dobrá práce. Nejlepší alokace bude samozřejmě ta, kterou na zásobníku udělá už překladač, ale jak moc lze něco takového udělat pro obecné objekty, to fakt netuším (asi moc ne ).

Nesnažím se porovnávat rychlost Javy a C++. Jenom znám nějaká fakta o implementaci Javy (třeba že všechny alokace probíhají souvisle v jednom úseku paměti, který se pouze zvětšuje, takže v průměrném případě bude stačit nějaké to porovnání, posunutí ukazatele a inicializace), zatímco o C++ nikoliv, a hledám, kde by co mohlo být jinak. Zatím mne nikdo moc nepřesvědčil.

[kralyk z abclinuxu]

jestli ona jedna nebo víc z těch instrukcí nebudou call

[kralyk z abclinuxu]

Teď vážně, vono rozhodnutí mezi C++ a Javou nezaleží ani moc na vlastnostech jazyka nebo implementaci, ale hlavně na tom, co vlastně chcete tvořit...

[Ladicek]

Ale já se nechci rozhodovat mezi C++ a Javou. Bavíme se o alokaci paměti, to je celé.

[Jardík]

Hmm, a když je tam call, tak by tam mohlo být i ret. Ale aby tam nakonec nebyl int a retn (snad jsem to nezvoral).

[kapo]

Ono kazda sranda neco stoji. Takze kdyz budu mit rychly alokator, tak zas muzu ocekavat, ze s tou pameti nebude moc efektivne zachazet. Nic neni zadarmo.

[zde]

namísto GC je tam RAII koncept, který vykryje v běžném programu 99% situací

Ano, pokud neprogramujete. Pokud jde ale o netriviální problém, nejde předem určit kdy se bude objekt uvolňovat, do kterého kontejneru patří či kdo je jeho "vlastník", ani kam všude se mohla zatoulat reference na něj. V takových případech je GC nejjednodušší a nejefektivnější řešení. Tuším že GCC přešlo na GC, a předtím dlouho používalo obstack.

Takže GC v C++ nechybí, chcte-li, můžete ho tam mít, ale s přirozenými prostředky C++ je tam zbytečné.

To není argument. GC která není přesná ale jen konzervativní jde přirozeně přilepit do libovolně šíleného jazyka, tedy i do C++. Ovšem je to jenom hack co si dost často splete náhodné 4 bajty s pointerem, a uvolňuje tedy jen část garbage. A protože chybí jakákoliv použitelná typová informace, nejde implementovat jakákoliv finalizace.

[deda.jabko]

V C++ je GC principielne nanic, protoze mame chytre ukazatele.

chytre ukazatele jsou ve skutecnosti neuveritelne hloupe... a navic pomale...

[Let_Me_Be]

GC je nepochybne komplexnejsi zalezitost (hlavne pokud umi rozhodovat zda objekt alokovat na stacku nebo v heapu), ale nevim v cem by mel byt chytry ukazatel pomaly (vuci GC), aktualni implementace jsou jiste nevhodne pro vice-vlaknove sdileni, ale jinak.

[deda.jabko]

nevim v cem by mel byt chytry ukazatel pomaly (vuci GC)

tak treba v pricitani a odcitani jednicek aneb stokrat nic umorilo vola. navic uvolnovani vice objektu najednou se da zvladnout rychleji nez kdyz se to dela prubezne. sveho casu jsem ve vsem intepretru zkousel nahradit boehmuv GC pocitanim referenci a i bez detekce cyklu to davalo vysledky horsi v radech desitek procent. to mozna bude taky duvod proc se v ostatnich ,,jazycich s GC'' pouziva GC a ne pocitani referenci.

[Let_Me_Be]

Ono to bude spis tim, ze pokud to pocitani neni intruzivni tak je docela vysoka pravdepodobnost ze ten inkrement/dekrement zpusobi cache miss.

Jinak pocitani referenci neni jediny zpusob, mame linkovany seznam instanci, one-time objekty, predavane vlastnictvi.

Btw. treba dealokaci pameti by mel agregovat samotny runtime (alespon GCC implementace).

[Miloslav Ponkrác]

Chytrý ukazatel nerovná se nutně počítání referencí.

Jinak počítání referencí je pomalý způsob GC, má však jednu výhodu oproti jiným GC metodám. K uvolnění paměti dochází okamžitě = program potřebuje mnohem méně paměti. Druhá výhoda je při multithreadovém použití, že není nutné zastavovat thready. Každé GC musí čas od času zastavit program, a všechny jeho thready a to tak, že to nemůže kdykoli, ale musí každý thread nechat dojet do tzv. bezpečného bodu a pak rozjet svojí práci. V okamžiku akcí GC tedy proces a jeho thready stojí - nelze jinak. Proto to všěechny GC jazyky dělají co nejméně - a to tak, že doslova plýtvají pamětí, často je zablokovaná, ale neuklizená paměť čekající na GC i několikanásobně větší, než to, kolik proces skutečně potřebuje. Základní programátorská poučka zní: "Každý algoritmus se dá zrychlit, pokud začnete nehorázně pllýtvat pamětí". Nic proti GC, ale všechno má své stránky.

Proč se v C++ nejčastěji používá počítání referencí? Protože jeho vývhody - okamžité uklizení paměti hned jak není potřeba, protože je bezproblémově multithreadové bez další režie, a protože v dobře a moderně napsaném C++ se stejně skoro všechno odklidí samo přes RAII koncept, a ten nepatrný drobeček, asi tak jedno promile, co se uklidí přes chytré ukazatele už nehraje moc roli.

[Deleted [8409]]

Musím souhlasit.

Myslím, že toto je i věc, proč se stále C++ používá pro vývoj her. Bylo by neakceptovatelné, aby se vám hra zasekla třeba na 1s aby si mohl GC uvolnit paměť.

Další zajímavá technika, která tady nebyla zmíněná je Object Pooling. Prostě si dynamicky alokované instance nechám na další použití - opět plýtvání na úkor výkonu ;)

[zde]

Naopak, C++ se pro hry používá stále méně, protože je to jazyk nepoužitelný na cokoliv jiného než psaní C++ programů. Nezdá se mi že by se třeba WoW moc sekal, a to běží na LUA (jednoduchý inkrementální GC).

[Luboš Doležel (Doli)]

To je jako celý engine v LUA, nebo jen skriptování?

[zde]

Engine je v C (možná s minimem C++ featur), plus poměrně dost asembleru. Ale engine se neprogramuje, ten se kupuje (a případně mírně upravuje), je to komodita. To co se programuje je právě to skriptování GUI a AI a všechno kolem, a to v C++ není, takže tvrdit že hry se píšou v C++ není pravda.

[Let_Me_Be]

Ale engine se neprogramuje, ten se kupuje (a případně mírně upravuje), je to komodita.

ROFL, dalsi perla

To co se programuje je právě to skriptování GUI a AI a všechno kolem, a to v C++ není, takže tvrdit že hry se píšou v C++ není pravda.

Tohle se dela v ciste internich nastrojich, delaji to designeri, kteri nemaji ani sajnu o tom co to programovani je. V tomto procesu se nenapise ani rakda kodu.

Proboha zjistete si neco o tom jak se vyvijeji hry, nez zacnete matlat podobne kraviny.

[zde]

Tohle se dela v ciste internich nastrojich, delaji to designeri, kteri nemaji ani sajnu o tom co to programovani je. V tomto procesu se nenapise ani rakda kodu.

Jistě, ovšem ty interní nástroje je třeba nejprve vytvořit. Hádejte v čem.

Proboha zjistete si neco o tom jak se vyvijeji hry, nez zacnete matlat podobne kraviny.

Nápodobně.

[Let_Me_Be]

Jistě, ovšem ty interní nástroje je třeba nejprve vytvořit. Hádejte v čem.

Nemusim hadat, ja to vim. V C++, pripadne v Jave.

[kralyk z abclinuxu]

Engine je v C (možná s minimem C++ featur), plus poměrně dost asembleru. Ale engine se neprogramuje, ten se kupuje (a případně mírně upravuje), je to komodita.

Víte kolik ty enginy stojí? Stovky tisíc dolarů... Každej tvůrce her na tohle nemá nebo nechce tý možnosti užít. Pak si engine programuje sám, zpravidla v C/C++

To co se programuje je právě to skriptování GUI a AI a všechno kolem, a to v C++ není, takže tvrdit že hry se píšou v C++ není pravda.

Uh, radši si probereme, jak se tvoří hra:
1. Programátoři vytvoří nebo koupí-přizpůsobí engine a naprogramují nastroje na tvorbu komponentů hry (různé ty editory atp.) To vše většinou v C/C++, ale vzhledem k tomu, že featury C++ zpřehlední návrh vnitřní logiky, většinou C++.
Tam kde, jsou potřeba mohutné optimalizace jako např. vykreslovací engine apod. a vstupuje do hry C příp. assembler.
2. Designéři navrhnou a grafici vytvoří grafickou stránku hry
3. Herní logikové naskriptují konkrétní podobu chování hry. Ať už v LUA nebo jakýmkoli jiným skriptu, o jehož provedení se postará engine z bodu 1

To jen humpolácký tvůrci koupěj engine, zaplatí grafiky/herní designéry a složej to dokupy - tak vznikaj vodfláklý hry, který chce vydavatel hlavně rychle prodat.

Taky nesmíš věřit všemu, co napíšou někde ve score nebo na bonuswebu nebo buhví kde...

[depka]

na lua bezi akorat gui

[kralyk z abclinuxu]

Lol tak to je pěkná hovadina. C++ se pro hry rozhodně používá a WoW rozhodně neběží na LUA. Mimochodem, v čem je napsán interpreter LUA?

[zde]

LUA je napsána v C. To je takový jednoduchý, elegantní, portabilní, a přitom velmi efektivní jazyk.

[kralyk z abclinuxu]

To máte ňákej komplex z nerozumění C++ nebo co? Viděl jsem šílence, resp. jejich kód, kteří v C používali jakousi parodii OOP, něco jako třídy, akorát přes struct. Vůbec se to nedalo číst, funkce halabala jedna přesdruhou, hrozný...

[kralyk z abclinuxu]

Btw. jasně že LUA je napsaná v C, LUA je jednoduchý jazyk na napsání jednoduchých skriptů pro nějaké to GUI nebo AI. V LUA budete asi těžko navrhovat velmi komplexní systém se složitou hierarchií, provázaností a modularitou jakými herní enginy jsou. Je vidět, že nemáte absolutně šajnu co to herní engine je.

[Jardík]

Myslíte GTK?

[Boris Dušek]

Nevím sice, co myslel Kralyk, ale já jsem si pod tím GTK okamžitě představil

[Deleted [8409]]

Né jenom Gtk, prakticky všechno, co používá GObject

[Let_Me_Be]

Nezdá se mi že by se třeba WoW moc sekal, a to běží na LUA (jednoduchý inkrementální GC).

ROFL, tak to mne fakt pobavilo

V LUA je napsan UI, veskera implementace vsech metod, ktere se z LUA volaji jsou samozrejme implementovane v C++. A jen tak mimochodem je to pomale jako prase a u slozitejsich addonu se to seka zcela brutalne.

[deda.jabko]

K uvolnění paměti dochází okamžitě = program potřebuje mnohem méně paměti.

to nemusi byt nutne pravda u vetsiny alokatoru jsou uvolnene bloky ukladany do pomocnych struktur, aby byly opet recyklovany pri dalsi alokaci... coz znamena dalsi rezii na pamet... navic nektere alokatory maji tendence drzet si pridelene stranky co nejdyl.

každý thread nechat dojet do tzv. bezpečného bodu

obvykle ten bezpecny bod neni zase tak daleko... jelikoz i pres dnesni precesory je vetsina vlaken uspana.

V okamžiku akcí GC tedy proces a jeho thready stojí - nelze jinak.

z vlastnich zkusenosti stop world faze na heapu kolem ~256MB se spoustou malych objektu zabere cca ~100ms. coz opravdu neni zadna hruza a asi by se s tim vyrovnala i nejaka ta hra. (rt aplikace sem prosim netahejme)

všechno má své stránky

u multithreadoveho GC sice dochazi k stop world, coz muze byt neprijemne... ale klasicka alokace trpi taky docela vyraznym neduhem... v momente, kdyz proti sobe jde nekolik vlaken skutecne (tj. opravdu bezi na jednotlivych procesorech) alokujicich/dealokujicich objekty, tak se to stava neuveritelne uzkym hrdlem pro skalovatelnost (zamykani uvnitr alokatoru). chapu, ze tady tato vec vetsinu lidi netrapi, protoze se to jde obvykle poradne videt az u pocitacu s vice (nez ctyrmi) jadry... ale s tou bezproblemovou multithreadovosti bez rezie bych to opravdu neprehanel...

[Let_Me_Be]

Tohle ale narazi na otazku jestli musi smart pointer pouzivat zamky. Lock-free implementace se zacali objevovat az v posledni dobe (a zatim jsem je nemel potrebu nejak moc zkoumat) ale na webu se da uz najit napriklad lock-free linked list, coz je jeden ze zpusobu implementace smart pointeru.

[deda.jabko]

tak to nevim jestli smart pointery musi pouzivat zamky... a uprimne je mi to jedno, jelikoz smart pointery jsou jen vrstva nad ,,tradicni alokaci/dealokaci'', coz ve vetsine pripadu jsou docela zrudnosti a zamykani se tam da vyhnout jenom s velkymi obtizemi.

[Let_Me_Be]

Smart pointery jsou takove jake je mate naimplementovane. Ted nevim jestli Alexandrescu implementoval u svych policy based ukazatelu i alokaci na stacku, ale myslim ze v LOKI neco podobneho bylo.

[Deleted [8409]]

Atomické operace by měli stačit, ne ;) ?

[Let_Me_Be]

No to je sice hezke, ale problem je v tom co se nam bude dit mezi temi atomickymi operacemi coz resi prave zamykani, ze z xy operaci udela jednu atomickou.

[Deleted [8409]]

No atomická operace znamená, že se mezi ní nesmí dít nic. Měl jsem na mysli speciální instrukce procesoru, které zaručují atomičnost. Samozřejmě, pokud nestačí jedna operace, musí se použít zámek nebo nějaká komplikovanější metoda.

Nedávno jsem implementoval tzv. lazy instance (instance, které se vytvoří až při prvním požádání - get() ) a použil jsem právě atomické operace, abych ušetřil zámky pro každou takovou třídu. Takže jde to :)

[Miloslav Ponkrác]

to nemusi byt nutne pravda u vetsiny alokatoru jsou uvolnene bloky ukladany do pomocnych struktur, aby byly opet recyklovany pri dalsi alokaci... coz znamena dalsi rezii na pamet... navic nektere alokatory maji tendence drzet si pridelene stranky co nejdyl.

Ano, ta další režie je pár procent. A dělá se to proto, že alokátor musí bloky paměti požadovat od operačního systému, který je dodává velmi pomalu a pouze po velkých blocích. Třeba operační systém nikdy nealokuje méně, než jednu stránku paměti (na x86 je to 4KB). Ono je jaksi nemožné operačnímu systému vrátit třeba 8 bajtů paměti.

obvykle ten bezpecny bod neni zase tak daleko... jelikoz i pres dnesni precesory je vetsina vlaken uspana.

Tak až někdy v kritických zátěžích se zátěž procesoru bude blížit 100%, tak si opakujte, že to výkonné vlákno vlastně jenom neustále spí a ta zátěž se Vám zdá.

z vlastnich zkusenosti stop world faze na heapu kolem ~256MB se spoustou malych objektu zabere cca ~100ms. coz opravdu neni zadna hruza a asi by se s tim vyrovnala i nejaka ta hra. (rt aplikace sem prosim netahejme)

Vám 100 ms připadá málo? A předpokládám, že nejedete navíc na podprůměrně pomalém stroji, takže v řadě zařízení to může být i řádově více. A druhá věc je, že GC málokdy udělá práci celou, na 99% vyřídí pouze jednu generaci (z obvyklých tří) neuvolněné paměti. A i pokud pustíte plné GC přes všechny generace, tak GC potřebuje dvě spuštění na celou práci - v jednom spuštění zavolá finalize metody a ve druhém teprve pro ně uvolní paměť. Takže kdyby GC měla dělat opravdu celou práci naráz, tak ze 100 ms se už blížíme krát 3 generace krát dvě spuštění k 600 ms. A to zanedbávám fakt, že kolekce druhé a třetí generace je obvykle pomalejší, než té první.

u multithreadoveho GC sice dochazi k stop world, coz muze byt neprijemne... ale klasicka alokace trpi taky docela vyraznym neduhem... v momente, kdyz proti sobe jde nekolik vlaken skutecne (tj. opravdu bezi na jednotlivych procesorech) alokujicich/dealokujicich objekty, tak se to stava neuveritelne uzkym hrdlem pro skalovatelnost (zamykani uvnitr alokatoru).

A proto existují alokátory, která tímto neduhem netrpí. Například je známo, že alokační funcke Win32/Win64 API mají toto pořešeno, a pokud použijete pro heap alokace API funkce Windows - tedy HeapAlloc/HeapRealloc/HeapFree, pak k žádnému úzkému hrdlu nedochází. Žádné zamykání se nekoná, a výkonnost a rychlost alokace i v multithreadovém prostředí je neskutečná.

A stejně tak samozřejmě existují alokátory i pro C/C++, které umí totéž.

To co popisujete není obecně nutná vlastnost klasických alokátorů.

[Ladicek]

Vám 100 ms připadá málo? A předpokládám, že nejedete navíc na podprůměrně pomalém stroji, takže v řadě zařízení to může být i řádově více. A druhá věc je, že GC málokdy udělá práci celou, na 99% vyřídí pouze jednu generaci (z obvyklých tří) neuvolněné paměti. A i pokud pustíte plné GC přes všechny generace, tak GC potřebuje dvě spuštění na celou práci - v jednom spuštění zavolá finalize metody a ve druhém teprve pro ně uvolní paměť. Takže kdyby GC měla dělat opravdu celou práci naráz, tak ze 100 ms se už blížíme krát 3 generace krát dvě spuštění k 600 ms. A to zanedbávám fakt, že kolekce druhé a třetí generace je obvykle pomalejší, než té první.

Tyhle odhady mi přijdou naprosto mimo, o použitém GC nevíte zhola nic. Pokud jde o jednoduchý mark and sweep GC nad celým heapem, pak bych těm 100 ms věřil. Jenže to je opravdu maximum. Mám zkušenost s heapem cca 1,5 GB velkým, kde paralelní mark and sweep algoritmus obvykle skončí asi za 2 vteřiny, a jediné dvě stop world fáze dají dohromady nanejvýš desítky milisekund. Mimo ně program normálně běží.

Jo, taky jsem zažil plně stop world GC, který na stejném heapu běžel deset minut (Což bylo nejspíš tím, že půlka paměti byla odswapovaná na disku, jistý si nejsem.)

[deda.jabko]

A dělá se to proto, že alokátor musí bloky paměti požadovat od operačního systému, který je dodává velmi pomalu a pouze po velkých blocích.

to jste mi nerekl nic noveho, kazdopadne to vypada, ze to s tim volnym mistem u normalni alokace neni zase tak zhave...

Tak až někdy v kritických zátěžích se zátěž procesoru bude blížit 100%, tak si opakujte, že to výkonné vlákno vlastně jenom neustále spí a ta zátěž se Vám zdá.

jelikoz dnesni pocitace maji vetsinou pocet procesoru vyrazne mensi nez pocet vlaken, neni zase tak narocne zastavit aktualne bezici vlakna a dalsi nespoustet.

Vám 100 ms připadá málo? A předpokládám, že nejedete navíc na podprůměrně pomalém stroji, takže v řadě zařízení to může být i řádově více. A druhá věc je, že GC málokdy udělá práci celou, na 99% vyřídí pouze jednu generaci (z obvyklých tří) neuvolněné paměti......

kde jste sakra k tem vypoctum prisel?!

jenom pro upreseneni---boehmuv GC (nastaveny jako jednogeneracni), par milionu objektu o velikosti mensi 100B vetsinou i prevazne pod 50B, procesor je intel core duo (1.8GHz, 1GB ram celkove)... takze docela prumerny az dnes mozna uz podprumerny pocitac.

Initiating full world-stop collection 2 after 295171612 allocd bytes
--> Marking for collection 2 after 295171612 allocd bytes
Collection 1 reclaimed 0 bytes ---> heapsize = 268500992 bytes
World-stopped marking took 100 msecs
Heap contains 46771184 pointer-containing + 7016 pointer-free reachable bytes
Finalize + initiate sweep took 0 + 20 msecs
Complete collection took 170 msecs

jenom pro upresneni GC bezi v nekolika fazich a nejkriticejsi je ten stop-world s markerem (ktery muze bezet i paralelne), zbytek uz si muze bezet jak chce. finalizace objektu automatickou spravou pameti je obecne povazovana za hodne spatnou praktiku. navic pro finalizaci nemusi bezet samostatny sber,...

HeapAlloc/HeapRealloc/HeapFree, pak k žádnému úzkému hrdlu nedochází. Žádné zamykání se nekoná, a výkonnost a rychlost alokace i v multithreadovém prostředí je neskutečná.

a zkousel jste to spustit treba na ultrasparcu, kde skutecne _soubezne__bezi_ 32/64 vlaken? mozna byste byl prekvapen tou neskutecnou rychlosti. ano, dokud jsem vicevlaknove aplikace provozoval na pocitacich, ktere mely do 4 jader max, tak se tento neduh moc neprojevoval...

To co popisujete není obecně nutná vlastnost klasických alokátorů.

neni, ale jeste jsem nanasel funkcni alokator ktery by to dobre zvladal... nejbliz byl hoard... a i ten se pri urcitych vzorcich alokace nechoval zrovna idealne.

[Boris Dušek]

Zrovna včera jsem koukal, co bude mít (resp. už má v preview) Visual C++ 2010: lambda expressions, rvalue, auto keyword a static_assert. A v 2008 už je většina TR1.

[Luboš Doležel (Doli)]

A to jsem dřív četl komentáře, jak je celé C++0x předem mrtvé, jak to nikdo nebude implementovat... kdeže!

[Miloslav Ponkrác]

S C++0x je jiný problém. Že ho musí už vydat je jasné, to 0x znamená rok vydání, a už neměli moc času, jinak by to museli přejmenovat za rok na C++1x. Ale problém je, že v případě multiplatformových programů nebude C++0x velmi dlouho použitelné, pokud vůbec kdy.

Vezměte si, že třeba vim dodnes jeho autor píše v K&R C, protože řada platforem se v C kompilátorech dále nedostala. A stejně tak to bude s C++ - pokud budete na platformě Linux/Windows, pak není problém používat to nejmodernější ze standardů.

Myslím, že by se hodila nějaká moderní verze CFrontu, která by zvládala i C++0x.

[Let_Me_Be]

Myslím, že by se hodila nějaká moderní verze CFrontu, která by zvládala i C++0x.

Jj, presne tak.

[Miloslav Ponkrác]

Jinak k tomu optimismu a použitelnosti - já na Windows dlouho používal gcc, ale utekl jsem od něho, protože gcc dodnes ve standardním mingw32 vydání neumí ani pořádně současný C++ standard. Například jeho STL knihovna neobsahovala unicode části, například třída ::std::wstring tam nebyla. To byl prakticky hlavní důvod, proč jsem nainstaloval Microsoft Visual Studio C/C++ 2005 a jel v něm. Potřeboval jsem zkrátka C++ kompilátor, co zvládne standard.

Možná jde si překompilovat GCC sám, či kýho výra, aby podporoval všechno, ale nečekám, že budu kompilovat všechno, na co sáhnu. To bych nedělal nic jiného.

Pokud GCC bude C++0x podporovat stejně, jako podporouje dnešní C++ standard, tak to předem odepisuji. Pak jediným rozšířeným kompilátorem, který bude opravdu správně a úplně implementovat C++0x standard bude bohužel zase Microsoft.

[Jardík]

No já v gcc na win std::wstring mám - nemám ale mingw32 ale mingw-w64 s nějakou vývojovou verzí gcc, ale tuším, že jsem wstring používal i s mingw32 kdysi dávno, když jsem ho ještě používal. Já zas nemám rád visual c/c++, protože každá verze vytváří k programu závislosti na jiných verzích msvc runtime knihovnách a když je slinkujete staticky, tak vznikají megové binárky.

[Miloslav Ponkrác]

Zase migw32 vytváří závislost na realtimové knihovně msvcrt.dll z Microsoftího kompilátoru, a na rozdíl od Visual C/C++ nemáte vůbec možnosti slinkovat binárku staticky. Takže je to peprnější - gcc závisí na Visual C/C++ runtimové knihovně

Jinak to, jestli má binárka mego, mě nezajímá, doby kdy se tři dny optimalizovalo, aby binárka byla o dva bajty kratší jsou už naštestí pryč. Navíc velikost binárky absolutně nic neříká o tom, kolik zabere proces místa v paměti při spuštění, ani při běhu. Takže je to docela irelevantní.

Jinak, pokud můžu porovnávat - Microsoftí kompilátor je lahoda ohledně hlášení a chytání chyb. Zejména je mistrem v odchycování chybného použití STL a to i za běhu. STL je bohužel dost zprasený projekt, který když použijete jinak, tak se program zhroutí - nemá prakticky ani tu nejmenší kontrolu chyb. Takže pokud se Vám něco v C++ programu přeloženém v gcc zhroutí a máte podezření na STL - pak buď týden přemýšlíte, kde to je. A nebo to převedete do Visual C/C++, přeložený program spustíte a za pár sekund Vám do Visual C/C++ nabonzuje i s řádkem, kde je chyby včetně popisu. Ani nevíte, jak to šetří čas.

GCC také bohužel i řadu běžných chyb hlásí na jiném řádku, než jsou. Hlavně při složitějších template výrazech, když gcc ohlásí chybu na řádku 200, tak klidně může být ve skutečnosti třeba na řádce 172. Microsoft hlásí chyby správně na řádku, kde skutečně jsou. Vyjímečně dokonce nejsem schopen přijít, kde a co vlastně gcc vadí.

Co je zase v gcc výhodu je, že podporuje 80 bitové floating point čísla na x86 platformě, Microsoft se na to vykašlal. Gcc nemá tendenci přidávat varování, že jste nepoužili věci tak, jak by si Microsoft přál. Což jsou warningy, které musíte složitě vypínat.

Prostě všechno má svoje. Já jen moc nevěřím té podpoře standardu od gcc. Protože kompilátor, který si dnes dovolí neumět ani dnešní deset let starý standard C++, tak mě sotva přesvědčí, že bude mít plnou podporu novějšího.

[Let_Me_Be]

STL je bohužel dost zprasený projekt, který když použijete jinak, tak se program zhroutí - nemá prakticky ani tu nejmenší kontrolu chyb.

STL vubec neni zpraseny projekt, je presne definovano kdy co a jak funguje, kdyz to neznate je to vas problem, ne problem STL.

Takže pokud se Vám něco v C++ programu přeloženém v gcc zhroutí a máte podezření na STL - pak buď týden přemýšlíte, kde to je. A nebo to převedete do Visual C/C++, přeložený program spustíte a za pár sekund Vám do Visual C/C++ nabonzuje i s řádkem, kde je chyby včetně popisu.

Nebo se podivam na backtrace a mam jasno, ze?

Prostě všechno má svoje. Já jen moc nevěřím té podpoře standardu od gcc. Protože kompilátor, který si dnes dovolí neumět ani dnešní deset let starý standard C++, tak mě sotva přesvědčí, že bude mít plnou podporu novějšího.

Boze to jsou kecy. Neco konkretniho by nebylo? To co jste psal nahore samozrejme GCC bez problemu zvlada.

[Miloslav Ponkrác]

STL vubec neni zpraseny projekt, je presne definovano kdy co a jak funguje, kdyz to neznate je to vas problem, ne problem STL.

Zase jeden pán, který programuje bez chyb, a vždy napíše program napoprvé bez chyb, bez nutnosti ladění. Smekám před Vámi, jste borec. Mimochodem jediný na světě, který to dokáže.

Nebo se podivam na backtrace a mam jasno, ze?

Znovu opakuji, jste borec. Stojím v úžasu, a nedosahuji Vaší velikosti ani schopností.

Boze to jsou kecy. Neco konkretniho by nebylo? To co jste psal nahore samozrejme GCC bez problemu zvlada.

A Vy jste čínský papež s miliardovým kontem a třema naftovými poli. Všemu věřím.

[default]

Zase jeden pán, který programuje bez chyb, a vždy napíše program napoprvé bez chyb, bez nutnosti ladění. Smekám před Vámi, jste borec. Mimochodem jediný na světě, který to dokáže.

Není jediný. Já se také skromně hlásím

[kralyk z abclinuxu]

No tak to už jsme tři ...

[Ivan]

Nebo se podivam na backtrace a mam jasno, ze?

Backtrace? To jako verite gdb? GDB ma dost problemy s binarkama prelozenyma pomoci C++. My treba jsme treba i na produkci prekladali s '-O0 -ggdb3 -fno-inline -Bsymbolic' jenom kvuli tomu, ze se gdb nedokaze orientovat v C++ binarce. Pokud opravdu pouzivate STL tak vam zadny backtrace nepomuze, protoze vsechen kod je inline. Jeste ze ma VC debug build, ktery generuje kod, ktery za behu kontroluje vsechno mozne. Na linuxu je sice valgrind, ale to neni ono. Skoda ze valgrind nema vlastni port STL.

Naposledy jsem strasne prskal kdyz jsem se snazil dat automatickej pointer do vektoru. Syntakticky je to sice mozne, jde to zkompilovat ale pada to. Vubec jsem netusil proc a ze zdrojaku ani z "backtrace" jsem nic nevykoukal. Pak jsem nasel najek clanek na webu, kde bylo vysvetleny, ze to proste v STL nefunguje. Od ty doby pouzivam boost/loki. Proc STL (standart nemyslim implementaci) obsahuje dve veci, ktery se navzajem vylucuji?

[default]

Zlatá Java! Tímto veřejně děkuji společnosti Sun Microsystems za aspoň trošku použitelné prostředí pro vývoj software, které netrpí dětskými nemocemi

[Let_Me_Be]

Opravdu nevim kde jste s cim mel problemy, ale mne vzdy fungovalo GDB s C++ nadherne a to vcetne prace s STL. Chybu najdu vzdy rychle a spolehlive.

[msk]

Mne gdb prestalo fungovat niekde okolo roku 2001, kedy zacalo ignorovat breakpointy. Ani po 3 rokoch to nebolo fixnute, takze som sa naucil programovat bez debuggera. Aky je stav dnes netusim, gdb som medzitym uz len par krat pouzil na analyzu coredumpov.

[burlog]

Do STL container trid nelze vkladat std::auto_ptr, protoze tento ma nekonstatni kopirovaci konstruktor. Takovyto program by ani nemelo jit zkompilovat.

[Miloslav Ponkrác]

Jenom pro důkaz, že prostě lžete, a to zcela bezostyšně třeba o tom zvládání standardu v GCC (tedy ve verzi mingw32 pro Windows, o které jsem psal) si nalistujte FAQ přímo na stránkách oficiálního projektu:

http://www.mingw.org/wiki/FAQ

A nalistujte si otázku: "Why don't wide characters work with libstdc++?"

[kralyk z abclinuxu]

The wide-character parts of the GCC Standard C++ Library (libstdc++) have not yet been fully ported to Windows.

Tady jsme ve světě open-source. Co vám brání to napravit?

[Miloslav Ponkrác]

Vrozená lenost? A hlavně ty byrokratické obtíže kolem většiny open source projektů, kdy několik procent času věnujete nápravě chybě a zbytek protlačit to do výsledku.

[Let_Me_Be]

Problem bude v tom ze tady matlate GCC a Mingw. Mingw ma v sobe otresne starou verzi GCC, ktera jeste k tomu ani neni zcela funkcni. Na netu se daji najit aktualni Windows buildy GCC (samozrejme experimentalni).

[Miloslav Ponkrác]

Experimentální buildy mě nezajímají. Jedu na stable verzích.

Ale v zásadě máte pravdu. Nicméně závěr je stejný: gcc pro Windows nevyhovuje standardu C++ z roku 1998. Ať už jsou příčiny jakékoli.

[Let_Me_Be]

To bude tim, ze neexistuje nic jako GCC pro Windows MinGW samotne je experimentalni.

[tomas]

To ani visual studio, pred rokem jsem narazil na konstrukci co to neumi a jeste trapne hlasi syntax error. Gcc v podobnem pripade alespon rika, "sorry, not implemented" nebo neco takovyho.

[Jardík]

Mingw32 má gcc 4.3, což zas tak stará verze není a mingw-w64 má svn.

[Jardík]

Jestli to bylo na mě, tak je nepsal, že funguje bez problémů, ale že tam je a mně fungoval pro mé účely tak, jak jsem očekával.

[kralyk z abclinuxu]

Zase migw32 vytváří závislost na realtimové knihovně msvcrt.dll z Microsoftího kompilátoru, a na rozdíl od Visual C/C++ nemáte vůbec možnosti slinkovat binárku staticky.

Tak nevim, buďto to mám slinkováno staticky, nebo tam ta závislost není, páč mi gcc/mingw32 binárky chodí bez msvcrt.dll

Nemůže to bejt třeba kvůli -g, takže Release target tu závislost nemá? (nevím)

[Miloslav Ponkrác]

Spíš máte MSVCRT.DLL přímo v systému Windows, protože ho používá hodně programů, a tak většinou bývá nějakým nainstalováno. Jinak ne, že by mi to vadilo, že jsou binárky závislé na této DLL, nevadí mi to. Ale mě se nepodařilo se bez ní obejít.

[kralyk z abclinuxu]

Jasně že ji mám ve windows, ne asi. Všechny výskyty knihovny msv*.dll které jsem našel v %path% jsem dočasně přejmenoval na *.dll.zaloha, a přesto moje binárky neměly nejmenší problém. Takže o spolehlivosti vašich informací silně pochybuju

[Jardík]

Podle mingw týmu tam ta závislost opravdu je, ale jak jsem zmínil, ta knihovna je od win98 součástí windows.

[Jardík]

Závisí sice na msvcrt.dll, ale ta knihovna je (narozdíl od těch "jiných") přímo v systému od Windows 98 (a možná i 95).

[elviin]

ted jsem chtel sem pastnout tu linku, mj. na tom(TP 2010) delali z velke casti autori Boostu.

[Deleted [8409]]

Jak je to s tím STL ?

V té Wiki je příklad, že vytvořili nějaký nový move constructor, právě kvůli tomu, aby bylo možné udělat rychle toto:

std::wstring my_func(...)
{
  std::wstring result;

  // ...

  return result;
}

To STL vážně kopíruje obsah řetězce do nového pole při returnu (copy construcor) ? Jestli jo, tak je to hodně špatné a prakticky nepoužitelné.

[kralyk z abclinuxu]

takže ten move constructor nějak šetrně sdělí parametru (result) že při uvolňování nemá uvolnit ta data, která už patří tomu novýmu stringu, že? nebo to chápu blbě?

[Deleted [8409]]

No chápal bych to jako swap. Ta původní instance o ty data přijde (bude z toho empty string) a ta nová instance se stane novým vlastníkem těch dat.

Ale chápu moc dobře, proč něco takového zavedli, je to výhodné.

[Let_Me_Be]

No presneji, pokud dokazu provest presun efektivneji nez zkopirovani a zahozenim puvodnich dat, tak ma smysl to implementovat. Pokud mam tridu, ktera obsahuje pouze POD typy (resp. libovolnou tridu, ktera nerozlisuje mezi deep a shallow copy z pohledu rychlosti) tak to smysl nema.

[Deleted [8409]]

Jo, šak tu je řeč o stringu, proto jsem uvedl tento příklad :)

[Let_Me_Be]

Samozrejme ze ho kopiruje, protoze musi. Predstavte si ze je to metoda vracite nejaky atribut, urcite nechcete aby vam nekdo najednou zapisoval do vasi interni struktury.

Pokud nechci kopirovani, mam referenci, ale pak nemuzu vracet promennou, ktera zanikne pri opusteni bloku. Pokud chci oboje, tak musim pouzit ukazatel. Jednoduche.

std::wstring& my_func() { return nejaky_wstring; }
const std::wstring& my_func() { return nejaky_wstring; }
std::wstring* my_func() { std::wstring* s = new std::wstring; return s; }

[Deleted [8409]]

No ale v tom případě se nedivím, proč třeba Qt má vlastní QString, QList, ...

Ono to implicitní sdílení spolu s COW je velmi dobrá volba ;)

[Miloslav Ponkrác]

A Vy myslíte, že STL nemá COW a implicitní sdílení? Kde žijete?

Qt zkrátka je velmi staré a je odvozeno od velmi starých verzí C++, kdy ještě C++ nemělo ani standard. Qt nevyužívá možnosti C++ ani z 1%. Je mylné si myslet, že některé věci v Qt mají rozumné opodstatnění, či nějakou výhodu. Nemají. Ony totiž to opodstatnění měly v roce 91, kdy vznikalo, ale dne je to v mnoha případech spíše koule na noze Qt.

[Deleted [8409]]

Přečtěte si váš komentář výše o std::wstring, vyvrací vaše tvrzení o tom, že je něco mylné. To radši nemluvím o tom, že wchar_t je ve Windows 16 bit a v posix systémech 32 bit. To je potom těžké cokoliv sjednocovat i když se jedná jen o takovou drobnost.

[Miloslav Ponkrác]

A Vy si přečtěte, na co reaguje - na to, že je fajn, že Qt má vlastní věci, protože COW.

wchar_t může být cokoli a je to v pořádku

Sjednocení se dá udělat velmi snadno - pokud chci důsledně multiplatformní sjednodcený program, pak v C++ je šablona ::std::basic_string, který je obecným stringem o libovolné délce znaku.

Jen pro Vaší informaci, jak ::std::string, tak ::std::wstring jsou pouhou instancí této šablony, přičemž prakticky vše je definováno v této šabloně. Ve skutečnosti je ::std::string a ::std::wstring jen pouhým typedef základní šablony ::std::basic_string s parametry typu char (a příslušným char_traits) a wchar_t (a příslušným char_traits).

Je tedy naprosto primitivní si založit třeba svůj typ ve stylu:

typedef uint32_t mychar_type;

A pak vytvořit třeba mystring jako instanci šablony ::std::basic:string.

Nevidím sebemenší překážku ohledně sjednodcení, ani tu nejmenší.

[Deleted [8409]]

Jenže v případě Qt je to exportované v knihovně QtCore, což u libstdc++ není a všechny požadované funkce zaberou místo v každé knihovně/aplikaci, kde se STL využije. Pro aplikace to není problém, ale pro knihovny by mohl být.

[Miloslav Ponkrác]

Pokud chcete šetřit místo, nepoužívejte obludně velkou knihovnu Qt - jednoduchá odpověď.

[Deleted [8409]]

Mi vůbec nešlo o Qt knihovnu. Jde mi o to, že já si ten string radši napíšu, exportuju do knihovny a pak používám. Tímto způsobem si ho můžu upravit a optimalizovat pro moje účely a nemusím se starat o to, jestli je wchar 16 bitů nebo 32 bitů.

[Deleted [8409]]

Ještě bych dodal, že STL znám dlouho a zanevřel jsem na něj už od samého začátku, protože dříve to bylo mnohem horší než dnes a ta výsledná binárka byla opravdu o mnoho větší než ekvivalent v C. Dnes je to lepší, ale zvyk je zvyk.

[Miloslav Ponkrác]

Samozřejmě, že se nemusí kopírovat, a také se ve většině implementací nekopíruje. Valná většina implementací STL, včetně libstdc++ se používá "copy on write" technika - ::std::string a ::std::wstring vnitřně obsahuje ukazatel na data, což je blok, kde je počet odkazů na blok a vlastní řetězec. Pokud se předávají, nebo kopírují řetězce, neudělá se nic jiného, než se zkopíruje ukazatel na data, a inkrementuje jeden integer představující počet odkazů na data.

To, co se řeší je jiný problém, který neodstraňuje ani Qt, protože je to problém vnitřních definici C++ - to je to, že při vracení instance objektu jako návratové hodnoty funkce dochází k jistým neefektivitám, respektive ne vždy je to tak efektivní, jak by mohlo být. Což se neprojeví u STL stringů, ale v zásadě vždy dojde k aktivaci operatoru= dané třídy, a ač to kompilátory dělají velmi efektivně a optimalizují co se dá, tvůrci C++ mají roupy, zda by to nešlo ještě efektivněji. O nic jiného nejde.

[Deleted [8409]]

Šak já to chválím, podle mě se jedná o dobrou věc a rád bych to využil, ale nevím kdy nejdřív budu moct :)

[Let_Me_Be]

Navenek se kopiruje. Ze si to knihovna interne optimalizuje pomoci COW je jina vec. (Ted koukam ze jsem mozna nepochopil uvodni dotaz.)

[zde]

Hmm. Rozumné jazyky mají jednoduše stringy immutable, takže je nemusejí kopírovat vůbec a tudíž není nutná ani žádná COW šaškárna.

Ovšem favorit v stringové demenci je bezkonkurenčně Java. Udělat sizeof(wchar_t) == 2 mohl jen magor, a vyplýtvat u každého řetězce referenci na jiný řetězec a dva indexy, jen aby se mohly v 0.1 promile případů sdílet podřetězce je taky nápad jak ze cvokárny :)

[Let_Me_Be]

Rozumné jazyky mají jednoduše stringy immutable, takže je nemusejí kopírovat vůbec a tudíž není nutná ani žádná COW šaškárna.

Eh? A co je na tom jako rozumneho?

sizeof(wchar_t) == 2

Tak to si postezuj Microsoftu, protoze sizeof(wchar_t) je pod MS vzdy 2.

[Jardík]

Jako je v linuxu běžné, že char* je utf8 string (takže jeden znak může mít více bytů), tak ve Windows (s jádrem NT) se místo char* používá wchar_t* (či WCHAR typedef) - ti, kteří chtějí ale pomalý program neustále převádějící char* na wchar_t* a opačně si dále používají char* pro systémová volání - což neznamená, že 2B = jeden znak, ale on ten jeden znak můžou tvořit 4B (2B + 2B, tzv. surrogate pair). Práce s takovým řetězcem je pak ve vícejazykovém prostředí rychlejší, i když na druhou stranu zase více plýtvá pamětí u ASCII znaků. V Linuxu (a asi i jiných posix systémech) je pravděpodobně v jednom wcharu uložen asi celý surrogate pair (a nebo tam není UTF-16 a je to jinak, netuším), ale plýtvání pamětí je vyšší a práce s utf8 je zase často pomalá (hlavně je neštěstí s ním pracovat v textových editorech a tak se tam často převádí na "něco normálnějšího" kvůli rychlosti). Dokonce i Qt snad vnitřně používá UTF-16. To ale neznamená, že 4B wchar je špatný, práce s ním je zase opět o něco rychlejší než s UTF-16 právě díky nenutnostem kontrolovat páry.

[Let_Me_Be]

Boze, 1) naucte se formatovat, 2) nechapu co placate.

3) Pro interni reprezentaci sirokych retezcu se obvykle pouziva UTF-32 nebo UCS-4, jednoduse proto, protoze v momente kdy jeden znak != jeden char/wchar_t se z konstatni slozitosti dostavame do linearni a z linearni do kvadraticke

4) Pokud se v char * uklada UTF-8 retezec, tak si to musi resit program sam, jelikoz to primo odporuje norme (samozrejme ze vam v tom nikdo nebrani to takhle pouzivat)

5) sizeof(char) se sice (podle definice) rovna 1, nicmene pocet bitu muze byt libovolny (7,8,16,32)

6) V Linuxu se na siroke retezce samozrejme pouziva wchar_t, ktery ma 4B

7) Windows <= 2000 pouziva pro kodovani UCS-2 (coz by melo byt pevne kodovani - ted se mi to nechce hledat) Windows >= XP pouziva UTF-16, coz je variabilni kodovani, kde je jeden znak tvoren jednim, trema nebo peti datovymi polozkami

8) 4B wchar_t je samozrejme spravny, jelikoz odpovida pozadovane velikosti pevneho kodovani, kde 1 znak = jeden wchar_t

[Deleted [8409]]

3) Interní formát řetězců obvykle určuje knihovna, kterou používáte. V případě projektu pro GTK/Fltk je to UTF8, Qt používá UTF16, WinAPI používá UTF16, Java a C# používá UTF16. Linux wchar_t je implementován jako UTF32. wxWidgets je hybrid.

4) Program si char* vždycky řeší sám a není problém mít na více místech různé kódování.

5) No zatím nevím jak do "char" nacpat více než 8 bitů

6) Ano, ale třeba ve Windows ne, otázka je teď, jak napsat opravdu portable program, když z každou implementací se pracuje různě. Proto si toolkity a knihovny zavádí vlastní řetězce většinou UTF16 (ty z Windows)

7) Ano, další problém.

8) Je správný, ale nemůžete si nikdy být jist, že to tak je. Např. Embedded zařízení ten typ taky můžou mít radši 16 bitový, aby se šetřilo pamětí.

[Let_Me_Be]

5) No zatím nevím jak do "char" nacpat více než 8 bitů

Do 8 bitoveho charu samozrejme vic nez 8 bitu nenacpete, ale jeste jednou char muze mit 7,8,16 nebo i 32 bitu (+ cokoliv jineho, jenom tohle jsou pomerne smysluplne hodnotu vzhledem k definici charu).

[kralyk z abclinuxu]

char může mít 7 bitů? To je ňákej překlep, nebo skutečně existují lidi, co jsou schopni pracovat s 7bitovým charem?!?

[Let_Me_Be]

Definice rika, ze char musi pojmout zakladni znakovou sadu na dane platforme. 7bitove znakove sady existuji, tak proc ne. Ale uprimne se s 7bitovym charem clovek asi nesetka.

[Josef Kufner]

Pokud vemu v úvahu klasický signed char (7 bitů + znaménko) a fakt, že ASCII tabulka neobsahuje záporné hodnoty, tak to až tak neobvyklé není.

[kralyk z abclinuxu]

no ale v paměti těch 7bitů + znaménko zabere 8 bitů. Takže je 8mi bitovej. Ascii tabulka je afaik indexovaná přes usigned char, takže když tam hodim (signed char)(-1) tak se to imho rovná (unsigned char)255, není-liž pravda?

[Luk]

není-liž pravda?

Není. Protože například (signed char)(-1) < (signed char)(0), kdežto (unsigned char) 255 > (unsigned char)(0).

[Jardík]

1) Hmm

2) Hmm

3) No comment

4) A s čím z mého komentáře tohle souvisí, já jen tvrdil, že v linuxu většina vícejazyčných aplikací ukládá do char* utf8 stringy

5) Opět, s čím to souvisí, já netvrdím, že sizeof(char) != 1

6) Vždyť jsem to psal, jen jsem nevěděl, jestli to ukládá v UTF-16 (tj. celý surrogate pair, pokud je) nebo UTF-32.

7) Windows 2000 jsou již zastaralý systém (i když jeden z těch, co se MS povedl). V té době ještě byl GNU/Linux v plenkách. A wikipedia (a já s ní souhlasím) tvrdí, že UTF-16 má 1 nebo 2 (surrogate pair) "položky".

8) Co se líbí vám, nemusí být správné, standard nic takového neříká.

[Let_Me_Be]

4) Souvisí to s tím co píšete, UTF-8 se používá k ukládání, nebo externí komunikaci, interně se samozřejmě používá normálně wchar_t (UTF-32 nebo UCS-4).

5) Nemluvím o sizeof(char)!=1, to je definice sizeof, že sizeof(char)=1, mluvím o tom kolik bitů má char.

7) Nechal jsem se mystifikovat, opravdu je UTF-16 budto 2 nebo 4B.

8) standard říká že jeden znak = jeden char nebo wchar_t, jelikož se Unicode do 16bit nevleze je logicke, že se musí použít UCS-4 nebo UTF-32, každopádně 4B, je pravda že o tom, že by se měl používat Unicode standard nic neříká, naštěstí v této oblasti není moc jiných voleb

[Deleted [8409]]

4) Opět nemáte pravdu. Mám z vás pocit, jako by jste nikdy nepoužíval žádné knihovny. Gtk (a GLib) používá UTF8. Qt UTF16, atd. Žádný toolkit nepoužívá interně wchar_t (teda kromě těch Windows only). Obecně v linuxu se často používá UTF8 (projekty, které vznikají v linuxu) a pod Windows WCHAR (16 bit). Takže UTF8 se používá i interně a možná je to velká chyba!

5) char v C/C++ má 8 bitů, pokud mluvíte o jiném charu, je třeba napsat o jakém.

6) Jo

7) Standard to možná říká, ale implementace pod Windows není podle standardu. Velmi často se v unicode řetězcích používá právě 16 bitový char.

[Let_Me_Be]

char v C/C++ má 8 bitů, pokud mluvíte o jiném charu, je třeba napsat o jakém.

Přečtěte si standard.

[Deleted [8409]]

Ukažte C/C++ překladač, který má char jiný než 8 bitový.

[:::]

nezkousel jsem to hledat, ale i kdyby soucasne neexistoval tak to neznamena ze nemuze existovat za rok nebo za 2 (protoze standard to umoznuje) a tvuj program pak bude neprenositelny...

[Deleted [8409]]

Zkuste se podívat do zdrojových kódů knihoven a aplikací pro Linux a uvidíte, že bude nepřenositelných 99% věcí. 8 bitový char je nepsaný standard, který si netroufne žádný tvůrce překladače porušit.

Zkuste se podívat také do vašich zdrojových kódů:)

Toto, ačkoliv je to neefektivní:

char* a = ...;
char* b = ...;

char* c = malloc(strlen(a) + strlen(b) + 1);
assert(c);

strcpy(a, b);
strcat(a, c);

Je na denním pořádku.

Troufnu si tvrdit, že zvýšení charu na víc bitů by rozbilo i Linuxové jádro.

[Let_Me_Be]

PRECTETE SI STANDARD! Uvedeny kod bude fungovat kdekoliv, jelikoz sizeof(char) == 1 je definice sizeof!!! Veskere alokace a prace s pameti se neprovadi v bajtech ale v jednotkach velikosti char.

V ne x86 je celkem normalni ze sizeof(char) == sizeof(int) a CHAR_BITS == 32 (viz. limits.h)

[Deleted [8409]]

Veskere alokace a prace s pameti se neprovadi v bajtech ale v jednotkach velikosti char

Toto si zarámuju, protože si to cucáte s prstu:-P

Parametr v malloc() [1] je počet bytů a né charů. Pokud bych chtěl napsat opravdu portable program podle vašich standardů, musel bych alokovat takto:

char* c = malloc((strlen(a) + strlen(b) + 1) * sizeof(char));

Pokud tady tedy chcete hlásat standardy, tak si je nejdříve nastudujte vy. Možná jste ale sám ve vašem příspěvku přiznal, že char je 8 bitový

To, že se počítá s tím, že char má 8 bitů, je vidět i z miliónů manuálových stránek věnovaných tématice memcpy, strcpy, atd... [2, 3, 4]. Z toho už prostě nejde ven a prakticky nenarazíte na kód, kde je int8_t místo char.

Takže ano, standard něco říká, ale v praxi to zůstává zachované a pro většinu programátorů (kromě vás) je to nepsaný standard.

[1] malloc

[2] memcpy

[3] strcpy

[4] memset

[:::]

> Toto si zarámuju, protože si to cucáte s prstu:-P

sorry, ale co kdyby sis ten standard uz fakt precetl a prestal tady ze sebe delat idiota. Diky !

[Deleted [8409]]

Vy by jste měl začít radši programovat, aby jste pochopil, o čem je řeč.

[:::]

tady se clovek fakt obcas nestaci divit - jak nekteri jedinci nejenom ze nevi nic o tematu, ale jeste vedou radoby-chytry reci...

Kopii standardu najdes treba tady: ftp://ftp.research.att.com/pub/c++std/WP/CD2/

The sizeof operator yields the number of bytes in the object representation of its operand. The operand is either an expression, which is not evaluated, or a parenthesized type-id. The sizeof operator shall not be applied to an expression that has function or incomplete type, or to an enumeration type before all its enumerators have been declared, or to the parenthesized name of such types, or to an lvalue that designates a bit-field. sizeof(char), sizeof(signed char) and sizeof(unsigned char) are 1; the result of sizeof applied to any other fundamental type (3.9.1) is implementation-defined. [Note: in par- ticular, sizeof(bool) and sizeof(wchar_t) are implementation-defined.65) ] [Note: See 1.6 for the definition of byte and 3.9 for the definition of object representation. ]

--

Objects declared as characters (char) shall be large enough to store any member of the implementation’s basic character set. If a character from this set is stored in a character object, the integral value of that char- acter object is equal to the value of the single character literal form of that character. It is implementation- defined whether a char object can hold negative values. Characters can be explicitly declared unsigned or signed. Plain char, signed char, and unsigned char are three distinct types. A char, a signed char, and an unsigned char occupy the same amount of storage and have the same align- ment requirements (3.9); that is, they have the same object representation. For character types, all bits of the object representation participate in the value representation. For unsigned character types, all possible bit patterns of the value representation represent numbers. These requirements do not hold for other types. In any particular implementation, a plain char object can take on either the same values as a signed char or an unsigned char; which one is implementation-defined.

--

takze tam mas nadefinovany jenom ze sizeof(char) == 1 a ze se do nej musi vejit znakova sada a nic o 8 bitech ! Uvedom si ze existujou hromady architektur, ne jenom x86 compatible PC.

Na wikipedii se treba pise:

Various implementations of C and C++ define a "byte" as 8, 9, 16, 32, or 36 bits[4][5]. The actual number of bits in a particular implementation is documented as CHAR_BIT as implemented in the limits.h file.

kdyz nebudes linej tak urcite nejakyh takovy architektury najdes.

takze priste az budes zase vedet o tematu uplny hovno tak bych ti doporucoval si prvne neco nastudovat... ale zvaneni je vlastne jednodussi co ?

PS: programovanim v c++ se zivim

[Deleted [8409]]

Chce to chladnou hlavu

Já přesouvám v paměti bajty, vy chary. Já se držím praxe, vy teorie.

V jazyce C je napsaná většina programovacích jazyků, takže by se toto pravidlo mělo teoreticky vztahovat i na ně, a to se nezlobte, to je z hlediska budoucího vývoje naprostá blbost.

Taky by jste se mohl povznést nad tím, jak starý jazyk C je, a kdyby jste nechtěl jen dělat flame, tak by jste musel uznat, že toto o čem se bavíme (že bajt není bajt) byla z hlediska standardu chyba. Ono je totiž nutné rozlišit, co byla znaková sada dřív, a co je dnes - já si to ASCII pamatuju ještě z atari, a i tam byl 1 byte 8 bitů.

Takto bych tuto diskuzi asi ukončil, protože nemá cenu pokračovat dál. Jen bych vás chtěl vidět, jak budete komunikovat s nějakým HW pomocí "9 bitových" bajtů. A to nemusí být ani HW. Stačí si představit už jen framebuffer, audio, načítání a ukládání souborů, komunikace přes síť, atd.

PS: Takže jste se zviditelnil, zanadával si, a doufám, že je vám teď i líp. A nezapoměňte psát neprůstřelný kód, který poběží na jakémkoliv bajtu (i třeba 8.5 bitovém:) ).

[Let_Me_Be]

Tak jestli do souboru a pres sit posilate syrova data z pameti, tak je myslim vsechno jasne a neni proc se hadat

[Deleted [8409]]

Já mám data v paměti, kde je máte vy to fakt nevím

[Jardík]

The malloc() function shall allocate unused space for an object whose size in bytes is specified by size and whose value is unspecified.

Chce to klid a asi by bylo dobré už tuto hádku skončit s tím, že pravdu nemáte.

[:::]

jenze jardiku zapomels na to ze byte nemusi byt 8b...

[Jardík]

Ukažte mi jedinou implementaci C/C++ splníjící standardy, která má velikost byte jinou než 8 bitů.

[:::]

jardiku nezlob se name ale pokud neumis pouzivat google tak ses vazne lama...

[Jardík]

No prolezl jsem 3 stránky a nikde žádnou implementaci C/C++ splníjící standardy, která má velikost byte jinou než 8 bitů, nevidím a nemám na to celý den.

[petr_p]

Veskere alokace a prace s pameti se neprovadi v bajtech ale v jednotkach velikosti char.

Ne. malloc() v bajtech.

V ne x86 je celkem normalni ze sizeof(char) == sizeof(int) a CHAR_BITS == 32 (viz. limits.h)

To je divné. Pokud sizeof() udává počet bajtů a zároveň sizeof(char)==1, pak char by měl vždy zabírat jeden bajt.

Otázka samozřejmě je, jak je definován bajt.

Ať tak nebo tak malloc(strlen()+1) by mělo být přenositelné.

Situaci, kdy char bude mít více jak 1 B, ale sizeof(char) bude vždy 1, bych si dovolil označit za chybu ve standardu, protože by tím byl popřen samotný význam operátoru sizeof().

[Let_Me_Be]

Ano v bajtech, ale bajt ve vyznamu standardu C a C++ != 8 bitu.

Nicmene porad plati 1 bajt == sizeof(char) == 1 (jenom to muze byt treba 32bitu).

[Let_Me_Be]

Resp. abych byl uplne presny tak bajt ve vyznamu C a C++ >= 8 bitu.

[kralyk z abclinuxu]

V ne x86 je celkem normalni ze sizeof(char) == sizeof(int) a CHAR_BITS == 32 (viz. limits.h)

Imho je to většinou přežitek... Některé platformy to tak mají, protže to vyplývá z tradice. Buďto jsou staré nebo tvrdošíjně odmítají přistoupit na nyní de-facto standard (ale ne ten posvěcený v dokumentech).
Nebo to taky může být kvůli různým specializovaným čipům, např. v embedded věcičkách. Různé ty codec-on-chip atp. atd. Což je imho lepší řeší přes alignment.

[Ladicek]

vyplýtvat u každého řetězce referenci na jiný řetězec a dva indexy, jen aby se mohly v 0.1 promile případů sdílet podřetězce je taky nápad jak ze cvokárny :)

To je reference na pole charů. A že řetězec je v Javě pole charů vyplývá prostě z toho, že to není nativní typ (s výjimkou řetězcových literálů a přetížení operátoru +). Sdílení podřetězců je pak spíš bonus

[Deleted [8409]]

Pak je ale nutné zavést StringBuilder šaškárnu

[Ladicek]

Jako cena za inherentní thread-safety bez jakékoli synchronizační, kopírovací nebo čert ví jaké onanie mi to přijde víc než přijatelné

[zde]

StringBuilder je super příležitost udělat stringy navíc i unique, takže současně odpadne .isEqual() či strcmp() šaškárna, a srovnání řetězců je jedna instrukce a bez jakéhokoliv sahání do paměti.

[Ivan]

Zrovna tenhle priklad je takova seda zona c++. Nedavno jsem v jedny diskuzi narazil ta to, ze se tazatel ptal proc se mu v tomhle pripade copy konstructor nevola. Myslim, ze slo o visual C++. Nekdo tak vysvetloval, ze je to podle standartu legalni a kompilator muze v tohle pripade vratit primo promennou result. Tohle chovani se da explicitne vypnout. Takze bez ohledu na STL muze tenhle kod fungovat rozumne.

[zde]

Šedá zóna ... zhruba velikosti pacifiku :)

[Ivan]

Uz to mam to. Jmenuje se to return value optimalization(RVO, NRVO).

tady

Musim rict, ze tyhle veci me od C++ docela odrazuji. Dovedu si predstavit, ze nekdo rekne ze perfektne umi Javu nebo C#. C++ ale nemuze nikdo ovladat na 100%.

[Deleted [8409]]

Jak už napovídá "return value optimalization" jedná se o optimalizace a to je na C++ právě to šikovné :)

[rastos]

Tak som sa prehrýzol cez tú diskusiu a rozmýšľam ako koreluje s výsledkami ankety Řekli byste o sobě, že umíte programovat?