[QGHG-it-dev-list] Zadatak 7 - snimanje kompleksa u fajl
Dusan Cvijetic
dusancvijetic2000 at gmail.com
Wed Mar 9 14:05:04 CET 2022
Pozdrav,
Izvadio sam funkcije iz klase SimpComp jer mi tada još nije bilo jasno kako
su nam fajlovi povezani, verujem da bi sve funkcionisalo i da to nisam
uradio. Mogu da vratim, ako Vam je lepše.
Uneo sam ispravke u kod, više ne bi trebalo da baca upozorenja.
Pretpostavljam da je pravio problem jer sam string implicitno konvertovao u
char*, a ne char*[].
Da napomenem samo, VS i dalje baca nekoliko warninga, od kojih me najviše
brine:
Severity Code Description Project File Line Suppression State
Warning C6262 Function uses '66100' bytes of stack: exceeds
/analyze:stacksize '16384'. Consider moving some data to heap.
triangulator C:\Users\Duca\OneDrive - student.etf.bg.ac.rs\PRAKSA
VOJINOVIC\triangulator\input-and-output.cpp 15.
Nisam imao vremena da mu se posvetim, ali istražiću još šta znači.
Pretpostavljam da je zbog one čudne alokacije memorije.
Pozdravi,
Dušan
пон, 7. мар 2022. у 05:37 Marko Vojinovic <vmarko at ipb.ac.rs> је написао/ла:
>
> Pozdrav Dusane,
>
> (1-9) Odlicno, super! Sad deluje sve ok. :-)
>
> > (2) Prebacio funkcije. Pošto nisu više funkcije članice klase, već su u
> zasebnom folderu,
>
> Hmmm... Nisam siguran da li si morao da vadis f-je iz klase SimpComp ---
> valjda nije vazno u kom fajlu se nalaze implementacije f-ja, dokle god se
> nalaze negde? A mozda i jeste vazno, ako se fajlovi kompajliraju nezavisno
> jedan od drugog... No nema veze, ovako kako je sada je isto sasvim ok, neka
> ostane. :-) Kad formulisem zadatke, ponekad imam tu dilemu sa dizajnom ---
> da li datu f-ju da stavim kao clanicu neke klase ili da je definisem
> zasebno, jer je za veliki broj f-ja prilicno svejedno. Tako da je ovo skroz
> ok.
>
> > (6) i (7) Dodao sam i ovaj ispis, s tim što sada ime kompleksa
> ispisujemo redudantno
>
> Nema problema, neka ga. Necemo da ustedimo nista znacajno na tom jednom
> stringu. ;-) Vazno je da je .xml fajl human-readable i pregledan.
>
> > (9) Dodao sam forward deklaracije u fajl "rapidxml-patch.hpp" za sve
> funkcije koje su bacale grešku, proverite je li sad u redu.
>
> U redu je, kompajliranje sa g++ sada radi bez onih gresaka.
>
> Ali sad su se pojavila tri nova warning-a (koji nemaju veze sa
> patch-om...), log je u attachment-u. Nije mi do kraja jasno da li ti je
> bitna razlika izmedju "char*" i "string", i u principu kompajler to hoce da
> proguta pa nije previse vazno, ali baci pogled da li mozda moze i to da se
> ispegla. Kad nam se kod vec do sada kompajlirao bez ijedne greske i ijednog
> warning-a, cisto da ga cuvamo tako dokle god mozemo... ;-)
>
> > Izvinjavam se zbog tri push-a
>
> Ma opusteno... :-)
>
> :-)
> 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,
> >
> > (1) Urađeno.
> >
> > (2) Prebacio funkcije. Pošto nisu više funkcije članice klase, već su u
> zasebnom folderu, sada sam im kao argument dodao pokazivač na simpcomp koji
> se štampa, pa su novi potpisi
> > void save_complex_to_xml_file(SimpComp* simpComp, const
> string& filename);
> > vector<rapidxml::xml_node<>*>
> get_element_levels_as_xml_nodes(SimpComp* simpComp,
> rapidxml::memory_pool<>& mp);
> >
> > (3) i (4) Uklonio duplikate.
> >
> > (5) Urađeno.
> >
> > (6) i (7) Dodao sam i ovaj ispis, s tim što sada ime kompleksa
> ispisujemo redudantno - jednom kao ime root XML node, i drugi put kao
> vrednost XML node "name".
> >
> > (8) Ovo je bila greška, slučajno sam ostavio obe funkcije. Razmatrao sam
> koje je ime bolje za f-ju koja čita vrednost boje iz stringa, i prvo sam
> stavio verziju sa "as" (zbog copy-paste
> > iz get funkcije), ali je bolja verzija "from", koju sam sad ostavio kao
> jedinu. Funkcija treba da čita vrednost boje iz stringa koji joj je
> prosleđen.
> >
> > (9) Dodao sam forward deklaracije u fajl "rapidxml-patch.hpp" za sve
> funkcije koje su bacale grešku, proverite je li sad u redu.
> >
> > Dodatno, ispravio sam imena promenljivih da bi pratila konvenciju koju
> ste naveli u mejlu iz diskusije za zadatak 2.
> >
> > Ok, konkretnosti radi, 'ajde da fiksiramo konvencije ovako: imena
> funkcija su under_scored, imena klasa su CamelCase, imena promenljivih su
> camelCase, a imena konstanti su
> > UNDER_SCORED_CAPS. Bice zabavno. ;-) Inace, sto se tice generalnih
> konvencija kucanja koda, ponekad se trazi i word-wrap na 79-toj koloni, ali
> mene to strasno nervira na
> > velikom monitoru pa se ja prvi necu pridrzavati toga, niti cu vas
> da teram. ;-)
> >
> >
> > Izvinjavam se zbog tri push-a, primećivao sam da mi fale detalji dok sam
> pisao mejl. Biću pažljiviji ubuduće.
> >
> > Pozdravi,
> > Dušan
> >
> > суб, 5. мар 2022. у 01:27 Marko Vojinovic <vmarko at ipb.ac.rs> је
> написао/ла:
> >
> > Pozdrav Dusane,
> >
> > Svidja mi se kako si ovo uradio, odlican posao! Vidim da f-ja radi
> ono sto treba (do na neke detalje, vidi nize), a pitanje optimizacije nam
> uopste nije relevantno ---
> > snimanje u fajl je nesto sto se radi retko i kao one time effort,
> pa brzina izvrsavanja uopste nije vazna. :-) Radije bih da imamo jasan i
> razumljiv kod, kako je sada
> > napisan, nego da bude "optimizovan" i kriptican.
> >
> > Sto se tice memory leak-ova, to treba da pregledamo i vidimo da li
> rapidxml negde nesto leak-uje --- eventualno procitaj u uputstvu detalje
> kako se tamo alocira memorija.
> > Mozda je to sve ipak ok, nego se samo VS IntelliSense "prevari"
> jer je metod za alociranje u rapidxml-u "nestandardan"... Mozda bi mogli i
> Nenad i Jaroslav da pogledaju to,
> > cisto da budemo sigurni da je sve ok.
> >
> > E sad, evo i spiska stvari koje bi trebalo jos da doteras u kodu:
> >
> > (1) Direktorijum "rapidxml/" stavi unutar novog direktorijuma
> "third-party-software/". Verovatno cemo vremenom dodavati jos drugih tudjih
> paketa, pa da svi oni budu u tom
> > jednom direktorijumu, da bude jasno sta se gde nalazi.
> >
> > (2) F-je
> >
> > SimpComp::save_complex_to_xml_file()
> > SimpComp::get_element_levels_as_xml_nodes()
> >
> > stavi u input-and-output.cpp, i odgovarajuce deklaracije u
> input-and-output.hpp, tamo im je prirodnije mesto. Ostale f-je su ok tu gde
> su.
> >
> > (3) U color.hpp, red 54, imas duplo ;;
> >
> > string get_color_value_as_str() const;;
> >
> > (4) U triangulator.hpp, red 13, imas duplo // u putanji:
> >
> > #include "rapidxml//rapidxml_print.hpp"
> >
> > (5) Na kraju algoritma, kad obrises privremene UniqueID boje,
> treba da resetujes next_free_uid_number na (staru) zapamcenu vrednost
> current_maxid:
> >
> > UniqueIDColor::next_free_uid_number = current_maxid;
> >
> > (6) Za ceo SimpComp, osim tabele elemenata, algoritam treba da
> zabelezi u fajl i njegovo ime i dimenziju:
> >
> > string name;
> > int D;
> >
> > (7) Za svaki simpleks iz klase KSimplex, osim boja i suseda,
> algoritam treba da zabelezi u fajl i njegov nivo i dimenziju:
> >
> > int k;
> > int D;
> >
> > (8) Nije mi jasno u cemu je razlika u nameni izmedju f-ja
> >
> > Color::set_color_value_from_str()
> > Color::set_color_value_as_str()
> >
> > Vidim da su one samo placeholder-i u klasi Color, ali zasto ima
> dve, i cemu tacno treba da sluze?
> >
> > (9) Prilikom kompajliranja pomocu g++ mora da se doda flag
> -fpermissive da bi kod hteo da se kompajlira --- to mi se ne svidja, i to
> treba da popravimo. U prilogu ti saljem
> > error.log koji ispisuje g++ bez -fpermissive opcije (sa tom
> opcijom ispisuje sve to isto samo error-ove tretira kao warning-e). Kako
> izgleda, gomila f-ja iz
> > rapidxml_print.hpp se koristi pre nego sto je deklarisana, pa je
> verovatno dovoljno da negde dodas odgovarajuce forward-deklaracije za sve
> njih. Pritom bih voleo da tudji
> > kod ne diramo, nego da forward-deklaracije dodas u neki nas
> lokalni fajl (recimo "rapidxml-patch.hpp"), koji cemo da include-ujemo u
> triangulator.hpp neposredno ispred
> > rapidxml_print.hpp, i time eliminisemo problem sa kompajliranjem.
> >
> >
> > To je otprilike to. Hvala puno za ovo, ova f-ja je vazan doprinos,
> i mislim da si je veoma lepo uradio. Posto si se vec uvezbao sa
> rapidxml-om, ako ti nije tesko, uradi i
> > inverznu f-ju (zadatak 8) --- kad budes imao vremena naravno, nije
> frka. ;-)
> >
> > :-)
> > 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 Fri, 4 Mar 2022, Dusan Cvijetic wrote:
> >
> > > Pozdrav,
> > >
> > > Ovo je bilo teže nego što sam se nadao.
> > >
> > > Dodao sam funkciju string get_color_value_as_str() i
> implementirao je za već postojeće boje. Dodaću i inverznu funkciju
> (verovatno tek tokom sledeće nedelje).
> > >
> > > Implementirao sam i pisanje kompleksa u .xml fajl. Za to sam
> koristio biblioteku RapidXML, jer je obećavala najbrže izvršavanje.
> Međutim, ova biblioteka koristi neka čudna
> > alociranja
> > > memorije sa kojima se ranije nisam susreo, pa se bojim da negde
> ne dođe do curenja. Štaviše, VS IntelliSense mi izbacuje upozorenja
> (dostavljam ih ispod teksta poruke)
> > koja ne razumem,
> > > a tiču se memorije. Najbolje bi bilo da ovo pregleda neko sa
> malo više iskustva i znjanja, jer mi miriše na problem.
> > >
> > > Testirao sam kod na trouglu i tetraedru koji su pravljeni u
> glavnoj funkciji, i na ovim primerima radi. Nije ni blizu optimalan, ali
> vratiću se ponovo ovom problemu
> > kasnije. Hteo sam da
> > > okačim i ovu verziju da biste mogli da pratite napredovanje, i
> na vreme iskritikujete sve što ne valja.
> > >
> > > Pozdravi,
> > > Dušan
> > >
> > >
> > > Severity Code Description Project File Line Suppression State
> > > Warning C26495 Variable 'KSimplex::D' is uninitialized. Always
> initialize a member variable (type.6). triangulator C:\Users\Duca\OneDrive
> - student.etf.bg.ac.rs\PRAKSA
> > > VOJINOVIC\triangulator\classes.cpp 7
> > > Warning C6262 Function uses '65996' bytes of stack: exceeds
> /analyze:stacksize '16384'. Consider moving some data to heap.
> triangulator C:\Users\Duca\OneDrive -
> > > student.etf.bg.ac.rs\PRAKSA VOJINOVIC\triangulator\classes.cpp
> 288
> > >
> > > чет, 3. мар 2022. у 02:40 Marko Vojinovic <vmarko at ipb.ac.rs> је
> написао/ла:
> > >
> > > Sto se mene tice slazem se, takva f-ja zvuci pametno.
> Takodje, to bi omogucilo korisnicima da sami zadaju takve f-je za svoje
> custom boje koje budu kreirali. Npr,
> > ako neko
> > > hoce da napravi klasu boja 3x3 kompleksnih matrica, moci
> ce da implementira i takvu f-ju za svoju klasu, koja ce na odgovarajuci
> nacin da pretvori te podatke u
> > stringove
> > > koji mogu da se zapisu u fajl.
> > >
> > > Sto se tice dosadasnjih print f-ja, njih je napisao Nenad
> --- moj utisak je da je koristio static cast samo zato sto je to dovoljno
> za te elementarne print f-je. Ali
> > ako ima
> > > neki ozbiljniji razlog zasto bi static cast bio bolji od
> ove f-je koju ti predlazes, javice nam. :-)
> > >
> > > U medjuvremenu, slobodno implementiraj
> get_color_value_as_str() i koristi je za pisanje u fajl. Razmisli
> eventualno i o "inverznoj" f-ji koju bismo koristili za
> > citanje
> > > stringa iz fajla i prevodjenje u native vrednost za datu
> boju.
> > >
> > > :-)
> > > 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, 3 Mar 2022, Dusan Cvijetic wrote:
> > >
> > > > Pozdrav,
> > > >
> > > > Stigao sam do ispisa redosledno boja za svaki
> k-simpleks, i video sam da je za ispis (u print funkcijama) ranije korišćen
> static cast. Imam predlog da ovo
> > elegantnije
> > > rešimo tako što
> > > > ćemo dodati virtuelnu funkciju string
> get_color_value_as_str()koja bi vraćala odgovarajući zapis vrednosti boje
> kao string, a omogućila bi nam da, kada god želimo
> > da
> > > dobijemo vrednost
> > > > određene boje za štampanje, samo polimorfno pozovemo tu
> funkciju. Ovo drastično pojednostavljuje sva štampanja, i mnogo lakše se
> skalira za veliki broj boja.
> > > >
> > > > Kako zvuči ova ideja?
> > > >
> > > > Pozdravi,
> > > > Dušan
> > > >
> > > > сре, 2. мар 2022. у 17:28 Marko Vojinovic <
> vmarko at ipb.ac.rs> је написао/ла:
> > > >
> > > > Pozdrav Dusane,
> > > >
> > > > Generalna ideja je da ne izmisljamo toplu vodu ---
> ako postoji gotov softver za neku funkcionalnost, svakako to treba da
> koristimo, ako je moguce i ako nam
> > je
> > > zgodno.
> > > >
> > > > U ovom konkretnom slucaju ti treba da procenis da
> li ti je lakse da koristis postojece parsere ili ti je lakse da napises
> svoj. Obicno je bolja ideja da
> > koristis
> > > postojeci.
> > > > MIT licenca je verovatno ok, to ne bi trebalo da
> bude problem.
> > > >
> > > > Pritom, za sve "tudje" fajlove, koji nisu nas kod,
> napravi zasebnu strukturu pod-direktorijuma u kojoj cemo da ih drzimo, da
> se ne mesaju sa nasim kodom.
> > Znaci npr.
> > > ovako:
> > > >
> > > > mkdir ~/third-party-software/RapidXml/
> > > > mkdir ~/third-party-software/jsoncpp/
> > > >
> > > > pa onda u te direktorijume stavljaj njihov source
> i/ili include fajlove ili stagod, sve sto ti je potrebno za rad naseg
> softvera. Include-uj odnosno link-uj
> > sve
> > > takve
> > > > fajlove sa tom relativnom putanjom itd. Ovo je
> vazno da se odvoji jer se od nas zahteva da merimo "napredovanje u razvoju"
> naseg softvera ukupnim brojem
> > linija koda,
> > > u koji
> > > > normalno ne treba da racunamo tudj kod. ;-)
> > > >
> > > > :-)
> > > > 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 Wed, 2 Mar 2022, Dusan Cvijetic wrote:
> > > >
> > > > > Pozdrav,
> > > > >
> > > > > Da li treba da pišem parser od nule, ili mogu da
> koristim neku gotovu biblioteku? Video sam da za .xml fajlove postoji,
> recimo, RapidXml, a za .json
> > fajlove
> > > jsoncpp. Oba
> > > > imaju MIT
> > > > > licencu, koja nam, koliko sam razumeo,
> dozvoljava da sa njima radimo šta želimo, dok god uz izvorni kod uključimo
> i fajl sa samom licencom.
> > > > >
> > > > > Ako biste radije da pišem parser od nule, onda
> bismo možda mogli da ga realizujemo kao zasebnu klasu (sa decom-klasama za
> svaku vrstu fajla), pa da
> > SimpComp sadrži
> > > kao
> > > > svoje polje jedan
> > > > > pokazivač na njen objekat, i funkcije za
> pisanje/čitanje koje polimorfno pozivaju odgovarajući parser, u zavisnosti
> od vrste fajla koji koristimo.
> > > > >
> > > > > Pozdravi,
> > > > > Dušan
> > > > >
> > > > > пон, 28. феб 2022. у 15:36 Marko Vojinovic <
> vmarko at ipb.ac.rs> је написао/ла:
> > > > >
> > > > > Svakako, samo napred --- jedino uzmi u
> obzir da sam ja pisao onu .xml notaciju napamet, nisam siguran kako tacno
> treba da glasi. Pogledaj negde na
> > netu kakva
> > > je
> > > > pravilna
> > > > > sintaksa i specifikacija za .xml, nemoj da
> se oslanjas mnogo doslovno na moje primere u formulaciji zadatka.
> > > > >
> > > > > :-)
> > > > > 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 Sun, 27 Feb 2022, Dusan Cvijetic wrote:
> > > > >
> > > > > > Pozdrav,
> > > > > >
> > > > > > Uzeo bih ovaj zadatak da radim, ako je
> to u redu.
> > > > > >
> > > > > > Pozdravi,
> > > > > > Dušan
> > > > > >
> > > > > > пет, 11. феб 2022. у 23:14 Marko
> Vojinovic <vmarko at ipb.ac.rs> је написао/ла:
> > > > > >
> > > > > > Implementirati metod u klasi
> SimpComp koji ce da snimi dati simplicijalni kompleks u fajl:
> > > > > >
> > > > > > file*
> SimpComp::save_complex_to_file( string filename );
> > > > > >
> > > > > > Input: ime fajla u koji ce se
> snimiti kompleks.
> > > > > > Output: pointer na fajl u koji
> je snimljen kompleks.
> > > > > >
> > > > > > Prvi korak u implementaciji ovoga
> je odabir tipa fajla koji ce da sadrzi podatke, i njegove strukture. Fajl
> mora da bude istovremeno i
> > > machine-readable i
> > > > > human-readable, i
> > > > > > dva moguca predloga su .xml i
> .json tipovi, mada slobodno predlozite i neki treci ako mislite da je bolji
> od ova dva. Algoritam za snimanje
> > bi
> > > trebalo da ide
> > > > ovako:
> > > > > >
> > > > > > (1) Zapamtiti trenutnu vrednost
> globalne varijable next_free_uid_number iz klase UniqueIDColor (na primer,
> neka ta vrednost bude 12).
> > Kompleks mozda
> > > vec
> > > > sadrzi neke
> > > > > boje iz
> > > > > > ove klase, i sve instance za koje
> je id manji od ove zapamcene trenutne vrednosti treba preskakati i
> ignorisati u nastavku algoritma, tj.
> > tretirati
> > > ih kao i
> > > > boje
> > > > > svih
> > > > > > ostalih tipova.
> > > > > >
> > > > > > (2) Obojiti ceo kompleks bojom
> UniqueID (pozvati f-ju UniqueIDColor::colorize_entire_complex() iz zadatka
> 2). Ove nove id-ove cemo da
> > koristimo za
> > > imenovanje
> > > > > pojedinacnih
> > > > > > simpleksa u fajlu.
> > > > > >
> > > > > > (3) Zapisati u fajl strukturu
> vektora elements naseg kompleksa --- deklarisati level 0 i u njemu
> pobrojati nove id boje svih 0-simpleksa,
> > zatim
> > > deklarisati
> > > > level 1 i
> > > > > > pobrojati sve 1-simplekse, itd
> zakljucno sa nivoom D. U .xml formatu bi to moglo da izgleda npr ovako (ne
> znam tacno kako ide .xml sintaksa,
> > pisem po
> > > > secanju):
> > > > > >
> > > > > > <level
> 0>12,13,14,15,16,17,18</level 0> // id brojevi nivoa 0 u kompleksu
> > > > > > <level 1>19,20,21,22</level1>
> // id brojevi nivua 1 u kompleksu
> > > > > > ...
> // nastavljamo ovako zakljucno sa nivoom D
> > > > > >
> > > > > > Obratite paznju da su svi id
> brojevi >= 12.
> > > > > >
> > > > > > (4) Zapisati u fajl strukturu
> svakog k-simpleksa --- deklarisati simpleks njegovim id brojem, i zatim
> ispisati sve tipove i vrednosti boja,
> > kao i id
> > > brojeve
> > > > svih
> > > > > njegovih
> > > > > > suseda, poredjanih kao u koraku
> (3). Na primer, .xml sintaksa bi izgledala recimo ovako:
> > > > > >
> > > > > > <ksimplex 12>
> > > > > > <color-type>0</color-type>
> // ova nula je TYPE_BOUNDARY
> > > > > > <color-value>true</color-value>
> // ovo je vrednost boundary boje
> > > > > > <color-type>129</color-type>
> // ovo je TYPE_UNIQUE_ID
> > > > > > <color-value>11</color-value>
> // ovo je id vrednost UniqueID boje, koja je *manja* od 12
> > > > > > ...
> // pisemo type-value kombinacije za sve boje, *osim* za (poslednju)
> UniqueID boju koja je veca od 12
> > > > > > <level 0></level0>
> // ovaj simpleks npr nema susede nivoa nula
> > > > > > <level 1>19,22,41,356</level1>
> // id boje suseda nivoa 1 (svi su *veci* od 12...)
> > > > > > ...
> // pisemo strukturu za svih D nivoa suseda
> > > > > > </ksimplex 12>
> > > > > > <ksimplex 13>
> // ponavljamo gornju strukturu za naredni k-simpleks
> > > > > > ...
> > > > > > </ksimplex 13>
> > > > > > ...
> // dok ne uradimo sve k-simplekse u kompleksu.
> > > > > >
> > > > > > Kad se ovo zavrsi, fajl je
> snimljen, zatvoriti ga. Ukoliko postoje neke vec gotove biblioteke C++
> rutina koje konstruisu .xml i .json
> > sintaksu na
> > > osnovu
> > > > nekih
> > > > > ulaznih
> > > > > > podataka, verovatno je dobra ideja
> da ih iskoristimo, umesto da sami pisemo svaki simbol tih fajlova
> (smanjicemo mogucnost sintaksnih gresaka
> > i
> > > povecacemo
> > > > > kompatibilnost).
> > > > > >
> > > > > > (5) Deinstancirati sve UniqueID
> boje iz kompleksa koje smo dodali u koraku (2), uz paznju da ne diramo
> eventualne UniqueID boje koje su vec
> > postojale
> > > (koje
> > > > imaju id
> > > > > vrednost
> > > > > > < 12 iz primera), cime vracamo
> kompleks u njegovo pocetno stanje. Takodje, setovati globalnu varijablu
> next_free_uid_number natrag na
> > vrednost 12,
> > > zapamcenu
> > > > u koraku
> > > > > (1).
> > > > > >
> > > > > > Takodje, mozda bi imalo smisla
> napraviti dve f-je za snimanje fajla (umesto one jedne deklarisane gore),
> > > > > >
> > > > > >
> SimpComp::save_complex_to_xml_file()
> > > > > >
> SimpComp::save_complex_to_json_file()
> > > > > >
> > > > > > koje bi implementirale sve ovo
> odozgo, ali sa sintaksom odgovarajucom za dati format. Ubuduce cemo mozda
> da smislimo i neki treci format za
> > snimanje,
> > > na
> > > > primer .tex
> > > > > (za
> > > > > > crtanje TikZ paketom u LaTeX-u),
> ili .nb (za Mathematicu), ili sl.
> > > > > >
> > > > > >
> > > > > > :-)
> > > > > > 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
> > > >
> > > >
> > > >--
> > > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20220309/04628a9d/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list