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