C++ Doc ======= Charakteristika --------------- Jedna se o projekt dokumentacniho systemu primarne pro jazyk C++, ovsem cely projekt by mel byt veden se zretelem na snadne dalsi rozsirovani i o dalsi jazyky. Hlavni rysy ----------- Navrh je z casti inspirovan systemem JavaDoc, ale cilem projektu je poskytnout prostredi s sirsimi moznostmi, duraz je kladen predevsim na interaktivitu prostredi, ktere poskytne uzivateli kompletni prehled o pouzitych objektech, umozni rychlou a pohodlnou cestou seznamit se strukturou zpracovanych zdrojovych textu, pohodlne v nich vyhledavat a pomuze analyzovat vztahy mezi pouzitymi objekty (objekty v tomto smyslu se rozumi deklarace a definice funkci, trid, struktur, maker, promennych apod.). Katalog objektu lze pak doplnovat o komentare a popis, coz muze byt vyuzito jak pri studiu existujiciho projektu, tak pro dokumentaci vyvijeneho projektu. Vhodne je, aby dokumentace byla vkladana ve forme specialne formatovanych komentaru primo do zdrojoveho textu (jako je tomu u JavaDocu) - umoznuje to dokumentaci psat zaroven se zdrojovym kodem bez vyuziti prostredi dokumentacniho systemu. Na druhou stranu by melo byt mozne ukladat dokumentaci (na vyzadani ci u explicitne vybranych casti kodu) i mimo zdrojovy text - toto ma uplatneni v pripade, ze si uzivatel chce delat poznamky k textum, ktere by nemel nebo ani nemuze modifikovat, ci se jedna o soukrome poznamky; tato moznost by byla zajimava specialne pri rozsireni projektu o zpracovani javovskych zdrojaku, ktere byvaji sbaleny v balicich, jejichz modifikace je dost problematicka. Temer samozrejmou funkci je vyexportovani dokumentace do HTML (resp. XML), vitane by byly importni moduly, ktere by umoznovaly primo vyuzivat existujici systemy. Jednou z klicovych funkci je zobrazovani diagramu objektovych hierachii - mozne rozsireni projektu by mohlo slouzit dokonce pro modelovani techto hierachii. Program muze zahrnovat radu dalsich uzitecnych funkci. Mezi ty "drobne" patri preformatovani zdrojovych textu podle uzivatelsky definovanych pravidel ci konverze znakovych sad nebo graficke zobrazeni zavislosti hlavickovych souboru ci jejich casti. Pripadne dale mohou byt zahrnuty funkce pro analyzu zavislosti modulu a odkazu mezi objekty pouzitymi v textu. ametu na podobne doplnky muze byt navrzena postupne cela rada, jejich pripadna realizace vsak nesmi ohrozit klicove funkce projektu a pristupovat by se k nim melo jako k uzitecnym doplnkum puvodniho navrhu. Zvlastni pozornost by mela byt venovana preprocesoru - mnohe pomucky ve vyvojovych prostredich (class browsery, viewery apod.) maji problemy, pokud je zdrojovy kod ve vetsi mire ovlivnovan preprocesorem. Korektni reseni tohoto problemu muze byt povazovano za jeden z dulezitych rysu tohoto projektu. Podobne analyzator textu musi byt mozne ovlivnovat tak, aby zvladal i rozsireni kompilatoru nad ramec ANSI normy (tj. aby ruzna compiler-specific keywords nepovazoval za identifikatory apod.). Vzhledem k tomuto pozadavku a pozadavku zmineneho v charakteristice, tedy ze projekt ma byt vytvaren tak, aby umoznoval snadne rozsireni i na dalsi jazyky, se nabizi ke zvazeni, zda by analyzator textu mohl byt rizen na zaklade gramatiky popsane v definicnich souborech pro dany jazyk. Dalsim problemem, ktery bude zrejme nutne vyresit, je spravovani dokumentace v nekolikaclennem tymu, tj. napr. jak se vyporadat s CVS systemy, jak spravovat prispevky do dokumentace od ruznych clenu tymu apod. Implementace ------------ Specialne pokud budeme uvazovat lepe rozsiritelnou variantu projektu, kdy analyzator nebude moci byt "zadratovan", aby mohl pracovat podle gramatik z definicnich souboru, bude jiste o neco pomalejsi, a vzhledem k predpokladanemu nasazeni na velkych objemech textu, bude vhodne uvazovat o ruznych vylepsenich pro zkraceni doby analyzy textu i pri jeho zmenach, jako je kesovani predzpracovanych (hlavickovych) souboru v pameti i na disku apod. Predpokladanou platformou pro realizaci je Win32, jazykem by melo byt C++, pricemz jadro aplikace musi byt napsano tak, aby bylo pokud mozno nezavisle na pouzitem prekladaci a co nejvice oddelene od GUI; tak bude mozne snadno zkombinovat obe casti projektu bez ohledu na finalni pozadavky GUI. GUI bude zrejme zavisle na pouzitych knihovnach - v uvahu pripadaji nejspise VCL (Borland C++ Builder) nebo MFC (MS Visual C/C++), nabizi se i moznost vyuziti .NET frameworku.