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

Nenad Korolija nenadko at gmail.com
Sun Feb 20 21:09:26 CET 2022 

Ja koristim:
g++ -g -w -std=c++14 main.cpp -o main
Mozda baca greske zato sto ne zna sta je auto i slicne stvari. Ne mogu da
procenim, bez da uradis nesto tipa gcc main.cpp -o izvrsi-me > output.txt,
pa da nam posaljes, ili da kopiras iz prozora u email.

Pozdrav,
Nenad

On Sun, Feb 20, 2022 at 8:59 PM Dusan Cvijetic <dusancvijetic2000 at gmail.com>
wrote:

> Pozdrav,
>
> Malo sam se prerano poradovao, sada mi i Code::Blocks baca iste greške kao
> i Visual Studio. Pokušao sam i iz konzole, komandom gcc main.cpp -o
> izvrsi-me, no i tu baca grešku. Trenutno sam ponovo zaglavljen, i ne
> poznajem dovoljno funkcionisanje prevodilaca, pa ne znam ni kako da počnem
> ovo da rešavam.
>
> Pozdravi,
> Dušan
>
> нед, 20. феб 2022. у 20:31 Dusan Cvijetic <dusancvijetic2000 at gmail.com>
> је написао/ла:
>
>> Pozdrav,
>>
>> Hvala Vam na odgovorima.
>>
>> Šaljem u prilogu tabelu sa greškama koje mi baca Visual Studio. U pravu
>> ste, greške proističu iz nekog dela mog importa koda, ili nekih podešavanja
>> VS, pošto kod radi kada ga pokrećem koristeći Code::Blocks i GNU GCC
>> kompajler umesto onog ugrađenog u VS. Koristiću za sad Code::Blocks, ali bi
>> mi značila pomoć, ukoliko neko ume da rastumači šta mi se dešava, pošto sam
>> na Visual Studio navikao i prijatnije mi je tamo da radim.
>>
>> Pozdravi,
>> Dušan
>>
>>
>>
>> нед, 20. феб 2022. у 07:13 Marko Vojinovic <vmarko at ipb.ac.rs> је
>> написао/ла:
>>
>>>
>>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ipb.ac.rs/pipermail/qghg-it-dev-list/attachments/20220220/841e6d04/attachment-0001.htm>

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