• úvod
  • témata
  • události
  • tržiště
  • diskuze
  • nástěnka
  • přihlásit
    registrace
    ztracené heslo?
    XCHAOSANSI C/C99 (specifikace), GNU C (gcc, glibc), Tiny C (tcc) a POSIX - ne nutně C++,g++,libstdc++ nebo Win32 API
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    http://www.hpl.hp.com/personal/Hans_Boehm/gc/
    (asi najdes lepsi zdroje, ale tohle vypada jako slusnej zacatek)
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: no tak o tomhle toho moc nevím, nahoď odkaz
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Tak muzes do gcc pridat nejaky hooky, ted uz to zvlada jakous takous garbage collection, tak treba se prilipnout k tomu...
    XCHAOS
    XCHAOS --- ---
    ISTEVE: no, já bych skoro řekl, že signal-safety je dost podobné téma, jako thread safety... dost problémy stejného druhu, hlavně s globálními proměnnými.

    (kdysi jsem krátce spolupracoval s jednou firmou, jejíž hlavní starost byla, abych ze svého zdrojáku vyházel všechny globální proměnné ... víceméně, bylo to dost poučné, no...)
    XCHAOS
    XCHAOS --- ---
    ISTEVE: tak já se především o odchytávání signálů zatím nikdy nepokusil... zatím jsem nepsal nic takového, co by to potřebovalo. (nejčastější mi přijde znovunačtení konfigurace po odchycení HUP - hangup ... a možná nějaké korektní ukončení při odchycení TERM ... ale já to zatím nikdy nedělal)
    XCHAOS
    XCHAOS --- ---
    nebo ještě jinak - z předchozího příkladu v Pythonu nevyplývalo jasně tohle:
    >>> a=[1,2]
    >>> b=a
    >>> b[1]=3
    >>> a
    [1, 3]

    víceméně - podle mě každý začátečník, který se dostane v Pythonu takhle daleko, je velmi zhruba zralý přejít na můj dialekt C<<1. zatímco aby přešel na tradiční "liturgické C", které obajuje id REDGUY, tak by toho musel chápat výrazně víc.
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: mno, víceméně... jak říkám, Python dělá něco podobného: rovnítko vytváří referenci na objekt, zatímco + alokuje nový objekt pro kopii toho původního:

    Python 2.7.1+ (r271:86832, Apr 11 2011, 18:05:24)
    [GCC 4.5.2] on linux2
    Type "help", "copyright", "credits" or "license" for more information.
    >>> a=(1,2)
    >>> b=a
    >>> b
    (1, 2)
    >>> a=a+b
    >>> a
    (1, 2, 1, 2)
    >>> b
    (1, 2)
    >>> b
    (1, 2)

    tedy... víceméně, mě se + jako operátor konkatenace moc nelíbí, protože
    mojí základní myšlenkou pro C<<1 je jednotný alokátor, který by ideálně měl stejnou syntaxi pro alokaci jednoho objektu i pro concatenaci.

    např. str s=get(str,"text") je téměř identické s str s="text" - takový zápis je nesmysl. ale pro zřetězení, např. tr s=get(str, a," ", b) už to smysl dává.

    víceméně, kde jsem se zasekl je, že dnes jsou v módě nejen iterátory přes kontejnery, ale i generátory - např. v pythonu takové to pole=[prvek for prvek in ...] ... a udělat nejen univerzální iterační, ale i univerzální generační makro - tzn. takové, které by výsledek operace ve scope na konci PŘIDALO do kontejneru - na tom jsem se zasekl, to už v C vymyslet nedovedu :-)
    ISTEVE
    ISTEVE --- ---
    XCHAOS: Samozrejme, ze muze prijit v prubehu volani. Z toho jsou hilarious chyby.

    A pokud jsi nevedel tohle, pak dalsi interesting fact: Spousta funkci standardni knihovny je implementovana tak, ze pouziva nejakej buffer jako globalni promennou. Takze, kdyz udelam trivialni priklad:

    void le_sighandler(int signum) {
      printf("Yo dawg, I herd you like printf, so I put some printf in your printf."); // printf_sighandler
    }
    
    foo() {
      signal(SIGWHATEVER, &le_sighandler);
    
      printf("printfing %s", "like a boss"); // printf_foo
    }


    ...
    pak muze probihat exekuce tak, ze:
    1) vleze se do printf_foo
    2) printf_foo neco malo dela, a uklada si to do onoho globalniho bufferu -- jeste ale neskoncil
    3) prijde signal SIGWHATEVER, a spusti se le_sighandler
    4) printf_sighandler vyhodi do bufferu to co ma, flushne ho na stdout, a sighandler skonci
    5) onen globalni buffer nyni neobsahuje to co obsahoval v bode 2, ale nejakej podezrelej bordel (jako treba prazdnej string)
    6) printf_foo vesele pokracuje
    7) ???
    8) PROFIT

    ...tohle je samozrejme vseobecne platnej princip, ale printf priklad je takovej hezkej
    XCHAOS
    XCHAOS --- ---
    ISTEVE: no jo no... Pascal :-) jako v Pascalu to bylo tak nějak mlhavé ... a používalo se to hlavně na spojové seznamy... třeba místo předávání odkazů na hodnoty funkci tam byly řešené jakési "vstupní a výstupní" parametry funkce (o kolik elegantnější je v Pythonu jednoduše možnost aby funkce vrátila více hodnot (stub) - a aby nalevo od příkazu přiřazení byl prostě stub s názvy referencí ! popravdě - je to právě elegance Pythonu, kvůli které se jakéhokoliv zabředání do C++ dost štítím...)

    víceméně - já se snažím obejít celou záležitost se spojovými seznamy tím, že na ně bude poskytnutý nějaký framework. dnešní vyšší jazyky toto obvykle obchází, a tváří se, že si kontejnerové typy pořeší samy: Python i PHP přichází s dynamicky nafukovacími klasickými i asociativními polemi, a tváří se, že je implementují dostatečně dobře. Tedy: od žádného Python/PHP codera se v podstatě nečeká, že bude sám řešit nějaké dynamické spojové seznamy, jako se to očekávalo od programátorů v Pascalu.

    můj přístup je kompromisní: chci lidem dodat hotová makra pro manipulaci s několika různými základními kontejnery, včetně spojového seznamu. v kombinaci s immutable stringy po vzoru Pythonu.

    Python nemodifikovatelností stringu před "prostým uživatelem" tak trochu maskuje, že "všechno je je jen reference" - prostý uživatel na to překvapeně narazí až ve chvíli, kdy udělá referenci na kontejnerový typ, a zjistí, že se odkazuje pořád na tu stejnou kopii v paměti - ale po zralé úvaze, kdy mi to nejdřív dost zvedlo ze židle, se nyní domnívám, že právě toto je ten správný "lék", který by mohl učinit C přístupnější "masám" - víceméně: C s immutable stringy a s několika rozumnými makry na manageování předdefinovaných kontejnerových typů zabíjí více much několika ranami: jednou takovou mouchou je práce s utf-8 stringy (v takovém případě zapomeňte na indexování stringu integerem!), jinou mouchou je právě pointerová gymnastika, kterou je možné "decentně zakrýt".

    víceméně - můj dialekt by mohl lidi dovést k tomu, aby používali C, aniž by mu rozumněli, což z něj právě dělá "kreolštinu" mezi programovacími jazyky. je to taková "turistická verze" Céčka :-) bude dobrá k tomu, abyste si na baru mohli objednat panáka a tak :-)
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Pockej, takze predpoklad je ze nekdo bude psat dobrej optimalizovanej Cckovej kod, a nebude vedet jak vypada CPU uvnitr? Ani na urovni "veci jsou na adrese" a proc se ma predavat odkazem a ne hodnotou? So ti myslim ze zadny mnozstvi abstrakce nezachrani, pokud tam vyslovene nebude compiler kterej dela "aha, tady chtel predavat odkazem, akorat o tom nevi, tak to udelam za nej".

    Ad vyjimky v C++, chovaj se povetsinou hnusne, dost dojizdej na law of leaky abstraction a spousta lidi co znam ma vyjimky (a RTTI) vypnuty, protoze to zere vykon a neni spis to mate nez aby to pomahalo. (Premejslim co krom typeid na parenta a dynamic_cast vlastne umre na zakazany RTTI, nic dalsiho mne nenapada)
    XCHAOS
    XCHAOS --- ---
    ISTEVE: technický dotaz - on vlastně může signál přijít UVNITŘ volání nějaké funkce z userspace knihovny, co ? no ty jo...

    jinak v Pythonu se mi tedy stisknutí Ctrl+C interpretuje jako chyba ? potom ovšem už chápu, proč guruové kritizují používání obecného, nespecifického except ! to totiž může vést k ještě divnějším koncům, než by člověk čekal...

    popravdě: o tom, jak se chovají vyjímky v C++ až tak moc nevím, a o Pythonu akorát chápu, že jsem ty vyjímky používal spíše špatně.

    ale co s tím ? jaké chování by tedy očekával C programátor, u konstrukce try { } ? tedy, jaké chování by asi C programátor očekával u neodchycené vyjímky, aby to nebylo "proti synergii jazyka" ? (čisté C má ve zvyku chyby samo o sobě ignorovat - nicméně já bych měl tendenci nespecifickou vykímku aspoň zalogovat... zalogovat každé POSIX errno, resp. každý POSIX strerror, který nastane "pod kapotou" frameworku - v "čistém" C kódu by byla tendence tyto chyby ignorovat - zatímco já bych měl tendenci neodchycené vyjímky na konci programu vypsat (nebo je nechat programátora odchytávat z aběhu a logovat)
    ISTEVE
    ISTEVE --- ---
    XCHAOS: "žádný jiný jazyk nepřišel s * a & gymnastikou, například" [citation needed]

    ...sice to neni konkretne hvezdicka a ampersand, nicmene treba Pascal: http://www.hkbu.edu.hk/~bba_ism/ISM2110/pas065.htm
    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: ale ok, teď kromě provokativní odpovědi ještě vážná:

    tedy - v C je skutečně pár věcí, které mě pro začátečníka přijdou neintuitivní. žádný jiný jazyk nepřišel s * a & gymnastikou, například: já se před setkáním s C letmo setkal se Z-80 assemblerem, takže jsem okrajově chápal, o čem je řeč: Z-80 mělo jak instrukce pro práci s obsahem registrů, tak instrukce pro práci s pamětí na adrese uložené v registru. z tohoto úhlu pohledu C tak nějak od začátku dávalo smysl - což třeba z úhlu pohledu člověka, který začínal co já vím - skriptovacími jazyky, či objektovým programováním ? - by podle mě bylo úplně jinak (i když i mě trvalo dlouho, než jsem pochopil, že hlavní trik C je v tom, že "pod ním" už vlastně nic není, že je to jen "koberec na tvrdé podlaze", a ne kapota pod kterou je nějaký motor)

    skutečně - uvažuji o dialektu, které by některé složitější koncepce C umožnil "obejít" - mj. i začátečníkům, pokud budou mít tu odvahu. má snaha má tedy "obfuskační" charakter - protože se víceméně chystám předstírat, že je to jednodušší, než to ve skutečnosti je. (nicméně - toto je přesně v duchu celé tradice osobních počítačů jako takových - ty se od začátku snažily předstírat, že s počítači jako takovými je to daleko jednodušší, než to ve skutečnosti bylo...)
    ISTEVE
    ISTEVE --- ---
    ANT_39: Ah, vida! Jo, vicemene se zvysi uroven abstrakce o jedna (interrupt vector -> signaly -> signal-generated exceptiony), ale smysl to dava -- mam dojem, ze zrovna SIGINT python prevadi na KeyboardException. Problem co zminujes se signalem uprostred longjmp by asi sel resit tim, ze bys signaly na zacatku jumpu blokoval a na konci odblokoval.

    XCHAOS
    XCHAOS --- ---
    DAVIDOWITCH: tedy, já v podstatě k programování přistupuju spíše jako k sociálnímu a psychologickému experimentu, než že bych doopravdy čekal, že to bude k něčemu dobré.

    moment, kdy lidi něco nečekají, a současně to není nebezpečné (což v případě unixové userspace aplikace, kterou nepustíte pod rootem, je podle mě splněno), mě přijde zajímavý: moment překvapení podle mě souvisí s tím, kdy nějaká činnost přestává být řemeslem/rutinou, a stává se uměním. a mě pochopitelně zajímá programování co by "liberal art" - nikoliv programování coby "hardcore science".
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    XCHAOS: Tak ten hlavni problem s tim neni v tom ze by to bylo rozbitelny, ale v tom ze to nema co se rozbitelnosti synergii se zbytkem jazyka. Vetsina veci se v Ccku rozbiji.. nejak, a to tvoje se rozbiji jinak, coz lidi nebudou cekat a budou se to muset naucit. A pak holt nastava klasicka otazka, what price glory?
    XCHAOS
    XCHAOS --- ---
    ANT_39: přesně tak jsem to měl na mysli: dát lidem možnost odchytit třeba ctrl+c pomocí try { } ... jenže zase bez varování je to relativně neintuitivní.
    XCHAOS
    XCHAOS --- ---
    REDGUY: no, až na to, že v C jsou moje nebezpečná okénka alternativa k traktoru, který nemá kapotu a tudíž ani okénka, což je z tohoto hlediska bezpečné :-)

    hele, tvoje debata je marná, protože prostě nedokážeš vyvrátit výrok, že "v C lze snadno napsat potenciálně nebezpečný či chybný kód, který se bez varování přeloží". to, že se nebezpečný či chybný kód v C dnes většinou nepíše, je spíše zásluha jakési "profesní tradice", než že by dostupné konstrukce naplňovaly tvojí definici "nerozbitosti".

    můj framework v tomhle ohledu nebude lepší ani horší.
    ANT_39
    ANT_39 --- ---
    ISTEVE: Mam za to, ze to mysli naopak. Signal by generoval longjmp, ktery by tvuj setjmp odchytil. Coz imho dava smysl, mozna by to mohlo i fungovat, ale neni to urcite zaruceny. longjmp neni async-signal-safe, cili nikdo nevi, co se stane, kdyz je signal doruceny uprostred volani longjmp.
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    Hele, ten SIGFPE, deleni nulou. Vzdyt IEEE754 deleni nulou v pripade precise modelu jednoznacne definuje, ne? kdyz delis kladny cislo, tak deleni kladnou nulou je +inf, deleni zapornou je -inf. Kdyz zaporny tak opacne.
    Az kdyz delas 0/0, tak mas NaN a serious problem.
    Ty inf hodej vyjimku vzdycky, nebo jen ve fast modelu, nebo...
    Kliknutím sem můžete změnit nastavení reklam