DANIELSOFT: a teďka ještě vidím v man gcc

-E Stop after the preprocessing stage; do not run the compiler proper. The output is in the form of preprocessed source code, which
is sent to the standard output.

Input files which don’t require preprocessing are ignored.

já popravdě pořád ještě bojuju s pokušením místo generování C kódu vymyslet nějakou sadu C99 maker a funkcí a typedefů, která mi umožní psát pro mě příjemný kód, který se přímo přeloží jako C zdroják :-) ale pohybuju se s tím dost v kruhu, přiznám se - když člověk jednou přičichne k jednoduchosti pythonu, tak pro něj C začne být najednou pracné :)

(jinak parserů textu jsem v životě napsal už několik, a nepokládám to za extra složité - ostatně kontextové gramatiky a zásobníkové automaty jsou jedna z věcí, ze kterých jsem na VŠ zrovna nepropadl ...a může být pro mě jednodušší nějaký vlastní napsat, než se učit nějaký cizí... jde v podstatě jen o to, aby se tam nemuselo volání metody objektu "číselná konstanta" psát 0..něco nebo (0).něco - jako v Javě - protože 0.něco je chybný zápis plovoucí desetinné čárky :-))

jedna z věcí, na kterých trvám, je ale rozhodně to, aby pro mě vygenerovaný C mezi-kód byl srozumitelný (ať už ho vygeneruju parserem, nebo makry)

BTW, lze zavolat gcc v režimu "pouze C preprocesor"? to by mi pro debugování čehosi, v čem se vrtám, docela dost pomohlo .-)

ANT_39: Myslel jsem si to, nikdy jsem na to totiz nenarazil.
V tomhle je ten clang dobrej, prace s AST je tam snadna.

WILD_A: Ne, GCC generovat C neumi.

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.

ANT_39: to jsem neznal, dík...
Simplified Wrapper and Interface Generator
http://www.swig.org/

ANT_39: Jezis, to tam nemaj ani v pdf... tak latex :-)

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.

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.

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.

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

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

XCHAOS: Mne ani to C++ nevadi kdyz je to rozumnej subset, bez zbesilyho template metaprogramovani a boostu a podobnych veci.

ANT_39: Mne maintenance nevadi, honit bugy me docela bavi :) ... navic delat na free/open source projektech mne osobne i dava smysl.

(http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/ )

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.

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.