XCHAOS: tahle reprezentace byla zvolena, protože ve své době umožňovala maximální zobecnění. Ach jo. Opet blabolis, bez ohledu na jakakoliv fakta nebo dokonce i zakladni logiku. Mozna bys mel napsat Dennisu Ritichiemu a vysvetlit mu, jak zasadne se ve svem zduvodneni plete, nemyslis? Prece jenom, co on, trouba a spoluautor C, o tom muze vedet, ne? Je na tobe abys mu vysvetlil ze to nebylo kvuli pohodli a omezeni delky, ale kvuli "maximalnimu zobecneni" a "stejne implementaci jako na pasce" 8)


None of BCPL, B, or C supports character data strongly in the language; each treats strings much like vectors of integers and supplements general rules by a few conventions. In both BCPL and B a string literal denotes the address of a static area initialized with the characters of the string, packed into cells. In BCPL, the first packed byte contains the number of characters in the string; in B, there is no count and strings are terminated by a special character, which B spelled ‘*e’. This change was made partially to avoid the limitation on the length of a string caused by holding the count in an 8- or 9-bit slot, and partly because maintaining the count seemed, in our experience, less convenient than using a terminator.
http://cm.bell-labs.com/cm/cs/who/dmr/chist.pdf

No mne by furt zajimalo k cemu to pomaha. Protoze je tady s nama nejakejch 40 let a algoritmy jsou presto pro stringy zname delky.
Z tveho podani mam dojem ze "kdyby byly stringy nezname delky, tak se zacnou delat algoritmy na veci nezname delky." Jenze ony jsou a presto nedelaji.

a ad magneticka paska a hypoteza o zvoleni.. kdyz to nacitas z pasky, *musis* tomu naalokovat pamet. A pokud mas drahou pamet, tak si nemuzes az tak moc dovolit picoviny s reallocem, nebo si ji moc rozfragmentujes. Pokud by to bylo jak rikas, tak by fce co s tim pracujou musely umet pracovat se stringem co neni celej v pameti..

(jestli něco Denis a Ritchie fakt posrali, tak to nebyl formát null-terminated string, ale standardní libc funkce scanf() - pozor, ne fscanf(), ten je už ok...)

REDGUY: je to metafora a má cenu do toho tahat streamy: v unixu prostě všechno bylo navržené tak, aby se to co nejvíc podobalo něčemu jinému: string na co já vím, magnetické pásce mohl být implementovaný stejně, jako string v (tehdy ještě) drahé paměti RAM. tahle reprezentace byla zvolena, protože ve své době umožňovala maximální zobecnění.

XCHAOS: null-terminated string je metafora pro obecný stream znaků neznámé délky - Houbelec. Za prve, null terminated string neni v kontextu teto debaty nejaka "metafora", ale konkretni zpusob implementace. Nema smysl tahat do toho streamy, protoze o nich neni rec. Rec je o tom, jake vyhody ma _v_operaceni_pameti_ reprezentovat textovy retezec bud null-terminated, nebo s explicitni delkou na zacatku. Obecne reci o tom, jestli v nejakem kyberprostoru existuji veci nezname delky jsou irelevantni.

Ale hlavne, za druhe - v pripade null terminated stringu to neni tak, ze by jeho delka byla nejak obecne neznama nebo dokonce potencialne promenna behem zpracovani, tak jako u souboru nebo streamu. Ten string je ulozenej v pameti, bylo potreba pro nej naalokovat konkretni misto, ta ukoncovaci nula je na nejake konkretni pozici. Delka toho retezce _je_ pevne dana. Problem neni v tom ze by to byla neznama informace, problem je ze pro programatora je relativne drahe tu informaci ziskat (na rozdil od alternativniho zpusobu implementace retezcu).

XCHAOS: To zalezi jak to beres, tu obecnost. V null terminated stringu zas treba nemuzes mit nuly.

(když jsme u toho, tak obecný iterátor for_each() - v Python jakékolivfor - by vlastně měl umět pracovat s kontejnery, jejichž délka v okamžiku otevření ještě není známá... ale to už jsme odbočili).

