REDGUY: mno, ve skutečnosti mě ohledně tohohle napadlo jedno řešení - ukládat tu velikost PŘED ten předávaný odkaz - takže by si současně předával odkaz na první znak řetězce (či prvek pole, apod.) - a současně měl k dispozici i velikost (protože úmluva by byla, že by to tam dával už malloc()...). (toto je BTW kompatibilní s "kanonickým" C a já silně uvažuju, že to ve své "mikroknihovně" použiju).

ale trvám na tom, že pro mě zajímavější informace je "kolik mám celkem místa" než "jak dlouhý je tenhle konkrétní string. (netvrdím, že každý to musí nutně vidět jako já... ale ty vůbec máš zdá se problém přijmout takovéto vidění světa "já mám pravdu, a ty máš taky pravdu" - celkově je mi sympatický přístup "je více způsobů jak to udělat" - viz Lary Wall, autor Perlu - než takovéto "je jediný nejlepší způsob a ten vám všem vnutím"... prostě někoho baví lyže, někoho snowboard...)

XCHAOS: spoustu věcí se stringem (předávání reference, porovnávání, apod.) lze dělat aniž bych věděl, jak je ten string dlouhý - ano. Ale otazka kterou by sis mel polozit je, u kolika z techto operaci ti nejak _vadi_ ze mas na zacatku napsanou delku retezce. V jakych situacich te to (v soucasne dobe) stoji neco zasadniho navic oproti zero-terminated? Jak caste ty situace jsou? A naopak, pokud tu explicitni informaci o delce nemam, v jakych situacich me to boli? A jak caste jsou? Polozil sis tyhle otazky?


ale kdybych se u každého pointeru i pole mohl zeptat "kolik mám místa ?" - nu, na to staci pouzivat rozumejsi jazyk, pro ktery pole neni jen flak pameti, ale chytrejsi objekt, ktery o sobe dokaze neco rict, napr. prave celkovou velikost.

REDGUY: no jak říkám, studuj si jaké zdroje chceš, hlavně když máš dobrý pocit z toho, že urážíš druhé. (s tím se v životě určitě neztratíš... ušetříš za antidepresiva a tak...)

mě víc než oficiální zdůvodnění zajímají takové ty podprahové důvody... skutečně mě přijde podstatné, že spoustu věcí se stringem (předávání reference, porovnávání, apod.) lze dělat aniž bych věděl, jak je ten string dlouhý. popravdě - kromě informací, které potřebuju nebo které by se teoreticky mohly hodit, mě zajímá třeba i přemýšlet, které informace vůbec nepotřebuju...

ale co. jinak zajímavější je třeba debata, jak zjistit, kolik bylo pro který pointer alokováno.. tuším jsem tady postnul odkaz na nějaké GNU-only varianty tohoto, pro gnu libc malloc... (?) už jsem to ale zapomněl. proběhlo to pozoruhodně bez komentářů.

copak délka stringu.. .ale kdybych se u každého pointeru i pole mohl zeptat "kolik mám místa ?" .... jo, tak to by bodlo.

XCHAOS: hlavně, že TY víš, proč se tak rozhodli, že jo - no, ja to vim mj. proto, ze jsem si precetl zduvodneni napsane primo clovekem, ktery tak rozhodl. A pri vsi ucte, to mi prijde jako _mnohem_ verohodnejsi zdroj nez nejake tvoje blaboleni o "zobecneni". Ale samozrejme, jestli ani tohle zduvodneni ti neni dost dobre... nic jineho bych od tebe necekal 8) Jak jsem psal, napis mu, vysvetli mu jak to vlastne tenkrat myslel 8)

A btw, co tvuj "jazyk"? Uz jsi vymyslel jak fixnout problem s returnem? Nebo porad trvas na tom, ze rozumne reseni je proste return uprostred funkce nepouzivat? Nebo snad dokonce zkusis pouzit nejakej pricetnej zpusob psani vlastniho jazyka (gasp!)?

REDGUY: no ale hlavně, že TY víš, proč se tak rozhodli, že jo. díky tomu už je naštěstí zbytečné, abych se o nějaký odhad snažil já...

(já nepopírám, že obě řešení mají svoje pro a proti, ale faktem je, že ten článek který si odkazoval, se tvářil, jako kdyby kopírování stringu byla nejčastější operace - což v C, vzhledem k tomu, že od začátku bylo koncipované na předávání referencí na stringy a ne vytváření jejich kopií.... no nic, no)

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...)