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

Marko Vojinovic vmarko at ipb.ac.rs
Wed Feb 23 04:41:57 CET 2022


Novi nazivi f-ja su ok (bolji su od starih), ali necemo da merge-ujemo obe f-je u jednu. Trebace nam za kasnije colorize_simplices_at_level() kao nezavisna f-ja, namerno sam je trazio u zadatku 2. Svidja mi se ovako kako je, neka ostane. ;-)

:-)
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 Tue, 22 Feb 2022, Nenad Korolija 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
> 
> 
>


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