• ú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 --- ---
    DAVIDOWITCH: tohle už tu probehlo aspoň 2x .. princip chápu, ale pro množství paměti, které dnes může být alokováno, mi to přijde už krajně nepraktické.. nemluvě o vyswapovaných programech, apod.
    XCHAOS
    XCHAOS --- ---
    REDGUY: já bych zůstal u toho "jednodušší" , do bezpečnostních debat bych se nerad pouštěl (zvlášť ne v tomhle klubu / při použití C)

    víceméně, pokud runtime aspoň občas něco dealokuje, aniž by ses o to musel sám zasloužit - tak to podle mě jednodušší je.
    REDGUY
    REDGUY --- ---
    ANT_39: Pocinaje tusim 10.5 je v OSX Objective-C s garbage collectorem, ale vzdycky jsem myslel ze GC se tyka jen Objective-C objektu. Ale na druhou stranu tomu houby rozumim protoze ObjCuju jen na iPhone a tam GC jeste neni.
    ANT_39
    ANT_39 --- ---
    DAVIDOWITCH: Ja si vlastne vybavuju ze ObjC jde kompilovat s garbage collectorem (misto toho retain/release a releasepoolu z GNUStep). Tak mozna to jde zapojit i do normanich appek...
    DAVIDOWITCH
    DAVIDOWITCH --- ---
    ANT_39: No ja mam prave dojem, ze nabizi nejakou GC podporu i kompilovany aplikaci (pamatuju si to z nejakejch zprav ze tim resej firefoxi memory leaky na linuxu). Ale jistej si tim nejsem, not that kind of engineer :-)
    REDGUY
    REDGUY --- ---
    XCHAOS: 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ží" - ano, to nedokazu, proto se o to ani nesnazim. Na druhe strane, vyrok "XChoas se uspesne snazi navrhnout system, ktery alokaci pameti v C zjednodussi a ucini ji bezpecnejsi" lze vyvratit zcela trivialne, poukazem na jednu z mnoha chyb v designu jeho systemu.
    ANT_39
    ANT_39 --- ---
    ISTEVE: Otazka zni, jak ty signaly po longjmpu odblokujes? V tu dobu uz jsi jinde... Hmm, hadam, ze kdyz to bude maskovany v tech makrech, tak by to za tebe mohlo expandovat makro za kazdym try { a catch {.

    DAVIDOWITCH: Tak tomuhle nejak nerozumim. GCC ma preci GC pri kompilaci, jak to pomuze?
    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...)
    Kliknutím sem můžete změnit nastavení reklam