XCHAOS: že '+' je v C vždy jen nějaký druh matematické operace - zatímco v C++ to může být téměř cokoliv Jestli je tohle tvuj jediny argument, pak je tady samozrejme snadna pomoc: vis ze te vubec, ale vubec nic nenuti overloading v C++ pouzivat? Ze z nej muzes pouzivat jen to co chces - a mam velmi intenzivni pocit, ze to co chces od sveho jazyka C++ zcela bez problemu splnuje (resp. je mnohem snazsi naucit ho to nez to slozite roubovat na C). Nebo si myslis neco jineho? Ktere vlastni chces mit ve svem jazyce, ktere v C++ nejsou/nejdou?

ANT_39: lojban neznám, ale esperanto vnímám jako vceklu fascinující záležitost.

(BTW, dobrý nápad by bylo rozšířit Google translate i na programovací jazyky ... :-)

XCHAOS: Primer s prirozenymi jazyky kulha. Kdyz uz, tak to, co delas, je vylepsovani esperanta smerem, kde uz je lojban (treba strojova analyza, nebo se ti libi zasobnikove operace), ale lojban samotny nechtes, protoze je divnej.

REDGUY: Záhlaví se od poslední návštěvy nezměnilo. ... aneb http://en.wikipedia.org/wiki/International_Obfuscated_C_Code_Contest

... víceméně, jde mi jen o to, že tajně doufám, že můj výtvor do této soutěže jednou někdo přihlásí. stačí ? :-)

MAZA: já jsem neřekl, že je něco POTŘEBA.

mě prostě C++ nějak nebere, a zajímám se o spolupráci s lidma, které taky nebere. zajímavé je, že kdyby šlo o lidské jazyky, tak bys neřešil, že někdo studuje němčinu a jiný francouzštinu a jiný španělštinu.

samozřejmě... můžeš zpochybňovat, že se někdo bude snažit psát v němčině milostnou poezii a jiný bude chtít ve francouzštině velet nějakým vojenským jednotkám a ještě někdo další bude ve španělštině chtít dojednávat vysoce abstraktní mezinárodní finanční transakce.... já ani nijak neříkám, že je C extra vhodné pro to, s čím si hraju... ale pořád věřím, že bude existovat určitý omezený okruh lidí, kterým to přijde zajímavé.

(víceméně: já nemám jiný argument pro preferenci C před C++, než je tem, že '+' je v C vždy jen nějaký druh matematické operace - zatímco v C++ to může být téměř cokoliv, podle typu objektu, pro který ten operátor přetížíte - sice chápu, že se někomu jinému přesně kvůli tomuto C++ líbí.. jenže mě se přesně kvůli tomuto nelíbí)

XCHAOS: Mozna by ses mel rozhodnout o co ti vlastne jde. Vytvorit vylepsene C jako general-purpose jazyk? Udelat verzi C jako jazyk pro zacatecniky? Zbastlit si neco jako experimentalni projekt, mirenej ne na prakticke pouziti, ale na podivani se jak to zhruba muze byt implementovano? Neco jineho? Co se pamatuju, tak Cll1 jsi postupne, podle toho jak se ti to zrovna hodilo, vydaval za kazdou z tehle variant (plus jeste treba superefektivni dialekt pro kosmicke sondy 8) ). Pro diskusi by bylo velmi prinosne, kdybys jasne napsal na co miris, akorat ze to potom trochu komplikuje pripadne zmeny cile podle okamzite potreby 8)

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