News
Actual
Earlier
Lectures
Prog. Languages 1
Advanced C++
Generative Prog. (Ph.D.)
Software Metrics (Ph.D.)
Bolyai Math-Info seminar
GAMF
Dept. of Informatics
MIN1G2
MIN1J1
Research
Generative programming
Publications
Projects
Student thesis
Co-operative education
Simpeer
OO Metrics on .NET
IKKK
Contact
Contact
Lesson schedule
Curriculum Vitae
Links
Links
|
|
| Thesis |
Sorry, the english version is
unavailable at this time!
Kedves Hallgatók!
Az alábbiakban néhány olyan érdekes kutatási témát találtok, amelyeket
én is elég érdekesnek találok ahhoz, hogy a témavezetésüket elvállaljam
:-).
Az egyes témákon belül lehetnek átfedések és kidolgozottságuk is
eltérő lehet, attól függően, hogy nagyprogram (Np), szakdolgozat
(Sz), diplomamunka (D) vagy TDK (D) készül. A konkrét dolgozatok
célkitűzései mindig személyreszabottak. |
| 1. Alternatív template könyvtárak |
| A generatív programozás új, feltörekvő programozási
paradigma. Alkalmazása nem helyettesíti, hanem kiegészíti az objektum-orientált
elveket. A generatív programozás egyes ágai: a generikus programozás,
az aspektus-orientált programozás, a szándékalapú (intentional) programozás,
és más, nyelvfüggetlen eszközök, melyek helyenként már túlléptek a
kísérleti stádiumon. Ugyanakkor kifejező erejüket, erősségüket, gyengéjüket
még nem ismerjük eléggé, ezért további kutatásokat igényelnek.
Ahhoz, hogy e kutatások sikeresek legyenek, hasznos, ha több,
hasonló elven készült alkalmazás, könyvtár áll rendelkezésre, melyeket
elemezhetünk, összehasonlíthatunk. |
| 1.1. MetaSTL - STL-szerű template metaprogram
könyvtár (D, Sz, Np) |
| A Loki ma már széleskörűen elfogadott template
metakönyvtár, az STL pedig elterjedt futási idejű template könyvtár.
Sajnos, a Loki használata idegen az STL programozó számára. Jó lenne
a Loki funkcionalitását az STL-re némiképpen hasonló szintaxissal
lehessen használni. Pl. jó lenne a Typelist-et konténerként kezelni
és egyfajta fordítási idejű find, find_if, for_each, stb... algoritmust
alkalmazni rá.
Ilyen törekvések vezettek a boost::mpl kidolgozásához is. Vizsgálja
meg a boost::mpl-t ebből a szempontból. |
| 1.2. GTL - Graphical Template Library
(D, Sz, Np) |
| Az általunk korábban kisérleti jelleggel létrehozott
GTL újragondolása, kiterjesztése, elsősorban az STL mintájára. Még
több alakzat, még több algoritmus. Iterátorok, iterátor-kategóriák
(esetleg felhasználható a smart iterátorok témája (lásd: 1.6). Egyéb
STL eszközök: Functorok, Binderek, Adaptorok. Összetett objektumok.
Ideális esetben a végtermék egy teljes grafikus rajzolóprogram, amely
a GTL könyvtár szolgáltatásaira épül.
A grafikus célú generikus könyvtárak közt emlegetik a CGAL könyvtárat.
Vizsgálja meg a CGAL felépítését. |
| 1.3. MMTL - Multimedia Template Library
(D, Sz, Np) |
| A multimédia eszközök template könyvtára STL
mintára. Egyik dimenzióban a "konténerek" fájlformátumokat
reprezentálnak, másik dimenzióban a rajtuk végezhető műveletek vannak.
Speciális feladat a stream-ekre optimalizált "konténerek"
kifejlesztése. valószínűleg speciális iterátorokat is ki kell kísérletezni.
A feladat része néhány kliens program létrehozása, esetleg valamilyen
kisebb multimédia alkalmazás kifejlesztése. |
| 1.4. Q - STL-szerű burkoló írása
a QT fölé (D, Sz, Np) |
| A GTL-ben alulról felfelé építkezve hozunk
létre egy Generikus könyvtárat, itt viszont egy meglévő és széleskörűen
használt könyvtár fölé szervezünk generikus burkoló felületet. A cél
az, hogy a QT funkcionalitásának megfelelő könyvtárhoz jussunk, egy
egyszerűbb, és/vagy könnyebben kiterjeszthető interfész bevezetésével.
|
| 1.5. PTL - Pattern Template Library
(D, Sz, Np) |
| Design Pattern könyvtár megvalósítása metaprogramozási
eszközökkel. Pl. Singleton<T> megvalósítja a T típust ellenőrző
singletont. Fordítási idejű garanciák biztosítása a pattern típusparamétereivel
kapcsolatban (lásd 2.2. és 2.5.). Figyeljünk arra, hogy a pattern-eket
esetenként egymást követően alkalmazzuk. Keressünk lehetőséget arra,
hogy támogassuk az ilyen kompozíciókat. Mindehhez érdemes megvizsgálni
a már létező OOP és AOP elvű könyvtárakat. |
| 1.6. Smart iterátorok (D, Sz) |
| A generikus programozás egyik legfontosabb
komponense az iterátor, amely összekapcsolja a konténereket és az
általános célú algoritmusokat. Mégis, talán az iterátorokról tudjuk
a legkevesebbet. Az iterátor koncepció vizsgálata és lehetségzes továbbfejlesztések
kijelölése. Például iterátorok egyesítése, lazy evaluation, stb. Gyakorlati
példák definiálása, ahol a smart iterátorok használata leegyszerűsíti
vagy általánosabbá teszi a kódot.
A smart iterátorok témakörében érdemes az első C++ workshop anyagát
és a view template library-t megvizsgálni. |
| 1.7. Regular Expression Templates |
| Az expression template egy fordítási idejű
optimalizációs eljárás, eredetileg mátrix-számítások felgyorsítására
(Todd Veldhuizen). Cél egy hasonló elvű könyvtár megalkotása reguláris
kifejezésekhez, sztringek mintaillesztéséhez. |
| 1.8. Egyéb generikus könyvtárak specifikációja
és kifejlesztése (D, Sz, Np) |
| Lásd még 9. |
| 2. Statikus típusellenőrzés |
| A modern programozási nyelvek a típus fogalmán
keresztül fogalmaznak meg számos szabályt, korlátozást, és végeznek
el ellenőrzéseket, melyekkel a futási idejű programot biztonságosabbá
teszik. A típusok absztrakt leírására több elmélet és eszköz is létezik.
Úgy tűnik, az elméleti lehetőségek széleskörűbbek, mint amit a mai
programozási nyelvek a gyakorlatban lehetővé tesznek. E rés felderítése
és áthidalása javíthatja a jelenlegi nyelvek kifejezőerejét és példát
mutathat új nyelvek tervezésekor. |
| 2.1. Statikus típusellenőrzés elmélete
|
| A típusok és típusrendszerek matematikai leírása
Luca Cardelli és Ken Bruce könyve és cikkek alapján. Egyáltalán mit
lehet ellenőrizni? Kapcsolódó téma: Objekum Orientált Calculus (Csörnyei
tanár úr). Hipotézis: létre lehet hozni a fordítási idejű ellenőrzések
hierarchiáját (a Chomsky hierarchia allegóriája). Vannak egyszerűbb
ellenőrzések, melyek fordítási időben végbemennek, bonyolultabbak,
melyekhez metaprogramokat kell írni, és olyanok, melyeket csak többszöri
fordítási lépéssel lehet ellenőrizni. Az elméleti lehetőségek és a
nyelvek ebbéli "erősségének" összehasonlítása (pl. a Turing-teljes
C++ template-ek erős eszközt adnak). |
| 2.2. Statikus típusellenőrzés megvalósítása
C++ nyelven (D) |
| Statikus típusellenőrzés eddigi eredményei.
További megvalósítások standard C++ eszközökkel. Feladat további ellenőrzési
szempontok definiálása (has_virtual, default_constructible, ...) és
megvalósításuk lehetőségei. Ellenőrzések, melyekhez nem elég a standard
C++: compiler hack, többszöri compiler indítás, stb... |
| 2.3. Compiler hack (D, Sz, Np) |
| Egy vagy több C++ fordítóprogram módosítása
más módon megvalósíthatatlan típus ill. koncepció ellenőrzések elvégzésére
(lásd 2.2), vagy a metaprogram garanciák ellenőrzésére/támogatására
(lásd 4.1.), esetleg együtt a 3.2.-vel. Lehetséges célpontok: g++,
VC++, stb. |
| 2.4. Statikus típusellenőrzés a programnyelvekben.
(D) |
| Különböző magasszintű programozási nyelvek
összehasonlítása a statikus típusellenőrzés szempontjából. Minimálisan
szükséges nyelvek: C++, Java, ADA, Eiffel, funkcionális nyelvek (Clean,
Haskell, Lisp valamelyike). Példák. |
| 2.5. Patternek szemantikai helyessége
(D, Sz) |
| Vizsgáljuk meg az egyes patternek helyességének
feltételeit (típusmegszorítások, elő és utófeltételek, stb), és dolgozzunk
ki apparátust ezek formális megadására. Szóba jöhet pl. a Fóthi Ákos
féle eszközrendszer használata is. Keressünk mechanizmust arra, hogy
egy X pattern utófeltételéből bebizonyítsuk Y pattern előfeltételét.
Hozzunk létre eszközt a feltételek számítógépes reprezentálására (XML
és/vagy C++ metaprogram) és az automatikus bizonyításra (lásd 1.5.). |
| 2.6. Az STL helyességvizsgálata (D)
|
| A C++ STL library gyakran használt és jól ismert
eszköz. Részleteiben azonban a C++ standard nem túl könnyen használható
definíciókat ad rá. Például nehezen eldönthető kérdés, hogy egy multimap
megtartja-e a beszúrási sorrendet az azonos kulcsú elemek között.
Az ilyen kétértelműségek feloldására hasznos lenne az STL adatszerkezetek
és algoritmusok precíz definícióját megadni (pl. elő és utófeltételek
segítségével). További cél lehet STL-t használó C++ programok (automatikus)
helyességbizonyítása. David Musser STL-Lint nevű eszközének vizsgálata,
esetleg bővítése. (Musser és doktoranduszai által kidolgozott módszer
az STL elemeinek specifikálására és helyességvizsgálatára) |
| 3. Program/Metaprogram-fejlesztést
segítő eszközök, elsősorban debugger |
| Bár metaprogramok alkalmazása ma már nem szokatlan,
a metaprogramok írása még eléggé kezdetleges állapotban van. Gyakorlatilag
minden egyes új könyvtár létrehozása hack-elés, amelyet nem támogatnak
fejlesztőeszközök. Olyan eszközök kifejlesztése, amelyek támogatják
metaprogramok írását, tesztelését, debuggolását elsődleges fontosságú
lenne.
A hagyományos objektum-orientált programok esetében is vannak
új módszerek a fejlesztés, tesztelés gyorsítására, pl. az un. mock
objektumok. |
| 3.1. Debug standard eszközökkel (D) |
| Csak standard nyelvi eszközök felhasználása:
metaprogramok, melyek pl. log-ot írnak a példányosuló osztályokról,
assert-ek (ilyenek léteznek a Loki-ban és a Boost-ban is, de ki kéne
terjeszteni őket meta-ellenőrzésekre, pl: _nem példányosul_ az X osztály),
print-ek (melyek fordítási időben működnek, lásd a klasszikus prímgeneráló
metaprogram).
Ötlet: esetleg a "Curiously recurring template pattern"
használata:
class MyClass: public DebugMixin<MyClass> { ... }; Ilyenkor
az osztály önmagát adja paraméterül a Debugger osztálynak, ezzel
MyClass-t vizsgáló kódot hozva létre, amelyből végül örököl. |
| 3.2. Compiler hack (D, Sz, Np) |
| A cím magáért beszél. A 3.1. vagy annál bővebb
funkcionalitás megvalósítása a 2.3. eszközeivel.
Eddig felmerült módszerek: - Sablon példányosításakor üzenet kiírása
- Sablon példányosításakor új template típus (pl. DEBUG<>)
létrehozása, ennek paramétereként pl. egy TYPELIST-ben átadhatók
típusinformációk a példányosításról: egy listában a formális paraméterek,
másikban pedig a megfelelő "értékek"
- Valamilyen már meglevő típus módosítása a programban sablon
példányosításakor, pl. egy típus beszúrása típuslistába.
Hasznos lenne még a példányosításkor keletkező hibaüzenetek megjelenítése
valamilyen könnyebben olvasható formában. |
| 3.3. Metaprogramok szintaxisának javítása
(D) |
| A sablonmágia szintaxisa nemcsak nehezen olvasható,
de jelentősen különbözik is a C++ "hagyományos" eszközeitől,
ezért a többség idegenkedik a használatától. A könnyebb érthetőség
kedvéért célszerű egy egyszerűbb szintaxis kifejlesztése, pl. előfordító
makrók, esetleg valamilyen korlátozott funkcionális nyelv formájában,
ami lehetőség szerint minél jobban hasonlít a C++ nyelv többi eleméhez,
de legalábbis könnyen olvasható és kezelhető. |
| 3.4. Fejlesztési esettanulmány (D) |
| Adott egy nem működő metaprogram, pl. Unruch
prím-kiíró metaprogramja. Hogyan lehet "kijavítani"? Ötletek,
szükséges eszközök, bevethető módszerek naplószerű feljegyzése. |
| 3.5. Mock objektumok megvalósítása
C++ nyelven |
| A mock objektumok a tesztelést segítő proxy
osztályok példányai. Segítségükkel úgy válik tesztelhetővé egy osztály,
hogy nem kell a teljes környezetét, az összes kooperáló osztályt megvalósítani.
Mock objektumok megvalósítása elsősorban reflection-nel történik,
ami C++ nyelven nem támogatott. Jelenlegi implementációk Java és .Net
platformon elérhetőek (www.jmock.org és www.nmock.org). |
| 4.1. Metaprogram algoritmusok garanciái
(D) |
| Az STL garanciákat ad az egyes műveletek futási
idejű bonyolultságára. A cél hasonló feltételrendszer kidolgozása
a metaprogram "műveletek" esetére. Pl. a példányosuló osztályok
O(n) számúak, stb... Egy érdekes részfeladat a jelenlegi fordítók
vizsgálata (Veldhuizen csinált ilyet.) (Lásd még 2.3.) |
| 4.2. Metaprogram adatszerkezetek vizsgálata
(D) |
| A futási idejű adatszerkezetek különböző kategóriákra
oszthatók, (pl. az STL beszél szekvenciális és asszociatív konténerekről).
Vizsgáljuk meg ebből a szempontból a metaprogram adatszerkezeteket.
Pl. a Typelist lineáris, a Veldhuizen által az expression template-ekhez
használt adatszerkezet fa-struktúra. Vannak-e asszociatív meta-konténerek?
Milyen garanciákat lehet adni? |
| 5. Metrika |
| A szoftver bonyolultsági mértékek rendkívül
fontosak a mai szoftvertechnológiában. Egy jó metrika már a tervezési
és korai fejlesztési időszakban előrejelzéseket adhat arról, hol vannak
a rendszer kritikus pontjai (akár a fejlesztés, akár a tesztelés vagy
a későbbi karbantartás szempontjából).
A hagyományos mértékek azonban lényegében használhatatlanok az
obejktum-orientált, de különösen több paradigma együttes használatakor,
pl. generikus vagy aspektus-orientált programok esetében. Ezért
van szükség paradigma-független mértékek kidolgozására, alkalamzására,
ellenőrzésére. Ilyen mérték az AV gráf, melynek további kiterjesztése,
továbbfejlesztése, és validálása izgalmas feladat. |
| 5.1. Az AV-metrika kiterjesztése kivételkezelésre |
| Az AV gráf kiterjesztése kivételkezelésre.
A kivételkezelés ma már a programok szerves része: nem strukturált
vezérlésátadás, amit általában a kód bonyolultságának csökkentésére
használunk. Mérhető, kimutatható-e ez a csökkenés? Melyek a helyes
kivételkezelési stratégiák? |
| 5.2. Az AV-metrika kiterjesztése generic-ekre
ill. template-ekre |
| Az egyik, engem leginkább érdeklő feladat.
Az AV gráf értelmes kiterjesztése a Java-stílusú generic-ekre és a
C++ stílusú template-ekre. Nem csak definiálni kell a mértéket, hanem
mérésekkel igazolni is kell e definíció helyességét. |
| 5.3. Az AV-metrika Eclipse plugin-je
(Np, Sz, D) |
| Az egyik legnépszerűbb ingyenes fejlesztési
környezet az eclipse, melyhez bárki könnyen írhat további kiterjesztéseket,
un. plugin-okat. Az AV metrika megvalósításra került eclipse plugin-ként,
de ez még továbbfejleszthető, részben használhatóságának fokozásával,
részben a metrika újabb kiterjesztéseinek implementálásával. |
| 5.4. Aspektus orientált programok bonyolultságának
vizsgálata (D) |
| A divatos AOP programozás hívei azt hírdetik,
hogy az aspektusokkal a program szervezése áttekinthetőbb, karbantarthatóbb,
azaz egyszerűbb. Ez hihető is, a legtöbb esetben, de még jobb lenne,
ha mérésekkel is alá tudnánk támasztani ezt az állítást. Erre egy
módszer lenne pl. AOP és OOP módszertanokkal megvalósított (már létező)
patternek bonyolultságának összehasonlítása.
Brazil PhD-sek (www.cin.ufpe.br/spg) OO programokat refaktorizálnak
AOP programokra és (Java) generikus programokra. Érdemes lenne megmérni,
hogy a refaktorizáció hogyan befolyásolja a komplexitást.
Együttműködés lehetséges Awais Rashid-dal. |
| 5.5. AV metrika .Net platformon (Np,
Sz, D) |
| Program, amely egy lefordított .NET-es programot
visszafejt (CIL - kb. Java virtuális bytekód) és bonyolultságot számol
a forráskódjára. Másik megoldás, hogy magának a .Net byte-kódnak mérjük
közvetlenül a bonyolultságát. |
| 5.6. Kurrens bonyolultsági mértékek
validálása emberkísérletekkel |
| Kérdezz. |
| 6. Aspektus Orientált Programozás C++
-ban. |
| Esetleges együttműködés Szamcsival és Awais
Rashiddal. |
| 6.1. C++ alapú AOP eszközök vizsgálata
(D) |
| AspectC++, stb |
| 6.2. Aspektus orientált programozás
megvalósítása C++ nyelven (D, Sz) |
| AOP megvalósítása jelenleg standard C++ eszközökkel.
!!! Az ECOOP 2004 MPOOL Workshop-on egy indiai srác (Musser doktorandusza)
által előadott megvalósítás ötletének vizsgálata, esetleg javítása.
|
| 7. A moduláris programfejlesztés eszközei |
| Cross-cutting concerns, class families, collaboration,
aspects |
| 7.1. A CSet metakönyvtár alkalmazhatóságának
vizsgálata (D, Sz) |
| Több életszerű klienskód létrehozása a kidolgozott
könyvtárhoz, módosítási és bővítési javaslatok a könyvtárral kapcsolatban.
Például a A C++ standard I/O rendszer (sőt, a teljes szabványos könyvtár)
vizsgálata a croscutting concern-ek szerint. (fstream és ifstream
között pl. nincsen subtype reláció). A szabvány követelményeinek és
az egyes könyvtári megvalósítások áttekintése. Az input/output rendszer
átírása CSet alapon. |
| 7.2. A CSet alternatív implementációi
(D, Sz) |
| Virtuális öröklődéssel, MDSC-vel, AspectJ-vel,
HyperJ-vel, Aspect C++ -al ill. Composition Filterrel. Ezen megoldások
összehasonlítása egymással és a CSet megoldással. |
| 7.3. Chevron-shape öröklés elméleti
vizsgálata (D) |
| A chevron-shape öröklés elméleti leírása, összehasonlítása
más OO konstrukciókkal, pl. strukturális öröklés. Javaslat a programozási
nyelvek esetleges kibővítésére, hogy támogassák az elmélet által megkövetelt
igényeket. |
| 7.4. A CSet könyvtár további javításai
(D, Sz) |
| Konstans ptr, ref, lista duplikációk javítása,
esetleges további hibák és hiányosságok orvoslása. Módszer felhasználói
kód hozzáadására a komponensekből összerakott osztályhoz. |
| 7.5. Call by declaration (D, Sz) |
| Paraméterezhető mixinek (felhasznált adattagok,
függvények megadása) megvalósítása C++ nyelven. lásd Erik Ernst cikke
|
| 7.6. Reverse Inheritance |
| Közbülső osztály beszúrása az öröklődési hierarchiába.
|
| 8. Nyelvek típusosságának és egyéb
eszközeinek speciális használata |
| Kutatások során kitalált, hasznosnak tűnő új
elméletek, módszerek implementálása nyelvi bővítések nélkül, meglevő
eszközökkel. |
| 8.1. Ownership domain (D) |
| Objektumok tulajdonosának típusbiztos specifikációja,
megvalósítás sablonokkal a Java-s megoldáshoz hasonlóan. Implementáció
egyéb lehetőségei C++ nyelven.
Együttműködés Alex Potaninnal. |
| 8.2. Kétszintű programozási módszertan
(D) |
| A kétszintű nyelvtanok mintájára egy speciális
programozási módszertan, nyelv és fejlesztőeszköz kidolgozása.
Az egyik szint egy alacsonyszintű, kb. Fortran, C (olvasható assembly
:) lehetőségeivel rendelkező, párhuzamosságot és funktorokat alapszinten
támogató nyelv. Lehetőség szerint egy új, erre a célra kitalált,
hatékony, egyszerű, tiszta és típusbiztos nyelv kidolgozása.
A másik szint a metaprogramokhoz hasonlóan a fordító "átprogramozását"
teszi lehetővé, kb. egy interpreter vagy VM fordítási idejű változataként.
Lehetővé válik új típusok, műveletek létrehozása, meglevők módosítása.
AOP, generikus programozás, stb ezáltal speciális alesetként, természetesen
kezelhető, egy új (általában Java kiterjesztésként elképzelt :)
elmélet is jó eséllyel megvalósíthatóva válik ilyen metaprogramként.
Esettanulmány készítése a támogatandó eszközökről, igények felmérése.
Nyelvek és fordítóprogramok prototípusának elkészítése.
Együttműködés Zólyomi Istvánnal. |
| 8.3. Hatékonysági kritériumok specifikálása
( pl. O(n) ) |
| pl. sort( O<2>(), container) |
| 9. A Boost könyvtár |
| A Boost programkönyvtár eddigi eszközeinek
felmérése, új alkalmazási területek kutatása, a könyvtár bővítésének
esetleges irányainak meghatározása. |
| 9.1. MPL (D) |
| A Boost Metaprogramming Library vizsgálata:
alkalmazások, esetleges bővítések. Szükség esetén hasonló funkcionalitású,
de (legalább kissé) más elveken alapuló könyvtár fejlesztése. |
| 9.2. A gráf könyvtár (D) |
| A Boost STL-szerű gráf könyvtárának vizsgálata |
| 9.3. Boost tesztkörnyezet kialakítása
(D) |
| A boost::regression_test vizsgálata, használatának
ismertetése, tesztkörnyezet kialakítása saját fejlesztések céljából.
|
| 9.4. Template introspection és concept
checking (D) |
| A jelenlegi boost::concept_check könyvtár refaktorizálása
a Zólyomi-Porkoláb cikk tervei szerint. Utánanézni Terje Slettbo munkájának.
Az új introspection könyvtár átgondolása, esetleges bővítései után
a boost::type_traits segítségével implementálni a boost::concept_check
egy javított változatát. |
| 9.5. Funkcionális nyelvek kötése C++
-hoz (D) |
| A jelenlegi funkcionális nyelvekhez létező
binding-ok és a boost::binding könyvtár vizsgálata alapján (vagy segítségével)
Clean nyelvű binding kifejlesztése. További érdekes nyelvek lehetnek:
Lisp, Haskell, ML. |
| 9.6. Cache könyvtár (D) |
| Elévülő adatok hatékony tárolása, kezelése.
Ötlet: megvalósítás wrapper/adapterként, együttműködés a szabványos
konténerekkel. |
| 9.7. Egyéb boost esélyes könyvtárak
kidolgozása/tesztelése-javítása |
| Javítás, átszervezés: 1. Jeff Garland Date-Time
könyvtára 2. Arne Adams, Detlef serialization könyvtárai
Új könyvtárak: 1. Socket 2. XML 3. Thread 4. RDB (Obj-Relational
mapping, együttműködés: cache, serialization) 5. GUI |
| 10.1. Az OO és a Generatív programozás
hatékonysági összehasonlítása (D, Sz) |
| Feladattípusok keresése, ahol az egyik paradigma
jobb megközelítést ad. Konkrét mérések néhány klasszikus program esetén:
faktoriális, prímszámok, gráf-algoritmus (pl. a Prim vagy Kruskal
algoritmus általános megoldással, STL-lel (push_back() vs. reserve()),
és template metaprogramming-al. Hasonló módon történhet pl. a string-keresések
optimalizálása (adott string keresése, adott méretű string keresése,
expression template-ek használata, stb.) |
| 10.2. Többszintű modellezés (D) |
| Modellek közti transzformáció hasznossága,
pl. többszörös öröklődés transzformálása egyszeres öröklődéssé (lásd
ECOOP 2004 MASPEGHI workshop). Modelltranszformációs nyelv vagy könyvtár
kidolgozása, amely a modell változásakor csak a változások szerint
generál újra. Kapcsolat az MDA-val (Modell Driven Architecture), Stickel
Gábor? Frohner-Porkoláb-Varga cikk |
| 10.3. Elosztott adatbázisok egyes problémái
(D, Sz) |
| Elosztott adatbázisok esetén (pl. CORBA) gyakran
használunk OO konstrukciókat. Előfordulhat azonban, hogy az öröklődési
hierarchia különböző szintjein definiált attribútumok más szervereken
helyezkednek el. A jelenlegi rendszerek ezt nem támogatják. Meg kell
vizsgálni egyrészt az ilyen típusú fejlesztés támogatását, másrészt
a futás optimalizálását (a narrow függvény más szerverre irányít át).
Lásd 10.6. |
| 10.4. Független komponensek összekapcsolása
(D, Sz) |
| A jelenlegi komponensek előre elkészített konnektorokon
keresztül kapcsolódnak egymáshoz. Sok esetben azonban hasznos lehet
a konnektorok utólagos generálása, miután tudjuk, milyen konténereket
akarunk összekapcsolni. Lehetséges megoldások: AOP (AspectJ és AspectC++),
esetleg trait-ek használata. |
| 10.5. Feature-oriented programming
formális definíciója |
| ??? Coplien szerint valami szlovák arc szép
eredményeket ért el az ügyben. |
| 10.6. IDL generikus bővítése |
| Corba IDL típussal való paraméterezhetőségének
megvalósítása. Pár évvel ezelőtt az OOPSLA konferencián már elhangzott
cikk a témában, de azóta nem lett belőle semmi. |
| 10.7. Expression probléma |
| még végiggondolandó |
|
