XCHAOS: jj, nactes buffer, prohodis buffer.. u tech utf8/16 musis poresit kdyz budes mit na konci bufferu jen pulku znaku.
Ale nechces mmapnout a jit odpredu-odzadu, protoze se v tom souboru useekujes xmrti.

DAVIDOWITCH: no, myslím to lze číst pořád od konce... nevím jak utf-16 ale utf-8 je snad dělané tak, že poznám, jestli sem přečetl začátek nebo ten doplňkový fragment (?), základ je vzít poslední dvouznak a rozhodnout se, jestli je to x+1 nebo 1 znak? prostě revertovat po bufferech načítaných z disku a vždy se rozhodovat, jestli mi něco zbývá.. voser, ale oddebugovatelný (jako ale napsat to z jedný vody načisto bez debuggingu bych si fakt netroufal :-)

XCHAOS: Jop, posral sem to.

Kazdopadne, ten out-of-core je zajimavej. Kor kdyz clovek zjisti ze ani 128GB pameti neni dost :-D

DAVIDOWITCH: jo, no, mě zmátlo těch 8 bitů (nejen mě)

ANT_39: Pravdu dis, sem to psal narychlo mezi meetingama :-)

XCHAOS: Ma.. ale ja pomerne explicitne psal utf16 ;-)
A mmap je jen metoda jak dostat stranku co zrovna chces do pameti. Kdyz na tom zkusis random access pres celou pamet, tak umres at to mas mmapem nebo manualne.

ANT_39: AFAIK utf-8 má 127 8bitových znaků (překryv s běžným ASCII). můžeš použít nějakou knihovnu, která ti to do paměti načte jako wchar_t, pravda...

DAVIDOWITCH: (Asi myslis bud 16 nebo 32 bitu.)

DAVIDOWITCH: jo, iteraci přes utf8 znaky jsem tuhle (asi před 2 lety) zkusmo dělal :-) myslím, že to řazení pozpátku bych tam pořád zvládl v nějakém 2*n čase (strlen + jeden průchod), s tím utf-8 je to každopádně dobrá demo úloha pro tu miniknihovnu/sadu maker, co mám rozpracovanou.

"když se to nevejde do paměti" je už zajímavější úloha... tohle jsme samozřejmě v 90tých letech byli zvyklí pod DOSem řešit pořád... dnešní přístup je naopak mmap souborů a práce se soubory jako kdyby byly načtené v paměti. kombinaci "nevejde se do paměti" + utf8 bych asi řešit nechtěl...

JANFROG: zrovna treba u nekterych implementaci lispu se to zjistovat docela da, obzvlast kdyz to jsou cisty funkce, nicmene v praxi je to vetsinou zbytecny.

XCHAOS: Je to ciste skolni uloha, ale ma spoustu fajn figlu. Jako treba jak to udelas aby to fungovalo na utf16 (tj. kazdej znak ma bud 8 nebo 16 bitu, podle flagu v nejvyssim bitu).
Nebo co udelas kdyz se to nevejde cely do pameti.

Pricemz pristup do out-of-core dat je dulezitej pro.. no skoro vsechno.
I kdyz klasictejsi otazka na tohle bejva na sort.. mas obrovsky mnozstvi dat na disku, nevejde se to do pameti, chces je seradit, jak to udelas?

(Dalsi dobra uloha je, ze mas obrovskej log, nekolik TB, a chces z nej random 10k pro nejaky statisticky zpracovani... jak vyberes 10k radek abys nemel zbytecny IO)

DAVIDOWITCH: tohle přece za mě zoptimalizuje kompilátor, riiiiiight? ;)

JANFROG: KEYMASTER: Jo.. byl tam strlen

for(int i = 0; i < strlen(str); ++i)
std::swap(str[i], str[strlen(str) - i - 1]);

(tj. nejenze to neprohodilo, ale mel tam to N^2 hned 2x)

JANFROG:
char* previous = malloc(1);
previous[0] = 0;
for(int i = 0; i < strlen(input); ++i) {
char* next = malloc(strlen(previous) + 2);
next[0] = input[i];
for(int j = 0; j < strlen(previous)+1; ++j) {
next[j+1] = previous[j];
}
previous = next;
}

Víc to naprasit nedokážu. Dealokace paměti vynechána z důvodu optimalizace, někde jsem četl že free je pomalý a všechna pamět se stejně uvolní po skončení programu.

WILD_A: Tak hlavne pointa je v tom, ze u HLL - pokud jeho VM za neco stoji - ani nemuzes vedet, co se skutecne provede dokud ten program nespustis nad konkretnima datama...takze IMHO ani nema cenu s tim nejak operovat...

DAVIDOWITCH: Ja to pochopil tak, ze by vykon mel byt bran v potaz, ne ze jde hlavne o vykon.
string reverse v N^2 je ovsem vic nez snaha zbytecne neoptimalizovat, to je presnej opak :)