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.

XCHAOS: Ja to nepouzil stylem AS IS ale vykopiroval a modifikoval jsem co jsem potreboval, takze primej example nemam.

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

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

jinak pole proměnné délky vzniká (pokud to dobře chápu) na stacku, takže ho nejde například vrátit z funkce, ne? což samozřejmě znemožňuje napsat intuitivní konkatenační funkci... ta musí pořád alokovat... (taky v dokumentaci to používají jako náhradu za alloca(), tzn lokální alokaci na stacku)

WILD_A: neznám?

XCHAOS: Docela sikovny, v kodu C99 to pouzivam, vubec C99 vidim jako posun do predu, akorat teda prenositelnost je mistama slabsi. Ale jinak C99 preferuju ve spolupraci s Pythonvskym pycparserem se pak daji delat pekny veci, jako generovat kod z komentaru a pod.

ha... pole proměnné délky v C99? (místo alokace...)
GNU C Language Extensions
http://tigcc.ticalc.org/doc/gnuexts.html#SEC76

http://stackoverflow.com/...s-the-worst-real-world-macros-pre-processor-abuse-youve-ever-come-across

baví mi např.:
#define ever (;;)
for ever {
...
}

ale já raději používám
#define loop while(TRUE)
:-)

jinak tohle
http://chaos-pp.cvs.sourceforge.net/chaos-pp/order-pp/example/bottles.c?revision=1.10&view=markup
pro mě určitě bude mocný zdroj inspirace :-) ale řekl bych, že moje nápady jsou stručnější:

http://chaos-pp.cvs.sourceforge.net/...vc/chaos-pp/order-pp/inc/order/rec.h?revision=1.6&view=markup

jinak samozřejmě, dostal jsem se k tomu přes hledání tohohle :)

https://gist.github.com/jcromartie/238308

ale samozřejmě, nemám tak nízké cíle.

BTW $ v názvech maker gcc toleruje kvůli nějaké historické kompatibilitě s VMS (a jde to zakázat, ale defaultně je to povolené)