XCHAOS: Ano, to je samozřejmé, ale proč si zbytečně přidělávat práci, když už tu abstrakci někdo provedl? Na kole v batohu také můžu vozit štěrk, ale když ho potřebuju převézt tunu, je lepší pohlédnout se po jiném způsobu dopravy. Každý nástroj má své určení.

Kolik lidí používá HLA? Jaká aplikace je v něm napsaná? Kolik lidí potřebuje objekty v Cčku, když je tu C++, které je umí a umí je dostatečně dobře a nativně, rozhodně mnohem lépe, než C kdy bude?

tak jo... tak hodíme za hlavu tu nostalgiii, a vrhneme se opět na mudrování o tom, kudy a zda vůbec vede cesta do budoucnosti pro ANSI C a zejména jeho aktuálnější verze (C99, případně C0x - tedy pokud bude vyhlášené nejen C++0x ale i C0x) ?

máme zde celou škálu přístupů, od konzervativního "malloc a free musí stačit každému - aspoň vím co dělám, když to dělám" (toto je srovnatelné s přístupem "masturbace je TAKY bezpečný sex - aspoň nikdo neotěhotní" :-) - až po různé více či méně extravagantní přístupy.

já popravdě v poslední době víc přemýšlel o těch metaobjektech, které by měly doplňující informace někde na adresách ptr-1, ptr-2. vlastně nejsou ani tak neslučitelné s tím "vykrajováním" podmnožin z primitivních datových struktur - naopak, pokud je metaobjekt doplněný informací o reálné délce, tak je možné ho použít k předání k sub-pole či sub-stringu i jenom s minimálním množství přídavných informací - a navíc je to argument proti NULL terminated stringům.

představuju si to asi nějak takhle:

ptr - odkazuje přímo na string, začátek C pole, apod., je indexovatelný pomocí C hranatých závorek, apod. - ovšem pozor, může to být taky přímo int, long, float...
ptr - 1: obsahuje pointer na "interface" objektu (a tedy lze z toho vyčíst i typ objektu)
ptr - 2: obsahuje informaci o aktuální velikosti
ptr - 3: obsahuje informaci o alokované velikosti
ptr - 4: reference counter (sic! ale "klonovací funkce", vytvářející nový metaobjekt, bez skutečného kopírování samotného obsahu paměti, by ho mohla vždy aktualizovat... )

výhody:

- jednotlivé instance metaobjektu se deklarují prostě jako pointery na daný primitivní typ
- přiřazení = zůstává přiřazením, vytvořením další reference (myšleno reference na úrovni C zdrojáku, ne nové reference ve smyslu zvýšení počtu metaobjektů odkazujících na stejný flák paměti)
- "interface" může snadno obsahovat sadu základních "metod" - typu serializace, zjištění délky, ověření validity obsahu, apod.
- vytvoření "klonu" metaobjektu nebo "vyříznutí" podmnožiny objektu nemusí být spojené se skutečným kopírováním obsahu paměti
- konvence, která by předpokládala vždy volání funkcí interfacu (např. length() apod.) a ne přímé čtení paměti, by elegantně řešila např. přístup k metaobjektu typu FILE, apod.
- makra, určená na přístup k interfacu objektu, by mohla teoreticky před voláním kontrolovat, zda na adrese ptr -1 je skutečně odkaz, na nějaký definovaný interface (pomalé, ale robustní - použitelné pro případ, že by definovaných interfaců byl jenom nějaký předem známý, nízký počet)

nevýhody:

- totální průser pokud někdo tenhle přístup použije na nekompatibilní pointer (ovšem toto je v C průser vždy, takže jsme jenom tam, kde jsme byli od začátku)
- totální průser, pokud to celé zapomeneme inicializovat
- zbytečné plýtvání pamětí pro metaobjekty typu int, long, apod. a netriviální zápis matematických operací (na drouhou stranu - nepředpokládá se, že by se to na toto používalo)
- pokud chceme zobecnit např. i na spojové seznamy, tak bude nutné předdefinovat nějaká pevná pravidla jak vypadají (např. "na začátku každého záznamu je vždy odkaz na další záznam)
- pochopitelně tím nezískáme automatické uvolnění paměti (ale zase s rozumnou správou paměti může počítat inicializační funkce, "konstruktor" metaobjektu)

JACHYMKO: jen bych doplnil, ze takto prece fungoval i starej znamej Novel Netware. ke svemu startu potreboval DOS (ne nutne od MS), pricemz jej pozdeji dovedl z pameti odstranit (netware ale pak neslo ukoncit jinak nez resetem).

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