s trochu nadsázky lze říct, že v podstatě v prostředí, ve kterém všechno víme předem, ani není důvod něco programovat :-)

DAVIDOWITCH: no já jsem v podstatě chtěl říct, že null-terminated string je prostě obecnější datová struktura, než string známé délky - je to o tom, že s tím můžeš pracovat, i když o tom máš předem míň informací, během práce o tom shromáždíš míň informací, apod.

nechtěl jsem zabředat do megaflejmu - jen poukazuju na to, že ty dva přístupy nejsou ekvivalentní, a že to není jen o tom, že by se vynálezci Céčka nějak svévolně rozhodli mezi dvěma rovnocennými alternativami a zvolili tu horší.

REDGUY: viz výše - a viz všechno předchozí.

null-terminated string je metafora pro obecný stream znaků neznámé délky ("everything is stream of bytes - repeat until enlightened"), pravda sice jde o speciální případ, kdy je ten stream (obvykle) celý v paměti - ale pořád můžeš vzít stejný algoritmus a v něm jenom změnit "čti bajty z paměti" za "čti bajty ze souboru" nebo "čti bajty ze streamu".

obecně stejně jako máš stream neznámé délky (roura, TCP stream apod.) a soubory jako streamy, které mají v okamžiku otevření známou délku (která se ovšem může změnit !!!), a s těmi prvními můžeš pracovat jen sekvenčně, zatímco u souborů máš random seek, tak stejné je to i s těmi stringy: prostě null-terminated string je obecnější případ, ve kterém třeba dokud si ho "nepřepočítáš" ani nemůžeš náhodně seekovat.

určitě si lze představit systém / prostředí, ve kterém by si o všech objektech jakéhokoliv typu předával informace o tom, jak jsou velké - to ano. (třeba by si ani nesměl otevírat streamy po síti, aniž bys neřekl, jak jsou velké). otázka je, jestli je takováhle restrikce fakt potřeba: jestli prostě netolerovat, že "v kyberprostoru kolem tebe" existují streamy předem neznámé délky...

XCHAOS: To byla otazka. Jaka spousta. Krom toho ze ho ciste pipujes a vubec se ho nedotknes.

DAVIDOWITCH: mno, tak v unixu se právě spousta věcí dělá předtím, než je string hotovej: třeba ho posíláš na stdout a ten jde přes stdin na vstup jinýho programu... (a co je stream nebo soubor jiného, než vlastně jen hodně dlouhej string ?). prostě to vede k psaní algoritmů, které nemají spočítáno, "kolik toho je" - ale spíš se ptají a jsem už na konci, nebo ještě něco přijde ?".

v zásadě oba přístupy mají svoje závažné nevýhody, když si představíš třeba multithreading... s tím, že jedno vlákno string vytváří, a druhé se ho současně už snaží číst... jsou tam podobná dilemata, jako u všech jiných kontejnerových typů.

a šlo by vymyslet i spoustu jiných divných datových struktur: třeba by mohl existovat konensus, že pole pointerů je ukončeno NULL pointerem - nebo jiným "divným" pointerem - a tak zjišťovat jeho délku... tohle se ale na rozdíl od null-terminated stringů pokud vím nikdy neujalo...

tuším třeba pro LISP se kdysi vyráběl i speciální hardware, který nějak optimálněji pracoval s jejich specifickými datovými strukturami (ale moc o tom nevím). a "softwareová archeologie" je BTW oblíbeným námětem cyberpunkových sci-fi... a bylo by zábavné třeba jako zápletku nějaké sci-fi zapojit do hry analýzu fiktivních datových struktur objevených v operačním systému mimozemské kosmické lodi :-)

