• ú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
    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...
    REDGUY
    REDGUY --- ---
    XCHAOS: nesouhlasím s tvojí definicí "rozbitosti", tečka. Njn. To je tvoje svate pravo. Pokud ti prijde pricetne uz treba jen to, ze pro jeden ucel musis pouzivat dva ruzne systemy, tezko ti neco vysvetlit.

    Ale dobre ze nevyrabis treba auta. Tiskova zprava XChaosWagen: Kdyz stahnete okenko naseho noveho ChaosMobilu az dolu, auto vybouchne. Neni to chyba, je to popsane v manualu a nesouhlasime s vasi definici rozbitosti. To ze ostatni auta stahnuti okenka az dolu umoznuji bez nejmensich problemu ani to ze auto na blizici se vybuch nijak neupozornuje neni ekvivalentni vyroku "je to rozbite" 8))
    ISTEVE
    ISTEVE --- ---
    Tak prosim chvili premejslej. Pokud bys delal umelej SIGFPE abys delal exceptiony, tak musis:
    1) (jednou) Zaregistrovat signal handler. Signal handler neni context-aware, tudiz potrebujes mit kod kterej bude z dalsich dodatecnejch informaci schopnej identifikovat co se ma vlastne udelat, a kam se ma vlastne skocit.

    2) (tolikrat kolik hazis exception) Vygenerovat signal. Jsou zde dve varianty:
    2.a) kill(), proste ten signal manualne poslat. Jinak receno, dva kontext switche, pac je to syscall.
    2.b) Fakt udelat floating point exception, tzn. umyslne delit nulou. Dva kontext switche + ten interrupt prijde od CPU (coz netusim jestli pridava nejakou cenu navic, ale implicitne bych veril ze muze).

    3) (pro vyvojare) Bud ustanovit omezeni, ze SIGFPE je signal kterej aplikace pouzivajici tvuj jazyk nemuze odchytavat (coz by bylo dost smutny), nebo vykonstruovat system kterej umozni identifikovat jestli je to SIGFPE pac se neco posralo, nebo SIGFPE pac delat exception handling.

    4) (tolikrat kolik delas odchytanou exception) Kdyz uz jsme si ten signal vygenerovali, musis odchytit signal. Coz by mel bejt dalsi nejmin jeden (spis dva?) context switch.

    Nevidim vyhody.
    XCHAOS
    XCHAOS --- ---
    (BTW...nikdy jsem třeba o C++ neřekl, že je "rozbité", jen proto, že mi přijde moc složité, a programuje se v něm jinak, než jsem zvyklý...)
    XCHAOS
    XCHAOS --- ---
    REDGUY: nesouhlasím s tvojí definicí "rozbitosti", tečka.

    "funguje to jinak, než jsem zvyklý" není ekvivalentní výroku "je to rozbité".
    Kliknutím sem můžete změnit nastavení reklam