Nebo na SIMD bez toho ze se de facto dela inline ASM a mlzi se kolem toho tim ze se tomu nadava "intrinsics".

XCHAOS: No to jo, jak to funguje uvnitr je rozhodne zajimavy.
Ale ty se to snazis vyrobit ne jak to funguje uvnitr "spravne", ale jak by to mohlo fungovat uvnitr, kdyz si dame tyhle naprosto neprakticky a vesmes arbitrary omezeni (konkretne to, ze rozsirujes definici jazyka aniz bys mel moznost sahnout na prekladac).
A to mi prijde tezce o nicem.

Nebylo by lepsi zamyslet se treba nad tim co by mohlo bejt v C0x, aby to ten jazyk posunulo a zaroven to nebylo "chceme mit C++, kterymu se bude rikat C"? Ja nevim, treba konstrukty/knihovny pro cloud computing (uznavam, ze ekvivalent pthreads neni nejlepsi napad, jelikoz pthreads nejsou ve standardu, ale treba by v C0x mohly!).

DAVIDOWITCH: chci říct, že hotovou abstrakci dnes používá kdekdo. ale někoho třeba zajímá "jak to funguje uvnitř" - podle mě je to legitimní, a podle mě lidi, které to nezajímá, mají na rovinu říct, že je to nezajímá - a nemusí od snahy pochopit to odrazovat lidi, které to třeba zajímá.

jasně, -1 moderace za odkaz na objektově orientovaný assembler... fakt "objektivní" moderace :-/

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.