[QGHG-it-dev-list] Zadatak 8 - ucitavanje kompleksa iz fajla
Marko Vojinovic
vmarko at ipb.ac.rs
Sat Nov 26 08:06:01 CET 2022
Pozdrav Dusane,
Hvala za popravke. :-)
Za curenje memorije nemoj da brines za sada --- kad budemo zavrsili sa konstrukcijom svih "elementarnih" funkcija (onih koje eksplicitno pozivaju "new" ili "delete"), onda cemo Nenad i ja da uradimo jednu temeljnu proveru svih curenja memorije i da sve zapusimo. Kad se to zavrsi, plan je da sve naredne funkcije koje cemo pisati budu "izvedene" iz ovih elementarnih, i u njima se nikad nista ne alocira "rucno", pa curenja memorije vise nece biti...
Za delimiter kapiram sta je i cemu ti sluzi, nego sam propustio da vidim definiciju u .hpp fajlu. :-) Ali sam se vise zbunio oko toga kako kompajler hoce da prihvati pozivanje f-je sa samo tri argumenta, ako je ona deklarisana i definisana da ih bude cetiri... Ali ok, izgleda je C++ tu fleksibilan, dokle god je cetvrti parametar eksplicitno definisan u .hpp fajlu. To nisam znao da moze.
Switch/case struktura u colorize_node_from_string() se ni meni ne svidja, ali neka je tako za sada --- radi nam posao, a momentalno imamo vaznije stvari da resavamo, na to mozemo da se vratimo kasnije.
Sto se tice baga sa UniqueID bojom, nemam nista protiv da to popravis kasnije, samo nemoj da zaboravis --- naznaci u kodu u komentaru da to treba da se popravi, i kako (stavi zakomentarenu ispravnu verziju koda, da posle ne razmisljamo sta i kako treba da se uradi na tom mestu).
A sto se tice ovog baga sa susedima i add_neighbor() na koji se zalis --- onaj fajl output.txt koji si mi poslao je previse nepregledan, nista nisam uspeo da vidim odatle. Pa sam zato sad implementirao f-ju
SimpComp::print_detailed()
koja na lep i pregledan nacin ispisuje ceo simplicijalni kompleks, sa svim detaljima, bojama i susedima svih simpleksa, tako da moze cela struktura lepo da se vidi, procita i prekontrolise. Pa bi bilo dobro da git merge-ujes najnoviji main branch u svoj 8_XML_reading branch, i onda mi posalji output od print_detailed() kad reprodukujes bag, da mozemo lepo da vidimo sta se tu tacno dogadja sa susedima.
Inace, koliko mogu da vidim i koliko smo Nenad i ja testirali kod, f-ja add_neighbor() radi tacno ono sto bi trebalo da radi --- dodeljuje jedan simpleks kao sused drugom, i obratno (jer je susedstvo simetricna relacija). E sad, ako joj trazis da stavi simpleks kao sused samom sebi, to je tvoj problem, tj. add_neighbor() nije kriva za to. Mozda bismo mogli da unapredimo add_neighbor() da proverava i prijavljuje gresku ako korisnik pokusava da poveze simpleks sa samim sobom (ili sa drugim simpleksima istog nivoa), ali to ce samo da maskira pravi problem koji se nalazi negde drugo --- ti generalno nikad ne bi smeo da dodjes u situaciju da se simpleks povezuje kao sused sa samim sobom, bez obzira da li ce add_neighbor() to pristati da ti uradi ili ne.
Ali 'ajde da vidimo tacno sta radi bag, pa cemo da utrejsujemo gde je zapravo greska... ;-)
I za kraj --- videh da si u triangulator.hpp dodao ovo:
class KSimplex; // Had to do a predeclaration because is used in get_color_from_str
To je visak, obrisi to odatle. Ista ta forward-deklaracija se vec nalazi na pocetku fajla color.hpp (odmah iza #ifndef - #endif strukture), i sigurno ne treba da stoji u triangulator.hpp fajlu --- tu treba da stoje samo ostale #include direktive. A forward-deklaracije mozes da stavljas u ostale .hpp fajlove gde ti je potrebno, i *ako* ti je potrebno. Naime, redosled #include direktiva u triangulator.hpp fajlu je tako namesten da smo vec pokrili sve neophodne forward-deklaracije, ne vidim gde jos moze da ti zafali neka.
Btw, nisam nasao f-ju get_color_from_str() nigde u tvom kodu, jel' to typo u komentaru? Odnosno jesi mislio mozda na f-ju get_color_value_as_str(), iz klase Color?
:-)
Marko
Dr. Marko Vojinovic
Group for Gravitation, Particles and Fields
Institute of Physics
University of Belgrade
======================
home page: www.markovojinovic.com
e-mail: vmarko at ipb.ac.rs
On Thu, 24 Nov 2022, Dušan Cvijetić wrote:
> Pozdrav,
>
> Ubacio sam komentare i doxygen dokumentaciju u svoj kod. Javite da li ste
> zadovoljni time, ili da menjam.
>
> Proverio sam curenja memorije pomoću Valgrind-a. Bilo ih je nekoliko u I/O
> delu, to bi trebalo da je sada sređeno. Postoji još curenja, ali čini mi se
> da su ona u klasi za boje, pa bi valjalo da još neko to pogleda i proveri,
> jer nisam mnogo radio sa Valgrind-om.
>
> Sad, kod:
>
> (1) Uklonjeno, bilo je višak.
>
> (2) "Nepostojeći" argument u oba slučaja je string koji predstavlja delimiter
> između elemenata niza, a u .hpp fajlu mu je zadata default vrednost ",".
> Napravio sam tako da bi funkcija bila fleksibilnija pri eventualnim kasnijim
> dodavanjima drugih formata. Dodao sam objašnjenje u komentar, pa bi trebalo
> da bude jasnije šta se dešava.
>
> (3) Slažem se, provera je suvišna i uklonio sam je.
>
> (4) Uradio po predlogu, ali svakako mislim da treba da nađemo rešenje koje
> izbegava switch u nekom momentu.
>
> Po pitanju (5) nisam ništa uradio. Postoji nepovezana greška koja se provlači
> još od prethodne verzije. Proverio sam da li problem 5 utiče na ovu grešku, i
> nema razlike ni kada unesem ispravku iz prethodnog mejla, pa sam ostavio za
> sad da bude kao i ranije, jer je preglednije šta se dešava.
>
> Već par sati pokušavam da provalim gde leži bag, ali mi se trenutno čini da
> nije u I/O kodu, već u funkciji add_neighbor(). Dodao sam u funkciju
> read_ksimplex_node() deo koji štampa izgled kompleksa nakon svakog dodavanja
> komšije nekom simpleksu, i izlaz koji sam dobio je u fajlu output.txt u
> prilogu. Da li add_neighbor() radi kako treba? Neki simpleksi su ovde dodati
> da sami sebi budu komšije, iako to nigde nisam eksplicitno tražio. Čini mi se
> da ova funkcija uvodi neku međuzavisnost kod komšija koja mi nije očekivana
> ni trivijalna.
>
> Može li još neko da pogleda ovaj problem?
>
> Pozdravi,
> Dušan
>
>
> On 20/11/2022 10:57, Marko Vojinovic wrote:
>>
>> Pozdrav Dusane,
>>
>> Evo pogledao sam I/O kod --- nisam ga jos testirao, ali ovako iz citanja i
>> pregledanja mogu da ti dam par komentara i saveta.
>>
>> Prvo, kod je super! :-) To sto je dugacak nema veze, i to sto treba
>> pocistiti detalje oko error-handling i memory leaks nije veliki problem.
>> Odlicno si uradio posao, svaka cast! ;-)
>>
>> Drugo, buduci da je kod relativno dugacak, bilo bi pametno da ubacis
>> komentare --- osnovnu ideju, bazicnu strukturu .xml fajla koji se
>> snima/ucitava, kao i cemu koji deo koda sluzi i sta radi, u glavnim crtama.
>> To je potrebno za slucaj da se kasnije vratimo na taj kod (bilo ti, bilo
>> neko drugi), da bi bilo jasno sta se dogadja i kojim redom. Komentare bi
>> bilo dobro da ubacis dok ti je cela stvar sveza u glavi, jer posle nece ni
>> tebi biti jasno sta si tu sve radio... ;-) Inace, i ja planiram ovih dana
>> da ubacim gooomilu komentara u ceo dosad napisani kod projekta, da sve bude
>> bolje i jasnije objasnjeno i dokumentovano.
>>
>> Trece, ima par sitnih detalja koje mozes malo da pocistis u kodu, u f-ji
>> read_complex_from_xml_file( rapidxml::xml_document<>& doc ):
>>
>> (1) Negde na sredini f-je stoji "bool first = true;" pri cemu se varijabla
>> first nigde kasnije ne koristi. Pretpostavljam da je to visak?
>>
>> (2) Pri kraju f-je u petlji pozivas dve f-je,
>>
>> read_level_node(current_node, sc,
>> stoi(current_node->first_attribute()->value()));
>> read_ksimplex_node(current_node, sc);
>>
>> koje imaju redom tri odnosno dva argumenta, a nize si te iste dve f-je
>> definisao kao
>>
>> void read_level_node(rapidxml::xml_node<>* node, SimpComp* sc, int
>> level, string delimiter)
>> void read_ksimplex_node(rapidxml::xml_node<>* node, SimpComp* sc,
>> string delimiter)
>>
>> tako da imaju cetiri odnosno tri argumenta. Taj dodatni nepostojeci
>> argument (string delimiter) se onda eksplicitno prosledjuje f-ji
>> parse_level(), koja ga koristi (na netrivijalan nacin). Nije mi jasno kako
>> ovo uopste hoce da se kompajlira (broj argumenata u f-jama se ne slaze), i
>> nije mi jasno gde je "delimiter" zapravo definisan? Ako je on neka globalna
>> varijabla unutar namespace rapidxml ili nesto tako, zasto ga onda
>> prosledjujes eksplicitno kao argument u parse_level(), a to isto ne radis u
>> read_level_node() i read_ksimplex_node()? Kako to sve zapravo radi?
>>
>> (3) Na samom kraju f-je, u poslednjoj petlji, brises privremene UniqueID
>> boje. Nisam siguran da li ti treba provera "if (!ks->colors.empty())", jer
>> bi svaki simpleks trebalo da ima taj privremeni ID. Naime, kad si snimao
>> fajl, f-jom save_complex_to_xml_file(), odmah na pocetku si uradio
>>
>> UniqueIDColor::colorize_entire_complex(simpComp);
>>
>> sto je obojilo bukvalno sve simplekse. Kada posle radis
>> read_complex_from_xml_file(), ti zapravo citas bas te brojeve (privremene
>> id-jeve), i struktura snimljenog fajla bi trebalo da ti garantuje da svaki
>> simpleks u novokreiranom kompleksu sigurno ima makar tu boju, ako nista
>> drugo. Pa zato ne vidim da li postoji situacija kada uslov "if
>> (!ks->colors.empty())" nije zadovoljen?
>>
>> Cetvrta tema --- pitanje sta uciniti sa f-jom colorize_node(). Moj predlog
>> je sledeci. Prvo, po nekoj ideji dizajna, f-je za I/O treba da budu
>> agnostic o tipovima i vrednostima boja, i slicnim detaljima --- krajnji
>> korisnik ce mozda zeleti da definise svoje custom boje, i da ih snima i
>> cita iz fajlova, ali mi sigurno ne zelimo da krajnji korisnik ceprka po
>> kodu I/O f-ja da bi mu to radilo. Za snimanje u fajl imamo lepo resenje ---
>> svaka boja u klasi Color ima definisanu f-ju get_color_value_as_str(), i ti
>> to koristis kada snimas boju u fajl, tako da te uopste ne zanima kako je
>> definisana vrednost boje (to je prosto neki string koji ces da snimis).
>>
>> Istu filozofiju treba primeniti i u slucaju citanja iz fajla, na sledeci
>> nacin --- prepravi f-ju colorize_node() tako da bude prosto wrapper f-ja
>> koja ce da poziva novu f-ju,
>>
>> void Color::colorize_node_from_string( KSimplex* ks, int color_type,
>> string color_value );
>>
>> i samo toj f-ji prosledi pointer ks i parametre
>>
>> int color_type = stoi(color_node->first_attribute()->value());
>> string color_value = color_node->value();
>>
>> pa ce posao te f-je da bude da oboji simpleks kako treba, a ti samo zavrsis
>> colorize_node() f-ju. Pritom, celu switch/case strukturu preseli u tu novu
>> f-ju --- ona ce da zivi u klasi Color (prebaci je u color.cpp i color.hpp
>> fajlove), i nju ce krajnji korisnik moci da azurira kada/ako bude dodavao
>> svoje custom boje.
>>
>> Ovakvim wrapper-zahvatom postizemo dve stvari: (a) dodavanje novih boja
>> vise nema direktne veze sa I/O f-jama, nego se vrsi samo modifikovanjem
>> f-ja u klasi Color, i (b) kasnije cemo mozda switch/case strukturu da
>> zamenimo necim inteligentnijim, mozda za svaku boju da zahtevamo da ima
>> definisanu f-ju set_color_value_from_str(), poput ove koju si uveo za
>> ScreenCoordinateColor, itdisl. Generalno, to sve dalje vise nije tvoj
>> problem (za I/O f-je), a klasu Color cemo verovatno jos dosta da
>> (re)dizajniramo i doterujemo kasnije (bilo ti, bilo neko drugi, bilo
>> krajnji korisnik, o tom potom)...
>>
>> Mislim da bi ovakav dizajn bio generalno mudriji, pa vidi da tako
>> reorganizujes taj kod.
>>
>> I konacno, peta tema --- cini mi se da sam pronasao i jedan mali bag.
>> Naime, u switch/case strukturi unutar colorize_node() imas izmedju ostalog
>> i sledeci kod:
>>
>> case TYPE_UNIQUE_ID:
>> color = new UniqueIDColor(stoi(color_node->value()));
>> ks->colors.push_back(static_cast<UniqueIDColor*>(color));
>> break;
>>
>> koji se izvrsava ako je snimljeni kompleks imao neke simplekse obojene
>> UniqueID bojama. Kada u nekoj kasnijoj sesiji (neki drugi main(), tj. drugi
>> program) ucitavas taj fajl i konstruises novi kompleks, moze da se desi da
>> su te snimljene UniqueID boje (iz fajla) vec iskoriscene za neki drugi
>> kompleks (seed-ovan ranije u ovoj novoj sesiji), sto vodi do dupliranja
>> UniqueID boja, sto ne sme da nam se dogodi. :-)
>>
>> Ovo dakle mora da se popravi, tako sto se dati simpleks ne oboji UniqueID
>> bojom koja je procitana iz fajla, nego mu se dodeli prvi slobodan UniqueID
>> iz tekuce sesije, ovako:
>>
>> case TYPE_UNIQUE_ID:
>> ks->colors.push_back(new UniqueIDColor());
>> break;
>>
>> Jasno, tada vrednosti id-jeva za kompleks vise nece da se poklapaju sa
>> id-jevima koji pisu u fajlu. Ali to sto se ne poklapaju niti moze da se
>> garantuje, niti je vazno --- vazno je samo da su jedinstveni, tj. da nema
>> preklapanja ni sa jednim drugim simpleksom koji je trenutno u memoriji.
>> Tako da obavezno popravi i taj detalj. ;-)
>>
>> :-)
>> Marko
>>
>>
>> Dr. Marko Vojinovic
>> Group for Gravitation, Particles and Fields
>> Institute of Physics
>> University of Belgrade
>> ======================
>> home page: www.markovojinovic.com
>> e-mail: vmarko at ipb.ac.rs
>>
>>
>>
>> On Sat, 19 Nov 2022, Dušan Cvijetić wrote:
>>
>>>
>>> Pozdrav,
>>>
>>> Dovršio sam kod za ispis u fajl. Ostalo mi je da ga iskomentarišem i
>>> ozbiljnije istestiram. Na prvi pogled se čini da radi, i da je i redosled
>>> svih stavki očuvan.
>>>
>>> Planiram, takođe, još malo da ulepšam I/O funkcije, trenutno su mahom
>>> ogromne i ružne. Ostalo mi je par nedoumica oko nekih rešenja, koja sam
>>> označio u komentarima sa // NOTE: ili //
>>> TODO:. Uglavnom se tiču izuzetaka, ili rada u okviru postojeće arhitekture
>>> (konkretno, čitanje različitih boja sam rešio putem case strukture, što
>>> možda nije najsrećnije, ali mi ništa
>>> drugo nije palo na pamet).
>>>
>>> Pre nego što nastavim sa testiranjem, imam još jedan predlog: nedavno sam
>>> počeo da učim cmake, pa bih voleo da pokušam da napravim cmake za naš
>>> projekat, ako se slažete. Tako bismo
>>> mogli bolje da organizujemo testove i kompajliranje.
>>>
>>> Pozdravi,
>>> Dušan
>>>
>>> On 10/11/2022 11:55, Nenad Korolija wrote:
>>> Zdravo Marko,
>>>
>>> Ni ja se nisam dalje bavio triangulatorom, ali sam bar završio i poslednje
>>> repove sa Amerikancima i valjda skoro sve oko papirologije za reizbor (tu
>>> je bilo komplikacija, ali će
>>> valjda sve proći u redu:).
>>> Ako ćeš imati vremena da baciš pogled na moje đubre, možda možemo i da
>>> budemo na vezi, pa da mi odmah kažeš šta da menjam (umesto da kucaš
>>> email), pa da nastaviš gledanje kad
>>> promenim...
>>>
>>> Vidimo se,
>>> Nenad
>>>
>>> On Thu, Nov 10, 2022 at 11:52 AM Nenad Korolija <nenadko at gmail.com> wrote:
>>> Zdravo Dušane,
>>>
>>> Koliko vidim, snimanje simplicijalnog kompleksa radiš redom.
>>> for (unsigned int lvl = 0; lvl < simpComp->elements.size(); lvl++) {
>>> for (auto ks : simpComp->elements[lvl]) {
>>> Dakle, verovatno je redosled snimanja i učitavanja isti, tj. nema potrebe
>>> da sortiraš po ID-u ili šta već.
>>> Dakle, trebalo bi da Markov predlog dobro testira snimanje i učitavanje -
>>> poređenje snimljenog sa onim što si nakon toga učitao pa snimio.
>>>
>>> Vidimo se,
>>> Nenad
>>>
>>> On Wed, Nov 9, 2022 at 10:52 PM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:
>>>
>>> Pozdrav Dusane i Nenade,
>>>
>>> Evo konacno sam se vratio u Srbiju i uspeo malo da se organizujem.
>>> Dosad se nisam odazivao jer sam bio bas pretrpan obavezama, nisam stizao
>>> da pogledam sta ste
>>> radili... :-( Ali nadalje cu biti malo bolji sa odgovaranjem na
>>> mail-ove. ;-)
>>>
>>> Dusane, vidim da si poceo da radis na citanju kompleksa iz fajla, i
>>> otprilike sam bacio pogled na ono sto si stavio u svoj branch dosad. Nisam
>>> testirao, ali
>>> pretpostavljam da radi, tj. da ispisuje na ekran ono sto procita?
>>> :-) Sto se tice posebne klase za I/O, svakako je napravi ako mislis da je
>>> potrebna, i Nenad i
>>> ja se slazemo. Javi dokle si stigao i kako ide.
>>>
>>> Btw, fundamentalni test za I/O moze da ide otprilike ovako:
>>>
>>> (1) seed-ujes neki kompleks SimpComp *G1 (npr. 5-sferu ili stagod),
>>>
>>> (2) snimis G1 u fajl-prvi.xml f-jom za snimanje (koju si napravio),
>>>
>>> (3) ucitas fajl-prvi.xml u novi kompleks SimpComp *G2, f-jom za
>>> citanje (koju sad pravis),
>>>
>>> (4) snimis G2 u fajl-drugi.xml f-jom za snimanje,
>>>
>>> (5) uporedis fajl-prvi.xml i fajl-drugi.xml (npr. diff-om ili cime
>>> god).
>>>
>>> Ako su dva fajla uglavnom identicna (do na vrednosti UniqueID
>>> brojeva i eventualne izmene u redosledu zapisivanja isl), test je prosao,
>>> i zadatak je resen. ;-)
>>>
>>> Osim toga, ako bi uspeo jos da namestis obe f-je (za citanje i
>>> snimanje) tako da cak i redosled kojim su stavke zapisane u dva fajla bude
>>> isti, tj. da fajlovi
>>> budu potpuno identicni (do na UniqueID-ove), to bi onda bila bas
>>> prava stvar. :-) Ali to nije obavezno --- redosled stavki u fajlovima u
>>> principu nije bitan,
>>> dokle god mozemo pouzdano da se ubedimo da fajlovi zaista sadrze
>>> iste podatke.
>>>
>>> :-)
>>> Marko
>>>
>>> P.S. Drago mi je da si se lepo proveo u CERN-u, i da postoji
>>> mogucnost da ides opet, svakako iskoristi priliku ako ti se ukaze...
>>>
>>>
>>> Dr. Marko Vojinovic
>>> Group for Gravitation, Particles and Fields
>>> Institute of Physics
>>> University of Belgrade
>>> ======================
>>> home page: www.markovojinovic.com
>>> e-mail: vmarko at ipb.ac.rs
>>>
>>>
>>>
>>> On Mon, 7 Nov 2022, Nenad Korolija wrote:
>>>
>>> > Zdravo Dušane,
>>> >
>>> > Ja se slažem. Ima smisla izdvojiti celu I/O funkcionalnost u
>>> posebnu klasu, tj. fajl.
>>> >
>>> > Pozdrav,
>>> > Nenad
>>> >
>>> > On Sun, Nov 6, 2022 at 5:16 PM Dušan Cvijetić
>>> <dusancvijetic2000 at gmail.com> wrote:
>>> > Pozdrav,
>>> >
>>> > Predlažem da se za I/O funkcionalnosti napravi nova klasa,
>>> pošto
>>> > trenutno radim na čitanju kompleksa iz fajla i imam mnogo
>>> pomoćnih
>>> > funkcija koje sam napravio, a koje trenutno plutaju u etru,
>>> pa bi bilo
>>> > lepše grupisati ih.
>>> >
>>> > Pozdravi,
>>> > Dušan
>>> >
>>> > On 30/10/2022 19:58, Dušan Cvijetić wrote:
>>> > > Pozdrav,
>>> > >
>>> > > Radim na čitanju iz fajla, pošto sam konačno prešao na
>>> Ubuntu.
>>> > >
>>> > > Da li treba sada da razmišljam i o hvatanju izuzetaka, ili
>>> je to tema
>>> > > kojoj ćemo kasnije da se posvetimo?
>>> > >
>>> > > Pozdravi,
>>> > > Dušan
>>> > >
>>> > > On 07/03/2022 06:00, Marko Vojinovic wrote:
>>> > >>
>>> > >> Vazi. :-)
>>> > >>
>>> > >> Sto se citanja iz fajla tice, obrati samo paznju kako ces
>>> da
>>> > >> instanciras UniqueID boje --- moraces "rucno" da im
>>> menjas vrednosti
>>> > >> na osnovu onoga sto procitas iz .xml fajla, jer
>>> konstruktor
>>> > >> UniqueIDColor::UniqueIDColor() zadaje te id-jeve
>>> automatski.
>>> > >>
>>> > >> Takodje, kad sve zavrsis, treba da setujes vrednost za
>>> > >> UniqueIDColor::next_free_uid_number na ono sto bi trebalo
>>> da bude
>>> > >> prvi slobodan id broj. To je valjda id vrednost prvog
>>> simpleksa u
>>> > >> fajlu, jer su oni u fajlu poredjani rastucim redom, a ti
>>> id-jevi iz
>>> > >> fajla ne treba da postoje u konacnoj strukturi u
>>> memoriji, pa bi prvi
>>> > >> od njih trebalo da bude "slobodan" na samom kraju...
>>> > >>
>>> > >> Jedino nisam siguran kako ce next_free_uid_number da
>>> funkcionise u
>>> > >> kontekstu veceg broja istovremeno instanciranih
>>> kompleksa, ali to je
>>> > >> pitanje dizajna o kome moram jos da razmislim.
>>> > >>
>>> > >> Ostatak algoritma osmisli sam, kako mislis da je
>>> najzgodnije.
>>> > >>
>>> > >> :-)
>>> > >> Marko
>>> > >>
>>> > >>
>>> > >> Dr. Marko Vojinovic
>>> > >> Group for Gravitation, Particles and Fields
>>> > >> Institute of Physics
>>> > >> University of Belgrade
>>> > >> ======================
>>> > >> home page: www.markovojinovic.com
>>> > >> e-mail: vmarko at ipb.ac.rs
>>> > >>
>>> > >>
>>> > >>
>>> > >> On Mon, 7 Mar 2022, Dusan Cvijetic wrote:
>>> > >>
>>> > >>> Pozdrav,
>>> > >>>
>>> > >>> S obzirom da sam radio ispis u .xml fajl, preuzeću i
>>> učitavanje
>>> > >>> kompleksa iz fajla.
>>> > >>>
>>> > >>> Pozdravi,
>>> > >>> Dušan
>>> > >>>
>>> > >>> пет, 11. феб 2022. у 23:17 Marko Vojinovic
>>> <vmarko at ipb.ac.rs> је
>>> > >>> написао/ла:
>>> > >>>
>>> > >>> Implementirati metod u klasi SimpComp koji ce da
>>> procita dati
>>> > >>> fajl i instancira u memoriji simplicijalni kompleks na
>>> osnovu
>>> > >>> podataka iz fajla:
>>> > >>>
>>> > >>> SimpComp* SimpComp::read_complex_from_file(
>>> file* f );
>>> > >>>
>>> > >>> Input: Pointer na fajl iz koga se citaju
>>> podaci.
>>> > >>> Output: pointer na instancirani simplicijalni
>>> kompleks
>>> > >>> kreiran na osnovu podataka iz fajla.
>>> > >>>
>>> > >>> Ovaj zadatak treba da instancira nov prazan
>>> kompleks, zatim da
>>> > >>> cita dati fajl, interpretira sintaksu iz zadatka 7, i da
>>> na osnovu
>>> > >>> tih podataka popuni kompleks odgovarajucim
>>> > >>> simpleksima datih nivoa, a zatim i boje i susede
>>> svakog
>>> > >>> simpleksa ponaosob. Ovo je u sustini inverzni algoritam
>>> u odnosu na
>>> > >>> zadatak 7, i zavisi od tacne implementacije tog
>>> > >>> zadatka (tj. od tacne sintakse snimljenog fajla),
>>> pa ovaj
>>> > >>> zadatak treba raditi tek kada budemo sigurni da smo
>>> skroz zadovoljni
>>> > >>> sa radom f-ja za snimanje u fajl.
>>> > >>>
>>> > >>> I u ovom slucaju cemo mozda uraditi vise verzija
>>> f-je za
>>> > >>> citanje, po jednu za svaki format fajla.
>>> > >>>
>>> > >>>
>>> > >>> :-)
>>> > >>> Marko
>>> > >>>
>>> > >>>
>>> > >>> Dr. Marko Vojinovic
>>> > >>> Group for Gravitation, Particles and Fields
>>> > >>> Institute of Physics
>>> > >>> University of Belgrade
>>> > >>> ======================
>>> > >>> home page: www.markovojinovic.com
>>> > >>> e-mail: vmarko at ipb.ac.rs
>>> > >>>
>>> > >>>
>>> > >>> --
>>> > >>> QGHG-it-dev-list mailing list
>>> > >>> QGHG-it-dev-list at ipb.ac.rs
>>> > >>> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>
>>> > --
>>> > QGHG-it-dev-list mailing list
>>> > QGHG-it-dev-list at ipb.ac.rs
>>> > http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>>> >
>>> >
>>> >--
>>> QGHG-it-dev-list mailing list
>>> QGHG-it-dev-list at ipb.ac.rs
>>> http://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
>>>
>>>
>>>
>>>
>
More information about the QGHG-it-dev-list
mailing list