XCHAOS: podobne jako kdyz dneska pises neco (v asm) na jednochip, rekl bych. A popravde mne nenapada moc manipulaci ktery by sly delat se stringem nez je hotovej.
Pokud bys jel multithreading, tak si proste s tim reallocem uplne v haji, pokud to nebudes zamykat (a pak se nemusis vubec obtezovat multithreadingem). Pokud nemas, tak mas velmi tesne interleaved nacitani a tu operaci co zrovna delas, a to mi prijde jako velmi spatnej napad no matter what.
A i tak by to byl velmi specialni pripad, a radsi budu mit univerzalni dobrou datovou strukturu a pak specialni pro specialni pripad, nez neco co se hodi na vsecky a sity to je na necky.

(vic mne v tom prikladu desi napad, ze 16b delky by melo bejt dost pro vsechny)

XCHAOS: V cam je tedy podle tebe vyhoda null terminated stringu pri tzv "on-the-fly" zpracovani? Musim ho mit v pameti, pamet musi byt predalokovana (resp. pokud neni, musim ji reallocovat v obou pripadech)? Kde je konkretni vyhoda? Nejak mi to z tveho vysvetlovani neni jasne, prosim, vysvetli to podrobneji.

DAVIDOWITCH: mno, můžeš mít předalokovanou paměť... ale někde musíš mít uloženou tu délku, a postupně jí zvyšovat, jak ti načtený kus stringu přibývá.

a tady by bylo závislé na konkrétní implementaci, jestli by si algoritmus pokaždé sahal na místo, kde je uložená délka stringu - a nebo jestli by si to okopíroval do proměnné na začátku.

samozřejmě, u toho postupného načítání vznikne stejný problém, kdyby si chtěl třeba zavolat strlen() na začátku - jenže právě "tradiční" čtení null-terminated stringů je většinou "zleva doprava" - a ne, že se nejdřív zeptáš jak je to dlouhé.

možná, že "výhoda" o které mluvím, hrála v těch 70tých letech větší roli, než dneska... těžko říct, moc si neumím představit, jak se tehdy doopravdy programovalo.

JACHYMKO: hmm, vzhledem k tomu, že filename bývá dlouhé řádově max. desítky bajtů (tvrdý limit je tuším 256, nebo tak něco), tak zrovna TOHLE nevidím největší bottleneck POSIX API :-) (jako že několik vážných bottlenecků tam jinak existuje... hlavně, že se občas kvůli celkové koncepci práce se streamy a soubory kopírují větší bloky dat sem tam po paměti, když by se to _teoreticky_ dalo udělat jinak, apod.)

XCHAOS: Jak s nim chces pracovat, s ohledem na jeho umisteni v pameti? Bude mas predalokovanej mrak pameti do ktery ho sosas (a pak muzes mit fixed length), nebo to reallocujes jak to jde, a pak s nim nemuzes delat vubec nic, protoze ti skace pameti jak nadmuta koza.

(je to opět odbočka k mému filosofování o tom, že algoritmy pracující s případy, kdy "víme, kolik toho bude", jsou úplně jiná kategorie, než algoritmy třídy "nevíme, kolik toho bude...)

jako já jsem o tomhle přemýšlel docela hodně, a musím se null-terminated stringů v některých ohledech zastat. především: ve chvíli, kdy se string začíná zpracovávat, vlastně ještě vůbec nemusíme vědět, jak bude dlouhý !

dnes si všichni představují, že string na začátku vždycky musí být _někde_ v paměti... ale to prostě není pravda. null-terminated string může vznikat a být spracováván on-fly, a jeho zdrojem může být nějaké sériové zařízení (dnes nejčastěji TCP stream, historicky třeba sériový port...). V podstatě díky koncepci null-terminated stringu můžeme např. pracovat se stringem, jehož začátek už dorazil v prvních packetech - zatímco konec je pořád ještě na cestě.

ANT_39: A ten strom odkazu, co od tam vede, taky neni spatnej, btw.

JACHYMKO: Ono obecne The Old New Thing je drobne cteni. Pro me nejzajimavejsi tam je ten neustalej (az do nedavna?) duraz Microsoftu na zpetnou kompatibilitu skoro za kazdou cenu a dusledky, jaky to ma. Sice to neni pristup kterej bych zvolil ja, ale plne je chapu.