Ezek a témák részben kapcsolódnak a Szoftvertechnológiai laboratóriumban folytatott kutatásokhoz, részben attól függetlenek. Számos programozási nyelvet (pl. C++, Scala, Java, stb.) érintenek, de közös bennük, hogy szükség van a fordítóprogramok működésének alapvető ismereteire, különösen az Absztrakt Szintaxisfa (AST) szerepének megértésére.
Programok energiafelhasználása
A programok energiafelhasználása egy hot topic. Vannak, akik energy-smell patterneket keresnek a forráskódban, mint portugál haveromék: link, mások mérnek, pl RAPL segítségével.
De ez olyan, mint amikor az elektromos autók környezetbarátságát nézzük: nem vesszük figyelembe az áramtermelés forrását, az akkumulátorgyárak szennyezését és energiafelhasználását. Szóval a téma a program teljes életciklusára kiterjedő energiafogyasztás becslése/mérése. Egy python program sokkal több áramot fogyaszt, mint egy C program, de mennyit fogyasztott a fejlesztése? A maintenance? A CI rendszer? Nyilván egy jó modellt kell felépíteni, sok paraméterrel, de végül is talán már vannak is ilyen modellek, csak energiafelhasználás helyett valószínűleg munkaórákat mértek. A Braga-i workshopon a keynote speaker azt mondta, hogy ez egy PhD-t érő téma és szerintem, ha jól megcsináljuk Q1 journal-t is érhet. A tipp, hogy magát a Clang fordítót vizsgáljuk.
C++ ranges
Szinte teljes az egyetértés, hogy a C++20 range-ek view-i el lettek rontva, pl. Josuttis előadása, de a Think-cell-eseknek is ez a véleménye. Szerintem lehetne egy dolgozatot írni ezekből a problémákból, és javaslatot tenni a javításra. Ugyancsak vannak tapasztalatok arról, hogy egyes esetekben (pl. filter) rejtett hatékonyság- csapdák is jelentkeznek a range-ek esetében.
Van egy jópofa példám arra, hogy a range-ek kompozíciója közel sem olyan tökéletes, mint ahogyan szánták. Mi okozza a problémát és mi a megoldás?
Ugyancsak a range-ek: Miért nincsenek parallel range algoritmusok, amikor 2017 óta van parallel STL? Lehetne csinálni? Én kísérleteztem egy párhuzamos filter_reduce-al, amiből ki lehetne indulni. Ha jól sikerül, akkor lehetne akár először egy boost könyvtárat csinálni belőle.
Párhuzamos algoritmusok
Említettem a meetup előadásomon is, hogy nagy csapda a parallel STL-ben, hogy egyes functorok kommutatív vagy asszociatív kell legyenek. Josuttis erről beszélt C++17 biggest traps korábban. Whispyvel csináltunk egy light-way könyvtárat, hogy erre felhívjuk a figyelmet, de persze ez nem igazán ellenőriz: C++Now lightning. De talán mégis lehetne valamit az ellenőrzés irányába tenni. Kaposi Ambrussal is beszéltünk róla, hogy 2 megközelítés lehet: garantáltan “jó” építőkövetkből szintetizálni a functort és akkor garantáljuk, hogy jó lesz az eredmény, vagy ellenőrizni, hogy a user jó functort írt-e. Ez utóbbi általános esetben baromira nehéz is lehet, de ki tudja,, lehet, hogy az átlag user csak egész számokat ad össze és szoroz. Akár szimbolikus végrehajtással is lehetne ellenőrizni, hogy (a + b) - (b + a) == 0 és ha azonosan igaz, akkor beláttuk (?). Talán, de lehet, hogy az élet bonyolultabb.
Meetupon beszéltem arról, hogy egyes algoritmusok parallel STL végrehajtása meghökkentő eredményekkel járhat. Készítettem egy prototípust, de rendesen le kéne implementálni, mérni.
Interfész fuzzing
Korábban két szakdolgozat, diplomamunka is foglalkozott avval, hogyan lehet a fuzzyingot felhasználni interfészek tesztelésére. Az alapprobléma, hogy amikor egy osztályt próbálunk tesztelni, nincsen igazán jó módszer arra, hogy meghatározzuk, milyen teszteket kell készítenünk. Van erről egy CppCon előadásunk. Van egy működő prototípusunk (nincs link), de pl. még nem tesztelte senki a nagyobb könyvtárakat a gyakorlatban és legfőképpen hiányzik a matematikai alapozás. Komoly kutatás lenne és cikket is lehetne arról írni, hogy mennyi teszteset kell egy könyvtár teljes teszt-lefedettségéhez, mennyit generálna egy “naiv” módszer és mennyit a mi fuzzy módszerünk.
Strong typing
Az erős típusosság Whispy előadása egy komoly probléma, különösen az, hogyan írunk át legacy C++ kódot erős típusokra. Whispyvel kidolgoztunk egy módszert C++Now előadás ami több lépésből áll. Először is, megjelöljük az AST-ben a konvertálandó elemet, megfigyeljük, hogyan terjes ez a típus az AST-ben, de nem módosítjuk a típust, csak jelöljük, kiszinezzük az elemeket az AST-ben (attribútumokkal). Eközben fel is jegyezzük, hogy milyen műveletet végeznek a típussal, ezt a fejlesztő felül- vizsgálhatja. A lista alapján le lehet generálni az új erős típust. Erről van egy diplomamunka. Whispy elkészítette a prototípust, döntően C kódra, de számos C++ nyelvi elem hiányzik. Egy cikk erről.
Egyrészt be kéne fejezni a toolchaint, hogy nagyjából működjön C++-ra, másrészt ki kéne próbálni valós kódbázison is. Lehetne egy interaktív eszköz is, ami támogatja a konverziót.
Még izgalmasabb lenne, ha tudnánk írni egy elméleti cikket arról, mik a fiktív type-ok terjedési szabályai, valami ilyen stílusban, “Ambrusozva”.
Overload inspector
A C++ overload bonyolult konstrukció. Megértéséhez Botond készített egy inspector eszközt, ami egy Clang fork. Az Overlord nem csak debugger, de profiler is, amivel mérni lehet, hogy mekkora overhead-je van az overload-nak. Ez különösen fontos, amikor mindenki std::begin(x)-t akar x.begin() helyett. Az ICPC cikk itt található. A profilingról még nem írtunk igazán komoly journal cikket. A mérések mellett ki kéne térni a jó kódolási megoldásokra, amik csökkentik a build time-ot.
További feladatok: Ahogy a Templight-ot, úgy az Overlord-ot is be kéne vinni a Clang kódbázisba. Ehhez be kell mutatni, hogy kikapcsolva minimális az overheadje. Másrészt ki kéne kisérletezni a legjobb interfészt és hibaüzeneteket.
Jó lenne az Overlord vizualizációját megvalósítani. Talán a godbolt.org-ba kéne berakni, talán egy külön eszközbe.
Másik irány: hogyan gyorsítsuk fel az overload feloldását. Botond ígéretes eredményeket ért el a cache-eléssel.
Version control coupling
Osztályok közötti coupling a szoftvermodulok közötti (valamilyen) függést jelent. Az erős coupling általában gondokat jelent, pl. maintenance szempontból. Számos coupling metrika létezik, de ezeket főként a forráskódból számoljuk. Viszont szegedi professzorok kutatták a conceptual coupling fogalmát. A conceptual coupling olyan meta információkból próbál kapcsolatokat találni szoftvermodulok között, mint pl. a kommentek vagy az azonosítók hasonlósága. Erről van cikk és egy MTA doktori is.
A szegedi kollégák megközelítésén lehetne javítani. Egyrészt csak az osztályok memberfüggvényeit vették figyelembe, teljesen elhanyagolták a globális (névtér) függvényeket, pedig pl. a std::string és std::ostream, stb. között pont ezek teremtenek kapcsolatot. Másrészt pl. ki lehetne zárni a ciklusváltozókat, stb. Meg lehetne mutatni, hogy így élesebb eredmémyeket lehetne elérni.
A másik - fontosabb - csapásirány annak megmutatása lenne, hogy a verziókezelés olyan coupling-ot jelent, ami nem mindig kimutatható a forráskódból Ilyen eset pl. amikor adatbázis vagy grafikus interface (pl. Qt) teremt kapcsolatot az osztályok között. Erről már van egy informális cikk. A szegedi cikk módszereit lehetne alkalmazni verziókezelésre, hogy matematikailag is kimutassuk az összefüggést.
Reguláris kifejezések statikus elemzése
A legtöbb programozási nyelven van valami könyvtár reguláriis kifejezések használatára. C++-ban a std::regex, a boost.regex és esetleg több más könyvtár is van. Ezek típikusan futási (konstruktor) időben ellenőrzik a kifejezés szintaktikáját. Az a feltételezés, hogy a legtöbb esetben ez a reguláris kifejezés nem változik, lehetne fordítási időben is ellenőrizni. Nevezetes kivétel a boost.xpressive, ami fordítási idejű template metaprogram könyvtár.
Elsőnek meg kéne mérni, hogy valóban igaz-e, hogy a regex minták valójában konstansok. Utána pedig kéne checkereket írni a regex ellenőrzésére. Végül jó lenne valami hibát taláni valós projekteken.
Kódmegértés
A kódmegértés problémaköre valamennyire kapcsolódik a CodeCompass témákhoz, de azoktól függetlenül is értelmezhető. Azt szeretnénk megérteni, milyen lépésekben történik a kód megértése, milyen eszközök, procedúrák segítik a kód helyes és alapos megértését.
Lehetne egy kísérletet szervezni az AI használatáról. A kérdés: mennyire segíti az AI a kód megértését, felderítését. Adott egy jól definiált feladat, aminek végrehajtása 99%-an a kód megértését, 1% a tényleges módosítását igényli. Például: módosítsuk a Xerces C++ könyvtárat úgy, hogy az XML parszer case- insensitive módon működjön. Ez egy strcmp helyett egy stricmp kicserélése, de nem mindegy, hogy hol. Biztosítunk teszt esetet is, ami ellenőrzi a megoldást. A kísérleti csoport AI-t használ, a kontrol csoport nem. Milyen idők alatt végzik el a feladatot? Lehet-e az ellenőrző tesztet is generálni az AI-al? Mav-e különbség, ha csak prmptolunk vagy ha más AI módszert használunk?