[QGHG-it-dev-list] Zadatak 2 - bojenje kompleksa
Nenad Korolija
nenadko at gmail.com
Tue Feb 22 23:23:25 CET 2022
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20220222/064467b5/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list