REDGUY: ?

XCHAOS: třeba v DOSu/Borland C to stálo fakt za houby Coz mame dvacet let za sebou a porad nic, ze...

REDGUY: ono to tam podle mě není proto, protože se právě počítalo, že na platformách s menším množstvím zdrojů bude nějaká hodně minimální verze malloc()... (třeba v DOSu/Borland C to stálo fakt za houby... hlavně možnost znovuvyužití uvolněné paměti byla mizerná, pokud se free() nezavolalo ve správném pořadí, tak se vlastně nemuselo volat vůbec...)

JACHYMKO: jako já jsem popravdě s C stringy celkem spokojen (nebo spíš "smířen")... ale chybí mi nápad, který by mohl vést k "pěknému" for_each() pro běžná C pole.

víceméně jsem měl dva nápady: pro pole pointerů by mohlo pole (např. pole pointerů) končit prvním NULLem nebo nějkaým NIL-symbolem (např. pointer na svůj vlastní začátek - ale tím nepředáš dílčí část pole). a nebo mě napadlo ukládat tu velikost před první prvek - jenže tím taky nepředáš dílčí část pole.

takže ano - u velikosti čehokoliv je tu základní otázka "kam s ní ?". kdybych vymýšlel nějaký "meta-objekt", který by se předával všem funkcím, apod. místo primitivního datového typu, tak by určitě měl dva základní atributy - "kolik toho je" a "kde to je" (třetí atribut by mohl být pointer na pole handlerů ošetřujících základní metody - aneb ještě atribut "co to je").

jenže to už člověk zase vymýšlí nějaký objektový jazyk, a éé... když si to nakousl, tak možnost rozdělit jakýkoliv primitivní string nebo primitivní pole ve stylu "hlava | tělo" (případně v pythoním duchu [offset:délka] ) je prostě intuitivně dobrá.

pokud máš kontejnerový objekt s dalšími informacemi (o jeho velikosti, apod.), tak prostě když chceš předat jeho podmnožinu, tak musíš vytvářet kopii paměti... naproti tomu C stringy, C pole a spojové seznamy (moje oblíbené :-) jsou tři primitivní kontejnerové typy, kde geniálně "přeskakovat začátky". dobře, ne každý algoritmus vyžaduje přeskakovat nějaké začátky :-) ale stejně... není to taková samozřejmost, že něco takového jde.

XCHAOS: no ale ty programy občas potřebují vědět, kolik je tam k dispozici místa - tak znovu: kdyby to opravdu potrebovali vedet a bylo by nejak zasadne tezke tuhle potrebu nejak obejit, _davno_ by byla soucasti standardni C knihovny funkce size_t getSizeOfMallocatedBlock(void *);. Pokud neni, usuzuji z toho ze to programy bud vedet nepotrebuji, nebo (a to spis) pricetny programator dokaze tuhle informaci ziskat v pripade potreby relativne bezbolestne jinak (treba tak, ze pokud vi ze ji bude pozdeji potrebovat, tak si velikost alokovane pameti zapamatuje v okamziku alokace).

REDGUY: no ale ty programy občas potřebují vědět, kolik je tam k dispozici místa :-)

jako tady už padlo hodně obvinění, která ta či ona vyšší abstrakce v C chybí (refcounty, apod.) - no a já tedy dodávám, že umět zjistit kolik mám místa by nebylo od věci (jak jsem vyhrabal dříve - v glibc to nějak jde, ale nevím jestli to je standardizované)

XCHAOS: že pro mě zajímavější informace - obavam se ze v realnem svete je zcela irelevantni co je zajimave pro tebe nebo pro me, dulezite je, co potrebuji vedet ty programy. A ciste evolucne vzato, vzhledem k tomu ze "kolik mám celkem místa" (v alokovanem bloku) v normalnim C zjistit nelze, zatimco "jak dlouhý je tenhle konkrétní string." je standardni funkce, prijde mi odpoved asi jasna 8) Kdyby to bylo nejak zasadne potreba, davno to je standardni soucasti libc.

JACHYMKO: jo vidíš, pointery dovnitř stringu jsem měl celou dobu na jazyku, ale ne a ne mě to jako argument napadnout :-) to samé jsem říkal i o těch spojových seznamech, BTW, apod. :-)

(těší mě, že jsem vymyslel stejnou blbost jako Microsoft, BTW :-)

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.