• ú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
    ANT_39
    ANT_39 --- ---
    WILD_A: Ne, GCC generovat C neumi.
    WILD_A
    WILD_A --- ---
    XCHAOS: Pokud chces jen generovat C kod z neceho jinyho tak bych na to sel mozna pres clang, sice je to c++ ale celkem smysluplny a clang AST je masivni a da se v nem vyjadrit spousta veci a navic umi plivat z AST zase zpet C. (Coz u gcc nevim jestli jde). Ja clang pouzil jen na statickou analyzu teda, ale prislo mi to snadny a jasny.
    XCHAOS
    XCHAOS --- ---
    ANT_39: to jsem neznal, dík...
    Simplified Wrapper and Interface Generator
    http://www.swig.org/
    AFRI
    AFRI --- ---
    ANT_39: PDF je tady
    ANT_39
    ANT_39 --- ---
    ANT_39: Jezis, to tam nemaj ani v pdf... tak latex :-)
    ANT_39
    ANT_39 --- ---
    XCHAOS: Jeste me napada, jestli by v tomhle ohledu neumel pomoct swig. Napsal bys backend pro tu svou notaci a nechal to vygenerovat C bindingy...? Hmm, nevim, ale mozna to stoji za podrobnejsi pruzkum.
    ANT_39
    ANT_39 --- ---
    XCHAOS: Delal jsem na to pred par lety diplomku, neni to vyslovene slozity. Dneska je ta codebase jinde (mmj. v c++, ze ano), ale dost z toho by mohlo byt porad aplikovany.
    XCHAOS
    XCHAOS --- ---
    WILD_A: tak gcc frontend by me zajmal.. ja mam vymyslenej dynamicky typovanej objektovej model pro cisty C (ne C++), a kdyby takovy kod slo generovat z nejaky lidsky syntaxe (typu Python), tak si myslim, ze by to bylo docela zajimavy... no ale mam ted rozpracovanych veci furu, takze tohle nema prioritu.
    WILD_A
    WILD_A --- ---
    ANT_39: Brno mam rad, ale rodinu tam tedko z prahy neprestehuju, bohuzel ...
    gcc je peknej mazec, zkousel jsem psat front end (jen ze zvedavosti) a ta hora maker moc srozumitelna nebyla, to je pravda, ale jinak vetsina veci co jsem videl byla v normalni GNU C coz se dobre da.
    U C++ sablony nevadej pokud se to neprehani, jako treba v boostu, je to mnohdy elegatni reseni, ale aby se chybovy hlaseni compileru neveslo na 2-3 radky protoze se rozepsala nejaka sablona s kryptickym textem, to mi prijde uz trochu moc. Vzdyt i to LLVM se docela da a ze to je nabobtnalej projekt.
    ANT_39
    ANT_39 --- ---
    (Ona je teda otazka, co povazovat za typicky. Mel jsem na mysli hlavne codebase GCC a GDB, z nichz kazda je vyrazne vystredni. Takovy elfutils na druhou stranu jsou celkem cisty GNU C :) Asi je u toho C obecne mensi sance najit vyrazne hnusnej nebo divnej kod, akorat jsem po dlouhodobem vystaveni Boostu nejak znecitlivel.)
    ANT_39
    ANT_39 --- ---
    WILD_A: Tak koukni, jestli neco najdes ;) http://jobs.redhat.com/ Muj tym konkretne hleda nekoho na maintenance toolchainu na powerpc ;)
    Akorat, mam za to, ze u vetsiny tech pozic budou chtit, abys byl fyzicky pritomnej v Brne. Remotee se da domluvit, a u nekterych pozic je primo uvedeny, ze je to akceptovatelny, ale neni to bezny.
    Jinak k tem "rozumnym subsetum"--podivej se, jak jsou napsany typicky open source veci. "Rozumny subset" neplati ani u C++, ani u C. U jednoho tam dost casto nejaky sablony budou, u druhyho to zas bude makromasturbace, coz dokaze byt jeste horsi :) (I kdyz od te doby, co GCC umi unwinding makroexpanzi, tak se to ladi trochu snaz.)
    WILD_A
    WILD_A --- ---
    XCHAOS: Mne ani to C++ nevadi kdyz je to rozumnej subset, bez zbesilyho template metaprogramovani a boostu a podobnych veci.
    WILD_A
    WILD_A --- ---
    ANT_39: Mne maintenance nevadi, honit bugy me docela bavi :) ... navic delat na free/open source projektech mne osobne i dava smysl.
    ANT_39
    ANT_39 --- ---
    WILD_A: Red Hat tenhle druh pozic polopravidelne miva, ale velka cast te prace byva maintenance, takze a) novyho kodu clovek typicky moc nepise, a b) nejakej cas urcite stravis Red Hatima procesama a praci s internima nastrojema; oboji je celkem stejna otrava jako v kazde jine firme.

    Zase jsi ale placenej za praci na zajimavych codebase, nedavno treba hledali maintainera pro Python na sekundarnich architekturach (powerpc, s390, ARM), coz mas prakticky garantovany, ze se zvrtne v neco zajimaveho :) A treba kolega se dostal na QA pozici, a behem snad dvou, tri let presel na vyvoj GCC, a ted pise UBsan.
    XCHAOS
    XCHAOS --- ---
    WILD_A: určitě je to vhodný se tady zeptat. já bych o takovou práci taky stál... ale je vzácností narazit na to, že hledají fakt C a ne C/C++ ... já mám ten problém, že C++ prostě nestravuju.
    WILD_A
    WILD_A --- ---
    Mimochodem, nevim jestli je to tady vhodny, ale neshani nekdo C vyvojare na *nix based systemy?
    WILD_A
    WILD_A --- ---
    XCHAOS: Ja to nepouzil stylem AS IS ale vykopiroval a modifikoval jsem co jsem potreboval, takze primej example nemam.
    XCHAOS
    XCHAOS --- ---
    WILD_A: existuje někde example využití C API k tomuhle? (já ve zdrojácích hledal jen jejich dynamická pole, a dost mi zklamala, popravdě)

    (pokud tuhle debatu sleduješ dýl, možná tušíš, že já fandím spojovým seznamům...)
    WILD_A
    WILD_A --- ---
    XCHAOS: Neni to json parser, ale vlastne generator kodu, kterej to cpe do struktur, ktery se v komentarich nejak popisou.

    Jinak asociativni pole v C je imho nejlepsi obslehnout z Pythonu jejich dictionary object, aspon ja to tak udelal, rychly a dostatecne obecny.
    http://svn.python.org/projects/python/trunk/Include/dictobject.h
    http://svn.python.org/projects/python/trunk/Objects/dictobject.c
    Kliknutím sem můžete změnit nastavení reklam