[QGHG-it-dev-list] Одговор на Задатак 35 од 2022-11-30: Функције за енкодирање и декодирање xml-стрингова
Marko Vojinovic
vmarko at ipb.ac.rs
Mon Jan 20 14:06:34 CET 2025
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
>
>
>
More information about the QGHG-it-dev-list
mailing list