[QGHG-it-dev-list] Zadatak 2 - bojenje kompleksa

Nenad Korolija nenadko at gmail.com
Thu Feb 24 23:36:26 CET 2022


Modifikovao, ali ti je jasno da nemam pojma zasto ti to treba. :)
U skladu sa mojim nagadjanjima, napravio sam funkcije koje bi mogle da nam
olaksaju zivot tipa:
- nadji prvu uniqueID boju i
- nadji sve vertekse.

Mozes da pogledas sve izmene i testiras kopiranjem poslednjih linija main-a
i jednostavnim komentarisanjem i menjanjem broja u zagradi:
    UniqueIDColor::colorize_simplices_at_level(tetrahedron, 0);
    UniqueIDColor::colorize_entire_complex(tetrahedron);

Nadam se da sa > D nisam omanuo uslov:
bool SimpComp::all_uniqueID(int level){
    size_t i = 0;
    if(level > D)
        return false;

Pozdrav,
Nenad

On Wed, Feb 23, 2022 at 5:54 AM Marko Vojinovic <vmarko at ipb.ac.rs> wrote:

>
> Da, ovakvo ispisivanje sa & u compact_print nije zgodno. Uradi ovako ---
> za svaki simpleks, pronadji prvu instancu UniqueID boje i ispisi uvek samo
> nju, a ostale instance ignorisi (ako postoje). To je najjednostavnija
> varijanta, i dovoljna je za nase potrebe.
>
> Takodje, ako vec sredjujes print_compact, mozes da namestis i sledecu
> logiku ispisivanja (smislio sam pre neki dan precizna pravila):
>
>     * Prvo proveri da li su verteksi (k=0) obojeni svi (v=all), ili ima
> nekih koji nisu obojeni (v=notall).
>     * Zatim proveri da li su ostali simpleksi (k>0) obojeni svi (s=all),
> ili ima nekih koji nisu obojeni (s=notall).
>
> Kad to saznas, onda ih ispisuj ovako:
>
>     * Ako je v=all i s=all --- ispisi standardno prvo boje svih verteksa:
> 1, 2, 3,..., pa zatim za ostale simplekse njihove boje i u zagradama boje
> njihovih verteksa. Sve sortiraj. Primer: 14 (2-4-8), 15 (3-5-9), ...
>     * Ako je v=all i s=notall --- ispisi boje svih verteksa: 1, 2, 3,...,
> pa zatim za ostale simplekse samo boje njihovih verteksa u zagradama,
> sortirane: (2-4-8), (3-5-9), ...
>     * Ako je v=notall i (s=all ili s=notall) --- i za vertekse i za ostale
> simplekse samo napisi boju ako je ima, odnosno rec "Simplex" ako je nema,
> bez zagrada i bez sortiranja: 8, 4, Simplex, 15, ...
>
> Ova pravila pokrivaju sve slucajeve. Naravno, u svemu ovome gore
> razvrstavas ispisivanje po nivoima, za svako k jedan zaseban red, kao i
> dosad sto je bilo.
>
> U main.cpp testiraj prvi slucaj tako sto obojis ceo tetraedar, drugi
> slucaj tako sto obojis k=0 level za tetraedar, a treci tako sto obojis
> recimo k=2 level za tetraedar, Dusanovim f-jama. Naravno, instanciraj tri
> nezavisna tetraedra za ovo, da mozes sve odjednom da testiras.
>
> Btw, smisao ovih pravila: prva dva slucaja (v=all) su regularna i
> verovatno ce se cesto pojavljivati u praksi, dok treci slucaj (v=notall)
> nije regularan i signalizira da je korisnik nesto negde zabrljao sa bojama
> (ispisivanjem reci "Simplex" bar na nekom mestu). ;-)
>
> :-)
> 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, 23 Feb 2022, Nenad Korolija wrote:
>
> > Marko, planirao sam sortiranje UniqueID boja i ispisivanje redom. To se
> kosi sa potrebama. Kakvo ispisivanje zelis u slucaju ivice sa 4&7 izmedju
> verteksa sa 8&9 i 10&11,
> > 4&7 (8&9-10&11)?
> >
> > On Tue, Feb 22, 2022 at 11:23 PM Nenad Korolija <nenadko at gmail.com>
> wrote:
> >       Sa svim se slazem...
> > Marko, druge funkcije color.cpp su ispale 0-3 linije koda, ali bih rado
> ubio colorize_simplices_at_level, ako sama po sebi nema svrhu, iako
> Dušanove imaju po 4 linije. :)
> > Vidim da si ti kreirao naziv funkcija koje sam komentarisao. Ako stari
> nazivi imaju neku interpretaciju koju ne vidimo, javi da vratimo.
> >
> > On Tue, Feb 22, 2022 at 9:52 PM Dusan Cvijetic <
> dusancvijetic2000 at gmail.com> wrote:
> >       Da, nisam u prošlom mejlu napisao, kada je dozvoljeno da simpleks
> ima više UniqueIDColor objekata, štampanje pobrljavi. Boje simpleksa se
> štampaju spojeno, a pošto pri
> >       štampanju samo prolazi kroz skup svih UniqueIDColor-a, ukoliko,
> recimo, želimo da štampamo ivicu, kada tačke imaju po dva UniqueIDColor
> objekta, ištampaće ivice kao da
> >       imaju četiri suseda. Recimo, ukoliko verteksi v1 i v2 imaju
> UniqueIDColor boje 1, 5 i 2, 6, redom (tako je trenutno u main.cpp fajlu),
> ivicu 9 koja je između njih
> >       štampa kao Simplices k = 1: 9 (1-2-5-6), pri čemu vertekse štampa
> kao 15 i 26. Nisam siguran je li nameravano da se funkcija za štampanje
> ovako ponaša, pa samo da
> >       napomenem.
> >
> > уто, 22. феб 2022. у 21:45 Dusan Cvijetic <dusancvijetic2000 at gmail.com>
> је написао/ла:
> >       Pozdrav,
> >
> >       nemoj da proveravas da li simpleks vec ima UniqueID boju
> >
> > Prepravio i pushovao, proverite je li sad u redu.
> >
> >       samo bi mozda imalo smisla staviti forward deklaracije u color.hpp
> a ne direktno u triangulator.hpp.
> >
> > Premešteno.
> >
> >       Nase klase su samo malo komplikovaniji slucaj istog tog koncepta
> --- unakrsno referenciraju jedna drugu u svojim definicijama.
> >
> > Imao sam, pre oko godinu dana, problem s ovim u svom kodu i nisam znao
> kako da ga rešim, pa sam reorganizovao klase. Sad mi je interesantan ovaj
> način rešavanja
> > unakrsne rekurzije, ne bi mi palo na pamet jer smo na fakultetu učili
> jedan šablon, koji je predstavljen kao Sveto Pismo, pa nisam nikad od njega
> divergirao.
> >
> >       Ok, konkretnosti radi, 'ajde da fiksiramo konvencije ovako:
> >
> > Trebalo bi da moj deo koda sad prati ove konvencije, ostalo nisam hteo
> da diram, ali mogu kroz sve da prođem, ako želite.
> >
> >       neka zasad f-je uvek vracaju samo true
> >
> > Prepravljeno.
> >
> > Pozdravi,
> > Dušan
> >
> >
> >
> > уто, 22. феб 2022. у 17:54 Marko Vojinovic <vmarko at ipb.ac.rs> је
> написао/ла:
> >
> >       Evo da vam odgovorim obojici odjednom... :-)
> >
> >       Dusane, odlicno si ovo uradio, svidja mi se, samo cu da te zamolim
> za jednu sustinsku izmenu --- nemoj da proveravas da li simpleks vec ima
> UniqueID boju.
> >       Obe f-je treba prosto da dodaju
> >       *nove* boje, cak i ako su simpleksi vec bili obojeni sa UniqueID.
> Ne zelimo da dopunjavamo kompleks bojama, nego da ga obojimo "jos jednom",
> da se tako
> >       izrazim. Inace, ne postoji nikakav problem da isti simpleks nosi
> dve UniqueID boje (obrnuto naravno ne sme), u zadatku 7 se cak oslanjamo na
> to.
> >
> >       Sto se tice konkretnih pitanja, ovako:
> >
> >       > Tek kada sam izvršio commit sam se setio da poruke treba da
> pišem na engleskom
> >
> >       Nije problem, samo pazi na to ubuduce --- neko ko ne zna srpski ce
> mozda pozeleti da gleda GitHub, zato je sve na engleskom. Btw, budite
> srecni sto vas ne
> >       teram da i komunikacija na mailing listi bude na engleskom. :-D
> >
> >       > Color traži da budu već deklarisani SimpComp i KSimplex, a
> KSimplex traži da već bude deklarisan Color, a SimpComp traži KSimplex:
> Color > SimpComp >
> >       KSimplex > Color. Naterao sam
> >       > ga da radi dodavši forward deklaracije za KSimplex i SimpComp u
> triangulator.hpp, ali ne mislim da je to dobro rešenje.
> >
> >       Naprotiv, forward deklaracije su upravo ono sto nam treba. :-) Te
> tri klase su ukrstene by design --- jer to tacno odgovara matematickim
> strukturama sa
> >       kojima radimo. U tom kontekstu, bilo kakvo uvodjenje nekih
> dodatnih klasa da se to "popravi" bi bilo skroz vestacko i nepotrebno.
> Znaci dobro si uradio,
> >       samo bi mozda imalo smisla staviti forward deklaracije u color.hpp
> a ne direktno u triangulator.hpp.
> >
> >       > Trenutno mi deluje neprijatno da polje klase namešta samo sebe
> >
> >       Sigurno si vec naviknut na koncept dinamicke liste --- nju kreiras
> strukturom koja u svojoj definiciji referencira samu sebe. Nase klase su
> samo malo
> >       komplikovaniji slucaj istog tog koncepta --- unakrsno
> referenciraju jedna drugu u svojim definicijama. Unakrsnu rekurziju [1] si
> sigurno video u
> >       algoritmima (npr. rekurzivni spust), jedino mozda nisi navikao da
> pravis klase na istu foru. ;-)
> >
> >       > Koristio sam konvenciju sa donjom crtom umesto camelCase-a jer
> je tako stajalo u potpisu funkcija, meni je takođe svejedno kako ćemo
> pisati.
> >
> >       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. ;-)
> >
> >       > nije naznačeno šta označava bool vrednost koju funkcija vraća,
> pa sam namestio da vraća true ukoliko je bar jedan simpleks obojen njenim
> pozivom.
> >       > Ne vidim koje bi se greške mogle javiti pri bojenju
> >
> >       Ovo sam ja zaboravio da preciziram u zadatku --- f-je treba da
> vrate false samo ukoliko ne uspeju da urade svoj posao. Jedine situacije u
> kojima je ovo
> >       zamislivo su out-of-memory problemi, npr. ako "new
> UniqueIDColor()" odbije da adresira memoriju, ili sl. Ali posto o takvim
> stvarima za sada generalno ne
> >       brinemo nigde u kodu, necemo ni ovde --- neka zasad f-je uvek
> vracaju samo true, pa cemo to da promenimo kad (ako) budemo radili code
> hardening.
> >
> >       > Druga stvar koja mi je zapala za oko je colorize_all_simplices,
> da bih vec iz argumenata video da nisu all. Mozda
> colorize_simplices_at_level?
> >
> >       Jeste, ovo je prirodnije ime, vidim da ga je Dusan vec popravio.
> >
> >       > Sledece bi u sustini trebalo da ne bude u classes.hpp (mada nama
> tako za sad odgovara zbog grupisanja funkcionalnosti), vec da se podeli u
> dva fajla:
> >
> >       Jeste, podelite classes.hpp na simpcomp.hpp i ksimplex.hpp (i
> odgovarajuce .cpp-ove). I naravno dodajte unutra forward-deklaracije klasa
> koje vam trebaju.
> >
> >       :-)
> >       Marko
> >
> >       [1] https://en.wikipedia.org/wiki/Mutual_recursion
> >
> >
> >
> >       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 Tue, 22 Feb 2022, Dusan Cvijetic wrote:
> >
> >       > Pozdrav,
> >       >
> >       >       Ono sto sam primetio je drugacije imenovanje
> >       >
> >       > Koristio sam konvenciju sa donjom crtom umesto camelCase-a jer
> je tako stajalo u potpisu funkcija, meni je takođe svejedno kako ćemo
> pisati. Moj deo koda
> >       je mali i lako ćemo ga
> >       > prepraviti da isprati bilo koji sistem.
> >       >
> >       >       Druga stvar koja mi je zapala za oko je
> colorize_all_simplices, da bih vec iz argumenata video da nisu all. Mozda
> colorize_simplices_at_level?
> >       >
> >       >
> >       > Slažem se, ime koje ste predložili mi je jasnije. Promenio sam u
> kodu, pa mogu ponovo da ga ispravim ukoliko nije po volji - još nemamo
> toliko mnogo koda
> >       da bi prepravljanje bilo
> >       > ozbiljan posao.
> >       >
> >       >       Ova petlja bez potrebe nastavlja i posle nadjene
> odgovarajuce boje:
> >       >
> >       > Ispravio.
> >       >
> >       >       Ovde mi se ne svidja neuniformnost:
> >       >
> >       > Mislim da je ovo ispravljeno menjanjem imena funkcije za bojenje
> po nivoima.
> >       >
> >       >       Deluje da ce colorization biti successful ako se bar jedan
> simplex oboji. Jel treba tako?
> >       >
> >       > To sam zaboravio da spomenem u mejlu, nije naznačeno šta
> označava bool vrednost koju funkcija vraća, pa sam namestio da vraća true
> ukoliko je bar jedan
> >       simpleks obojen njenim pozivom.
> >       > Ne vidim koje bi se greške mogle javiti pri bojenju, a da ih mi
> hvatamo, osim da simpleksi ne postoje, a tada vraća false. Nije mi bilo
> logično da vraća
> >       false ukoliko ne oboji bar neki
> >       > simpleks jer je moguće da neki nivo neće imati simplekse (ne
> znam da li je to sa strane primene tako, ali mi je situacija u kome postoje
> samo 3D elementi
> >       u 8D kompleksu zamisliva), pa
> >       > bi bilo mnogo false slučajeva za situacije koje su legitimne.
> Trebalo je ranije da pitam, ali šta je ideja sa bool vrednošću koju f-ja
> vraća?
> >       >
> >       >       Usput, kako si testirao?
> >       >
> >       > Koristio sam samo onaj kod iz main.cpp, gde sam obojio
> tetrahedron. Uz to, testirao sam je uz pravljenje dva tetraedra da bih
> proverio kako se ponaša
> >       kada ubacimo više objekata, i bilo
> >       > je OK. Taj deo nisam hteo da ostavljam da ne bih previše remetio
> main.cpp.
> >       >
> >       >       Moj bespotrebni kod si mogao slobodno da ubijes, umesto da
> ga ostavljas iskomentarisanog.
> >       >
> >       > Urađeno.
> >       >
> >       > Pozdravi,
> >       > Dušan
> >       >
> >       >
> >       > уто, 22. феб 2022. у 11:04 Nenad Korolija <nenadko at gmail.com>
> је написао/ла:
> >       >       Zdravo Dušane,
> >       >
> >       > Marko ce videti validnost bojenja.
> >       >
> >       > Ja pisem ocima najgoreg neprijatelja, cisto da bi se svi
> navikavali na to da obracaju paznju i na detalje (mozda nakon sto napisu
> kako im je najlakse,
> >       mada verovatno bolje od
> >       > starta):
> >       >
> >       > Ono sto sam primetio je drugacije imenovanje (sa underscore, tj.
> _) u odnosu na moje (camel case, npr. "    bool hasUniqueColor = false;").
> Meni je OK
> >       bilo koja varijanta, samo da
> >       > bude uniformno, a ne da neko ko radi na kodu treba svaki cas da
> prilagodjava mindset prema tome ko je kucao taj deo koda. :)
> >       >
> >       > Druga stvar koja mi je zapala za oko je colorize_all_simplices,
> da bih vec iz argumenata video da nisu all. Mozda
> colorize_simplices_at_level?
> >       >
> >       > Ova petlja bez potrebe nastavlja i posle nadjene odgovarajuce
> boje:
> >       > already_has_unique_id = false;
> >       > for (auto cl : simplex->colors)
> >       >             if (cl->type == TYPE_UNIQUE_ID)
> >       >                 already_has_unique_id = true;
> >       >
> >       > Ovde mi se ne svidja neuniformnost:
> >       > colorize_entire_complex
> >       > samo ide po nivoima i poziva:
> >       > colorize_all_simplices
> >       >
> >       > Funkcije su kratke i lako se razumeju, ali je nezahvalno da neko
> mora da cita kod i zakljucuje, a da su nazivi funkcija neuniformni i
> misleading.
> >       >
> >       > Deluje da ce colorization biti successful ako se bar jedan
> simplex oboji. Jel treba tako?
> >       >
> >       > Usput, kako si testirao?
> >       >
> >       > Moj bespotrebni kod si mogao slobodno da ubijes, umesto da ga
> ostavljas iskomentarisanog. Sad imamo cist nacin, a ono moje je bilo cisto
> za testiranje
> >       print_compact.
> >       >
> >       >
> >       > Sto se tice toga kako treba uvezivati, mi smo inicijalno radili
> sve u jednom fajlu, pa smo razdelili, pa se Marko potrudio da napravi
> biblioteku i
> >       razresi neke probleme.
> >       > Radio sam za Italijane, Amerikance, Nemce i Engleze i svuda smo
> imali Makefile koji je kompajlirao pojedine cpp fajlove u .o objekte, pa ih
> link-ovao.
> >       Verovatno je ovo nase
> >       > trenutno include-ovanje nesto sto smeta VS-u.
> >       > Sledece bi u sustini trebalo da ne bude u classes.hpp (mada nama
> tako za sad odgovara zbog grupisanja funkcionalnosti), vec da se podeli u
> dva fajla:
> >       > class KSimplex;
> >       > class SimpComp{
> >       > public:
> >       > Ali ako je VS problem resen, mozemo da radimo dalje.
> >       > Hvala za forward deklaracije za KSimplex i SimpComp. :)
> >       >
> >       > Pozdrav,
> >       > Nenad
> >       >
> >       > On Tue, Feb 22, 2022 at 10:09 AM Dusan Cvijetic <
> dusancvijetic2000 at gmail.com> wrote:
> >       >       Pozdrav,
> >       >
> >       > Odradio sam funkcije za zadatak, proverite je li sve u redu.
> >       >
> >       > Tek kada sam izvršio commit sam se setio da poruke treba da
> pišem na engleskom, ispraviću sledeći put, nadam se da nije veliki problem.
> >       >
> >       > I pored refaktorisanog koda, organizacija klasa Color i
> KSimplex/SimpComp stvara probleme. Color traži da budu već deklarisani
> SimpComp i KSimplex, a
> >       KSimplex traži da već
> >       > bude deklarisan Color, a SimpComp traži KSimplex: Color >
> SimpComp > KSimplex > Color. Naterao sam ga da radi dodavši forward
> deklaracije za KSimplex i
> >       SimpComp u
> >       > triangulator.hpp, ali ne mislim da je to dobro rešenje. Iz mog
> ograničenog iskustva, ovo mi deluje kao loša delegacija odgovornosti. Možda
> bi bolje bilo
> >       da SimpComp samog
> >       > sebe boji, ili da imamo posebnu klasu "molera" koja će da boji
> simplekse po potrebi? Tako bi ona mogla da uključi i Color i KSimplex i
> SimpComp, bez
> >       problema koje trenutno
> >       > imamo. Trenutno mi deluje neprijatno da polje klase namešta samo
> sebe, lepše mi je da to bude odgovornost samog objekta, ili nekog njemu
> nadređenog.
> >       >
> >       > Opet, moje iskustvo s ovakvim problemima se svodi na samo jedan
> iole ozbiljniji projekat koji sam radio, tako da mi javite ukoliko grešim,
> zanima me kako
> >       se ove strukture
> >       > obično rešavaju u praksi.
> >       >
> >       > Pozdravi,
> >       > Dušan
> >       >
> >       > уто, 22. феб 2022. у 01:26 Marko Vojinovic <vmarko at ipb.ac.rs>
> је написао/ла:
> >       >
> >       >       Pozdrav Dusane,
> >       >
> >       >       Potpuno si u pravu da f-je za bojenje ne mogu (i ne treba)
> da se pozivaju za pojedinacnu boju. Dakle svakako, stavi ih kao static za
> klasu. Ja sam
> >       to zaboravio
> >       >       da naglasim u definiciji zadatka, ali iz smisla tih f-ja
> je relativno ocigledno. :-)
> >       >
> >       >       A taman posla da isti pointer dodeljujes celom kompleksu,
> to uopste nije bila ideja... ;-)
> >       >
> >       >       Sto se tice rekurzivnog ukljucivanja fajlova generalno,
> slazem se da to moze bolje da se uradi, i to cu da reorganizujem uskoro
> (veceras ili sutra,
> >       poslacu
> >       >       zaseban mail o tome). Reorganizacija ce da pomogne i za
> Visual Studio --- da se include-uju samo .hpp fajlovi a ne i .cpp fajlovi,
> da mozete da
> >       napravite
> >       >       projekat, mozda cak da koristite i njegov kompajler,
> itdisl.
> >       >
> >       >       A sto se tice rekurzivnog ukljucivanja fajlova u kontekstu
> zadatka 2, nemoj da se sekiras za to, nego treba samo da uradis sledece ---
> da
> >       deklaracije f-ja stavis
> >       >       u color.hpp fajl (gde im je mesto u njihovoj klasi), a da
> implementacije tih f-ja stavis u color.cpp, gde se nalaze implementacije i
> za sve ostale
> >       f-je koje su
> >       >       deklarisane u color.hpp. I onda kad si to uradio, testiraj
> f-je tako sto ces u main.cpp fajlu da obojis ceo tetrahedron (ili samo
> njegove vertekse,
> >       level=0) i da
> >       >       ga ispises ponovo --- tj. nakon pozivanja njegovog
> tetrahedron->print_compact(), uradi
> >       >
> >       >          UniqueIDColor::colorize_entire_complex( tetrahedron );
> >       >
> >       >       ili umesto toga uradi
> >       >
> >       >          UniqueIDColor::colorize_all_simplices( tetrahedron , 0
> );
> >       >
> >       >       i onda iza toga jos jednom pozovi
> tetrahedron->print_compact(). Zatim kompajliraj main.cpp i uporedi output-e
> ispisivanja tetrahedron-a pre i
> >       posle, da vidis
> >       >       kako tvoje f-je menjaju ono sto se ispisuje. I to je to.
> ;-)
> >       >
> >       >       :-)
> >       >       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, 21 Feb 2022, Dusan Cvijetic wrote:
> >       >
> >       >       > Pozdrav,
> >       >       >
> >       >       > Konačno jedno pitanje koje se ne tiče Visual Studio-a,
> već samog koda.
> >       >       >
> >       >       > Naime, koliko sam razumeo iz potpisa funkcija, one treba
> da budu članice klase UniqueIDColor. Pošto je kroz ovu funkciju iz jednog
> poteza
> >       potrebno dodeliti
> >       >       boje celom skupu simpleksa, a
> >       >       > svaki simpleks dobija svoju jedinstvenu boju, ne vidim
> kako bi se ona mogla pozivati za pojedinačne objekte ove klase (trebalo bi
> pozvati
> >       konstruktore boje za
> >       >       svaki simpleks), pa sam
> >       >       > mislio da je realizujem kao statičnu funkciju članicu
> klase. Da li sam pogrešno razumeo ovaj deo, i zapravo treba dodeliti
> pokazivač na istu boju
> >       celom delu
> >       >       simplicijalnog kompleksa,
> >       >       > tj. čitavom kompleksu?
> >       >       >
> >       >       > Nezavisno od prethodnog tumačenja, imam problem sa
> hijerarhijom klasa koji ne mogu da savladam. Potrebno je da KSimplex ima
> vektor pokazivača na
> >       objekte klase
> >       >       Color, pa je u classes.hpp
> >       >       > uključen color.cpp. S druge strane, u color.hpp potrebno
> je uključiti classes.hpp, da bih mogao da iteriram kroz vektor simpleksa u
> kompleksu i
> >       dodeljujem
> >       >       boje. Ovo vodi do rekurzivnog
> >       >       > uključivanja fajlova:
> classes.hpp->color.cpp->color.hpp->classes.hpp. Čak i da se klasa KSimplex
> deklariše pre #include "color.cpp", ostaje isti
> >       problem, pošto
> >       >       bez definicije klase ne
> >       >       > mogu da pristupam njenim poljima, jer je i dalje
> nepotpuni tip. Trenutno ne vidim način da se ovo izbegne, osim da se izmeni
> hijerarhija klasa,
> >       ili raspored po
> >       >       .hpp fajlovima. Propuštam
> >       >       > li nešto ovde? Nikad nisam radio sa tuđim kodom na ovaj
> način, pa se izvinjavam što mi treba više vremena da savladam sve.
> >       >       >
> >       >       > Pozdravi,
> >       >       > Dušan
> >       >       >
> >       >       > пон, 21. феб 2022. у 22:36 Dusan Cvijetic <
> dusancvijetic2000 at gmail.com> је написао/ла:
> >       >       >       Pozdrav,
> >       >       >
> >       >       > Hvala Vam mnogo, ponovio sam korake koje ste naveli u
> poruci, i Visual Studio sada uspeva da izgradi  i izvrši kod, a čak uspeva
> i da mi farba
> >       kod bez dodatnih
> >       >       koraka. Ipak, ne
> >       >       > vidim koja je razlika u odnosu na ono što sam ja radio
> (File/New project from existing code), osim što se fajlovi nalaze na drugom
> mestu. Nije mi
> >       jasno zašto
> >       >       isti kod hoće da
> >       >       > izvrši kada se u projekat unese na jedan način, a baca
> greške kada se uveze na drugi...
> >       >       >
> >       >       > Isprva sam pokušao da ispratim vaše korake bez prethodno
> kreiranog main.cpp fajla, i video da tada Visual Studio uopšte ne nudi meni
> >       >       Debug/Properties/Configuration Properties/C++,
> >       >       > pretpostavljam zato što nema koda na osnovu kog bi
> zaključio u kom jeziku ću pisati (?). Pretpostavljajući da će pronaći
> ispravan kompajler
> >       ukoliko direktno u
> >       >       VS kreiram main
> >       >       > funkciju, prekopirao sam sve .hpp i .cpp fajlove u
> direktorijum projekta, prethodno napravivši main.cpp u VS uz kopiranje koda
> iz originala.
> >       Nadao sam se da ću
> >       >       tako izbeći
> >       >       > uključivanje dodatnih direktorijuma, i eventualno
> namestiti da mi se projekat nalazi u lokalnom git direktorijumu, što bi mi
> bilo najzgodnije
> >       (ako je ovo iz
> >       >       nekog razloga loša
> >       >       > praksa, napomenite mi, da odmah odustanem). Međutim,
> kada fajlove uvezem na ovaj način, ponovo baca iste greške kao i ranije.
> >       >       >
> >       >       > Pošto ovakva konfiguracija za sad radi, držaću se nje,
> ali ako neko ima ideju šta mi se dešava, bio bih zahvalan na objašnjenju.
> >       >       >
> >       >       > Pozdravi,
> >       >       > Dušan
> >       >       >
> >       >       > пон, 21. феб 2022. у 18:09 Jaroslav Blagojevic <
> jaroslav.blagojevic at gmail.com> је написао/ла:
> >       >       >       Ja sam napravio prazan Visual Studio 2019
> projekat, u drugom direktorijumu nego download-ovani repozitorijum, samo sa
> main.cpp fajlom kao
> >       "source files"
> >       >       (hpp fajlovi
> >       >       >       kao "include files" i dodao direktorijum sa
> download-ovanim repozitorijumom u
> >
>  Dеbug->Properties->Configuration Properties->C++->General->Additional
> >       >       Include
> >       >       >       Directories).Taj projekat sam izvršio uspešno, a
> za potrebe menjanja, pošto nije hteo da mi farba kod, sam morao da
> copy&paste-ujem .hpp
> >       fajlove (i cpp
> >       >       fajl na kome
> >       >       >       radim) iz download-ovanog repozitorijuma u
> direktorijum projekta, izmenim .hpp fajlove (dodao sam nastavak '1' na
> svaki) da ne uključuju
> >       .cpp, kopiram i
> >       >       .cpp fajl
> >       >       >       (isto dodajući nastavak '1'), izmenim, testiram i
> copy&paste-ujem promene nazad. Neće da farba kod u .cpp fajlovima, zato što
> ih ne tretira
> >       kao include
> >       >       fajlove. Dotle
> >       >       >       sam stigao. Visual Studio traži da mu se svi .cpp
> fajlovi stave u projekat, a ne da se include-ju .cpp fajlovi u okviru jedan
> drugog.
> >       Pretpostavljam da
> >       >       ako to uradimo,
> >       >       >       da će biti problem sa g++-om (da li on podržava
> projekte?)
> >       >       >
> >       >       > Pozdrav,
> >       >       >
> >       >       > Jaroslav
> >       >       >
> >       >       >
> >       >       > On Sun, Feb 20, 2022 at 7:13 AM Marko Vojinovic <
> vmarko at ipb.ac.rs> wrote:
> >       >       >
> >       >       >       Pozdrav Dusane,
> >       >       >
> >       >       >       Meni se cini da svi problemi na koje si naisao
> izgleda dolaze iz neke greske prilikom import-ovanja koda u Visual Studio.
> Ja ne koristim VS
> >       i ne umem da
> >       >       ti
> >       >       >       pomognem oko toga, ali Jaroslav rece da je uspesno
> importovao kod u VS, pa verovatno moze on da ti pomogne.
> >       >       >
> >       >       >       Trenutna verzija koda je inace skroz kompletna,
> sve je definisano, implementirano i radi kako treba --- ja ga u Linux-u
> prosto kompajliram
> >       iz komandne
> >       >       linije,
> >       >       >       ovako:
> >       >       >
> >       >       >          g++ main.cpp -o izvrsi-me
> >       >       >
> >       >       >       i onda kad izvrsim fajl "izvrsi-me", dobijem
> ocekivani output. Kompajler ne prijavljuje nikakve greske, sve prolazi
> savrseno glatko.
> >       >       >
> >       >       >       > Koliko sam video, greške koje mi kompajler baca
> se uglavnom odnose na imena koja ne može da identifikuje, a koja dolaze iz
> standardne
> >       biblioteke.
> >       >       >
> >       >       >       Pomoglo bi da nam posaljes te greske (makar prvih
> nekoliko), da vidimo o cemu se radi.
> >       >       >
> >       >       >       > Video sam da je using namespace std iskorišćen
> na početku triangulator.hpp fajla, ali me je zanimalo zašto ta komanda ne
> stoji na početku
> >       svakog .hpp
> >       >       fajla? Da
> >       >       >       li bi to bilo redudantno?
> >       >       >
> >       >       >       Da, bilo bi redundantno. Dizajn je da main.cpp
> include-uje samo triangulator.hpp, a da ovaj u sebi include-uje sve ostalo
> sto mu treba. Ne
> >       vidim zasto bi
> >       >       zeleo
> >       >       >       da deklarises namespace std vise puta. Mada mi se
> cini da cak i ako to uradis, ne bi trebalo da nastane nikakav problem.
> >       >       >
> >       >       >       Bila bi dobra ideja da na papiru nacrtas "drvo
> include-ova": koren je main.cpp, pogledas koji fajlovi su tu include-ovani,
> pa se onda
> >       spustas po granama
> >       >       tako sto
> >       >       >       onda otvoris te include-ovane fajlove i vidis sta
> oni include-uju, itd. Ja sam to bio uradio jednom, i preporucujem i tebi
> --- to drvo ti
> >       pruza vrlo lep
> >       >       uvid u
> >       >       >       organizaciju koda.
> >       >       >
> >       >       >       > Da li postoji neko pravilo kada treba da
> uključujem .hpp, a kada .cpp fajlove?
> >       >       >
> >       >       >       Genericki receno, .hpp fajlovi sadrze definicije
> klasa i deklaracije njihovih metoda i f-ja, a .cpp fajlovi sadrze
> implementacije tih
> >       metoda i f-ja
> >       >       deklarisanih
> >       >       >       u .hpp fajlovima. Oni su vec namesteni da
> include-uju jedni druge, prema onom drvetu, ti tu ne bi morao nista dodatno
> da radis.
> >       >       >
> >       >       >       > Još jedna od praksi koje su nas uvek terali da
> ispoštujemo je dodavanje zaštite u zaglavlja u vidu #ifndef - #define -
> #endif strukture
> >       >       >
> >       >       >       Ta praksa je sigurno dobra, ali mi smo
> #define-ovali konstante samo u constants.hpp fajlu, i nigde drugo. Iz
> drveta mozes da vidis da je
> >       constants.hpp
> >       >       >       include-ovan samo jedanput (unutar classes.hpp),
> pa ne bi smela nigde da ti se pojavi dupla definicija tih konstanti.
> Kasnije cemo
> >       verovatno da dodamo
> >       >       #ifndef
> >       >       >       strukturu u constants.hpp, da budemo u skladu sa
> praksom, ali to nije sad najhitnija stvar --- kod momentalno radi ispravno
> i bez toga. :-)
> >       >       >
> >       >       >       > pa bih cenio bilo kakvu pomoć koju možete da mi
> pružite.
> >       >       >
> >       >       >       Jaroslave, jel' bilo neceg netrivijalnog oko
> ubacivanja koda u Visual Studio? Jel' imas neki hint za Dusana?
> >       >       >
> >       >       >       :-)
> >       >       >       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, 20 Feb 2022, Dusan Cvijetic wrote:
> >       >       >
> >       >       >       > Pozdrav,
> >       >       >       >
> >       >       >       > Počeo sam da radim drugi zadatak kao što smo
> pričali, i imam problem sa pokretanjem koda. Nisam ništa menjao u
> fajlovima, samo sam
> >       napravio projekat u
> >       >       Visual
> >       >       >       Studio-u 2019
> >       >       >       > (File/New/Project from existing code, sa svim
> default opcijama), i kada pokušam da ga pokrenem, kompajler mi baci gomilu
> grešaka. Da li
> >       je u ovom
> >       >       trenutku
> >       >       >       generalno nemoguće pokrenuti
> >       >       >       > main.cpp, ili ja pravim neku grešku?
> >       >       >       >
> >       >       >       > Koliko sam video, greške koje mi kompajler baca
> se uglavnom odnose na imena koja ne može da identifikuje, a koja dolaze iz
> standardne
> >       biblioteke. Video
> >       >       sam da
> >       >       >       je using namespace std
> >       >       >       > iskorišćen na početku triangulator.hpp fajla,
> ali me je zanimalo zašto ta komanda ne stoji na početku svakog .hpp fajla?
> Da li bi to bilo
> >       redudantno?
> >       >       >       >
> >       >       >       > Kada smo na fakultetu radili C++, uvek smo
> #include direktive koristili da uvezemo neke header-e u trenutni fajl, no
> video sam da se u
> >       kodu ovde nekada
> >       >       >       uključuju .hpp, a nekada .cpp
> >       >       >       > fajlovi. Da li postoji neko pravilo kada treba
> da uključujem .hpp, a kada .cpp fajlove?
> >       >       >       >
> >       >       >       > Još jedna od praksi koje su nas uvek terali da
> ispoštujemo je dodavanje zaštite u zaglavlja u vidu #ifndef - #define -
> #endif strukture
> >       (tražili su nam
> >       >       da ne
> >       >       >       koristimo #pragma once jer
> >       >       >       > zavisi od kompajlera) kako bismo izbegli
> višestruku definiciju pri uključivanju zaglavlja. Da li mi koristimo neku
> drugu zaštitu za
> >       zaglavlja? Dosta
> >       >       grešaka
> >       >       >       koje mi je kompajler bacio
> >       >       >       > je bilo zbog redefinicije promenljivih, pa
> pretpostavljam da je to zbog odsustva zaštite zaglavlja.
> >       >       >       >
> >       >       >       > Na par mesta su se pojavila imena koja ranije
> nisu definisana. Pretpostavljam da je to zato što još uvek nemamo ceo kod,
> pa nisu sve
> >       funkcije i
> >       >       promenljive
> >       >       >       uvedene, no hteo sam ovde da
> >       >       >       > spomenem i te greške za slučaj da su problem
> samo kod mene.
> >       >       >       >
> >       >       >       > Na kraju sam pokušao da izmenim kod na mestima
> koje sam gore spominjao, samo da vidim mogu li ga naterati da se pokrene, i
> iako je
> >       kompajler prestao da
> >       >       se
> >       >       >       javlja, linker je počeo da mi
> >       >       >       > baca greške. Pretpostavljam da postoji neko
> sistematičnije rešenje za moje probleme (do sada mi se linker javljao samo
> kada ne startujem
> >       projekat u VS
> >       >       kako
> >       >       >       treba), pa bih cenio bilo
> >       >       >       > kakvu pomoć koju možete da mi pružite.
> >       >       >       >
> >       >       >       > Pozdravi,
> >       >       >       > Dušan
> >       >       >       >
> >       >       >       >
> >       >       >       > пет, 11. феб 2022. у 22:34 Marko Vojinovic <
> vmarko at ipb.ac.rs> је написао/ла:
> >       >       >       >
> >       >       >       >       Upoznati se sa osnovnom klasom Color i
> njenim child-klasama kroz problem dodeljivanja boje UniqueIDColor datom
> delu simplicijalnog
> >       kompleksa,
> >       >       odnosno
> >       >       >       celom kompleksu:
> >       >       >       >
> >       >       >       >          bool
> UniqueIDColor::colorize_all_simplices( SimpComp* G , int level );
> >       >       >       >          bool
> UniqueIDColor::colorize_entire_complex( SimpComp* G );
> >       >       >       >
> >       >       >       >          Input: pointer na simplicijalni
> kompleks, nivo "k" za k-simplekse koje treba obojiti.
> >       >       >       >          Output: true ako je uspesno izvrseno
> bojenje, false ako je doslo do neke greske.
> >       >       >       >
> >       >       >       >       F-ja colorize_all_simplices() treba da
> prodje kroz sve simplekse iz G.elements[level] (ili se pise
> G->elements[level]?), i svakom
> >       od njih da
> >       >       dodeli
> >       >       >       instancu boje klase
> >       >       >       >       UniqueIDColor. F-ja
> colorize_entire_complex() treba da izvrsi prethodnu f-ju za sve vrednosti 0
> <= level <= D. Nakon toga,
> >       zakomentariti kod koji
> >       >       >       dodeljuje ovu boju u seed
> >       >       >       >       f-ji seed_single_triangle() (boju boundary
> ne dirati, ona treba da ostane u seed f-ji), i umesto toga u main() f-ji
> eksplicitno
> >       pozvati
> >       >       >       colorize_entire_complex() da oboji
> >       >       >       >       kompleks za trougao, odmah nakon sto se
> ovaj instancira.
> >       >       >       >
> >       >       >       >
> >       >       >       >       :-)
> >       >       >       >       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
> >       >
> >       >
> >       >--
> >       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/20220224/b5d07ef8/attachment-0001.htm>


More information about the QGHG-it-dev-list mailing list