[QGHG-it-dev-list] Одговор на Задатак 35 од 2022-11-30: Функције за енкодирање и декодирање xml-стрингова
Лазар Радосављевић
lazar.n.rad at gmail.com
Thu Feb 13 03:47:46 CET 2025
Преместио сам #include !
И мени „боло очи” кад сам видео да се при читању фајла ослањамо искључиво
на претпостављени редослед података. Бацио сам поглед на библиотеку, може
да се специфицира да желим чвор-дете одређеног имена. Имплементираћу то
наредних дана.
Лазар
пон, 20. јан 2025. у 14:06 Marko Vojinovic <vmarko at ipb.ac.rs> је написао/ла:
>
> Pozdrav Lazare,
>
> Super, hvala za kod! :-) Imam samo jednu sugestiju da ispravis --- u fajlu
>
> library/src/input_and_output.cpp
>
> si dodao include direktivu
>
> #include <cstring>
>
> jer ti treba za funkcije za enkodiranje i dekodiranje. Ta direktiva ne
> treba
> da stoji tu u tom .cpp fajlu, nego treba da se premesti u fajl
>
> library/include/triangulator.hpp
>
> gde stoje sve ostale include direktive za ceo projekt. Ideja je da svaki
> .cpp
> fajl include-uje samo triangulator.hpp na svom pocetku, a odatle iznutra
> ce da
> se include-uje sve ostalo sto nam treba. Pogledaj strukturu
> triangulator.hpp
> fajla, bice ti ocigledno gde treba da se doda <cstring>.
>
> Inace, sto se tice ispravke baga u save_complex_to_xml_file(), to si
> odlicno
> uradio. Sada me interesuje tvoje misljenje oko fje
> read_complex_from_xml_file().
> Kako vidim, fja se trenutno oslanja na format .xml fajla u kome se prosto u
> prvom nodu nalazi ime kompleksa, pa u drugom dimenzija, pa u trecem
> topologija,
> itd. Ako ubuduce iz bilo kog razloga dodamo negde nove nodove u .xml fajl
> ili
> promenimo redosled, fja za citanje ce da se pokvari. Da li bi imalo vise
> smisla
> fju za citanje implementirati po sledecoj ideji --- procitas naziv noda,
> pa ako
> se nod zove "simpcomp" onda je njegova vrednost ime kompleksa, a ako se
> nod zove
> "dimension" onda je njegova vrednost dimenzija kompleksa, itd.
>
> Dakle ideja je da fja za citanje pogleda kako glasi naziv datog noda, pa
> onda da
> ucita vrednost noda u odgovarajucu variablu. Ako naziv nekog noda ne
> prepozna,
> moze da prijavi gresku i da ga preskoci ili sl.
>
> Meni se cini da bi takva fja za citanje bila robustnija na buduce izmene
> strukture .xml fajla. Sa druge strane, kada pocne onaj komplikovani deo ---
> citanje listi simpleksa, njihovih boja i suseda --- onda ne znam da li ima
> smisla
> proveravati nazive xml nodova, nego je mozda bolje prosto se osloniti na
> njihov
> redosled ili sl.
>
> Dakle, kako se tebi cini, da li ima smisla prepravljati fju za citanje,
> ili nema
> mnogo koristi od toga (ili je preveliki posao), i da je bolje da je
> ostavimo
> ovako kako je sada?
>
> :-)
> 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 Sat, 18 Jan 2025, Лазар Радосављевић wrote:
>
> > То је то, послао сам оба! :D
> >
> > пет, 17. јан 2025. у 12:54 Marko Vojinovic <vmarko at ipb.ac.rs> је
> написао/ла:
> >
> > Pozdrav Lazare,
> >
> > Jeste, potpuno sam zaboravio da treba da te dodam na spisak
> kolaboratora na GitHub-u...
> >
> > Evo poslat ti je invitation, pretpostavljam da je to 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 Fri, 17 Jan 2025, Лазар Радосављевић wrote:
> >
> > > Договорено!
> > >
> > > Треба онда само да ме додате међу сараднике на Гитхабу (ја сам
> lazar-rad). За сад бих могао само pull request да пошаљем.
> > >
> > > Поздрав,
> > > Лазар
> > >
> > > уто, 14. јан 2025. у 13:57 Marko Vojinovic <vmarko at ipb.ac.rs>
> је написао/ла:
> > >
> > > Pozdrav Lazare,
> > >
> > > Srecni praznici! :-)
> > >
> > > Super si ovo izanalizirao, nisam znao da je bag u nazivu
> taga a ne u konverziji stringova.
> > >
> > > Slazem se da prepravis format tako kako si predlozio (prvo
> resenje), implementiraj ga i
> > > uploaduj.
> > >
> > > A sto se tice funkcija koje si implementirao za konverziju
> stringova, ubaci i njih u
> > > input_and_output.cpp, bez obzira sto ih ne koristimo.
> Moguce da cemo ih koristiti kasnije,
> > > jer nesto nisam odusevljen rapidxml bibliotekom, mozda
> cemo je kasnije izbaciti i umesto
> > > nje staviti neku zgodniju ili napraviti nase lokalno
> resenje za xml, da se ne oslanjamo
> > > na tudj kod. Ali o tom potom...
> > >
> > > Funkcije ubaci u zasebnom push-u, da ih ne mesamo sa onom
> popravkom formata odozgo.
> > >
> > > Hvala i pozdrav!
> > >
> > > :-)
> > > 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, 14 Jan 2025, Лазар Радосављевић wrote:
> > >
> > > > Поштовани,
> > > >
> > > > Позабавио сам се проблемом из овог задатка. Написао сам
> функције које се траже и оне лепо раде. Покушао сам онда да их применим у
> функцијама за чување и учитавање симплицијалних комплекса (убацио сам их на
> она
> > места
> > > где се уписују,
> > > > односно дохватају, вредности xml елемената или атрибута)
> и резултат су били потпуно нечитљиви стрингови. Мислим да то има везе с тим
> што библиотека rapidxml има неки свој систем алокације стрингова, који је
> > овим путем
> > > био поремећен.
> > > >
> > > > Међутим, мислим да проблем уопште није био у одсуству
> ових функција. Библиотека rapidxml већ ради конверзију свих
> „проблематичних” карактера. Проблем је у функцији `void
> save_complex_to_xml_file(SimpComp*,
> > const
> > > string&)`, у томе
> > > > како она назива xml-елементе које креира. Наиме, ово је
> формат xml-документа који ће бити произведен:
> > > >
> > > > <"complex_name">
> > > > <name> "complex_name" </name>
> > > > <dimension> "D" </dimension>
> > > > <topology> "topology of the complex" </topology>
> > > > [<level lvl="l"> "simplices_id_list" </level> ...]
> > > > [
> > > > <ksimplex id="ksimplex_ID">
> > > > <self_level> "ksimplex_lvl" </self_level>
> > > > [<color color_type="color_type_id">
> "color_value" </color> ...]
> > > > [<level lvl="lvl"> "neighbours_at_lvl" </level>
> ...]
> > > > </ksimplex>
> > > > ]
> > > > </complex_name>
> > > >
> > > > Име симпкомпа који желимо да сачувамо се користи као
> садржај елемента <name>, али такође и као назив (таг) кореног елемента. По
> стандарду, називи елемената смеју да садрже само алфанумеричке знакове,
> доње црте,
> > цртице
> > > и тачке (мада
> > > > се последња два не препоручују). Друге специјалне
> знакове, а поготово размаке, не смеју да садрже.
> > > >
> > > > Такође, називи елемената xml-документа би требало (за
> конкретну примену) да буду предефинисани, а не произвољни. Зато ме чуди то
> што је стављено да се за назив кореног елемента користи стринг који корисник
> > задаје, и
> > > који може да
> > > > буде потпуно произвољан. Мислим да би најисправније било
> да се и назив кореног елемента предефинише, као што је случај са свим
> другим елементима. Предлажем да тај назив буде `simpcomp`, јер цео садржај
> > документа и
> > > представља запис
> > > > једног симплицијалног комплекса. Име нашег конкретног
> симпкомпа ће, наравно, остати у потпуности сачувано као садржај елемента
> <name>. Формат xml-документа би онда био:
> > > >
> > > > <simpcomp>
> > > > <name> "complex_name" </name>
> > > > <dimension> "D" </dimension>
> > > > <topology> "topology of the complex" </topology>
> > > > [<level lvl="l"> "simplices_id_list" </level> ...]
> > > > [
> > > > <ksimplex id="ksimplex_ID">
> > > > <self_level> "ksimplex_lvl" </self_level>
> > > > [<color color_type="color_type_id">
> "color_value" </color> ...]
> > > > [<level lvl="lvl"> "neighbours_at_lvl" </level>
> ...]
> > > > </ksimplex>
> > > > ]
> > > > </simpcomp>
> > > >
> > > > Алтернативно решење би било да се уведе функција која
> трансформише стринг у облик који је подобан да представља назив елемента.
> Ово је сасвим другачија операција у односу на стандардно xml-овско
> ескејповање. Не
> > би била
> > > инвертибилна,
> > > > мада за тим ни нема потребе. Могла би да се реализује,
> рецимо, тако што би се сви недозвољени знакови заменили доњом цртом, или
> тако што би се игнорисали. На пример, ако смо симпкомп назвали "Ham &
> Eggs", таг
> > кореног
> > > елемента би био
> > > > <Ham___Eggs> или <HamEggs>.
> > > >
> > > > Да закључим, ја сам за прво решење, да корени елемент
> има таг <simpcomp>; лакше је, а и сматрам да је боље. Истестирао сам и
> исправно ради. Спреман сам да имплементирам, само чекам одобрење.
> > > > Срећни новогодишњи и божићни празници!
> > > > Лазар Радосављевић
> > > >
> > > >--
> > > QGHG-it-dev-list mailing list
> > > QGHG-it-dev-list at mail.ipb.ac.rs
> > > https://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> > >
> > >
> > >--
> > QGHG-it-dev-list mailing list
> > QGHG-it-dev-list at mail.ipb.ac.rs
> > https://mail.ipb.ac.rs/mailman/listinfo/qghg-it-dev-list
> >
> >
> >--
> QGHG-it-dev-list mailing list
> QGHG-it-dev-list at mail.ipb.ac.rs
> https://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/20250213/151b05ff/attachment-0001.htm>
More information about the QGHG-it-dev-list
mailing list