Portál AbcLinuxu, 2. května 2025 10:00
31.10.2008 14:49
Darth Phantom | skóre: 18
| blog: Kelvin_Fitnick
| Doma
31.10.2008 16:18
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
To se mi líbí...
31.10.2008 16:17
31.10.2008 15:30
31.10.2008 15:58
int my_array[5] = {1, 2, 3, 4, 5};
for(int &x : my_array)
{
x *= 2;
}
x reference
A v C# je snad foreach: foreach(int i in pole_intu)
No ale obyčejný int byste tam nezměnil, protože ten referencí nebude a Integer je pomalejInteger 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čí.
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) /* ... */
}
2.11.2008 18:29
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
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ů.
(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é :)
2.11.2008 19:42
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
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).
jenom čunča použije int pro index místo size_tco je na tom čunčovskeho?
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)
char* a = ...; int i = strlen(a);a zabíjel bych :)
2.11.2008 21:35
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
2.11.2008 21:40
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
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í.
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 .-)
vim ~/.emacsoperator++(...)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++?
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;
}
nevím, jak se jmenuje, ale nesnáší C/C++ a minule seřval jednoho studenta, ať do javy netahá jeho praktiky, jakoTo 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 typuif (cislo = x) {}a že musíif ((cislo = x) != 0) {})
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.
2.11.2008 16:41
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
2.11.2008 17:29
-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
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...
Je to jako v partnerském životě: jednou nedá on, příště zase ty
> 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.
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...
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 =?
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.
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.
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.
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'...
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 )
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.
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 jenom rikam ze tahle 'vlastnost' je pekne iritujici...
malloc is in C: the common code path for new Object in HotSpot 1.4.x and 5.0 is approximately ten machine instructions.
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.
Ž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.
call
ret. Ale aby tam nakonec nebyl int a retn (snad jsem to nezvoral).
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.
V C++ je GC principielne nanic, protoze mame chytre ukazatele.chytre ukazatele jsou ve skutecnosti neuveritelne hloupe... a navic pomale...
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.
2.11.2008 12:34
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
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.
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ě.
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.
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:
struct. Vůbec se to nedalo číst, funkce halabala jedna přesdruhou, hrozný...
vim ~/.emacs
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.
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 boduobvykle 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ánkyu 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...
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ů.
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.)
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 msecsjenom 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.
vim ~/.emacs
31.10.2008 20:02
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
Myslím, že by se hodila nějaká moderní verze CFrontu, která by zvládala i C++0x.Jj, presne tak.
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.
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.
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.
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
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:
A nalistujte si otázku: "Why don't wide characters work with libstdc++?"
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?
MinGW samotne je experimentalni.
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
%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
31.10.2008 20:15
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é.
result) že při uvolňování nemá uvolnit ta data, která už patří tomu novýmu stringu, že? nebo to chápu blbě?
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; }
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) == 2Tak to si postezuj Microsoftu, protoze sizeof(wchar_t) je pod MS vzdy 2.
4.11.2008 23:09
(signed char)(-1) tak se to imho rovná (unsigned char)255, není-liž pravda?
4.11.2008 23:44
Luk | skóre: 47
| blog: Kacířské myšlenky
| Kutná Hora
není-liž pravda?Není. Protože například
(signed char)(-1) < (signed char)(0), kdežto (unsigned char) 255 > (unsigned char)(0).
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.
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.
Veskere alokace a prace s pameti se neprovadi v bajtech ale v jednotkach velikosti charToto 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
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:) ).
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.
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().
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).
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
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.