[GLib][C++] Praca z guint16

Dla specjalistów Programowanie
#1

Jeśli chcę wykonywać działania arytmetyczne na guint’ach to ma to wyglądać mniej więcej tak?

guint16 a;

	a = 1000;

	guint16 b;

	b = a*(guint16)2;

Czy są może jakieś lepsze metody?

#2

Co to za dwójka na końcu ostatniego wiersza?

#3

Zapewne rzutowanie w stylu C

#4

Jawne rzutowanie nie jest potrzebne, tylko zaciemnia kod. Bez też będzie działało. A jak ma dojść do przekroczenia zakresu wartości, to i rzutowanie nie pomoże.

#5

No działa bez rzutowania, ale mam swoją klasę napisaną na intach, program będzie odczytywał dane z Gtk::Entry które zwraca np guint16. Najlepiej będzie przerobić moją klasę na guinty czy pracować na mieszance?

#6

To zależy co ta wartość reprezentuje i jak ważny jest stały rozmiar między architekturami. Trochę bezpieczniej jest jeśli operacje są prowadzone na liczbach o tym samym znaku (w sensie z/bez). Jeśli to ma sens, możesz zrobić klasę szablonową - no ale to kwestia tego co to za klasa, o której mówisz.

#7

W sumie nieważne dla mnie jest jaki jest rozmiar typu na którym klasa pracuje. Klasa typowo licząca. Tylko jeśli przerobię ją na guint16 to potem gdybym chciał frontend dodać w QT4 np. to już trochę traci sens?

Nie mam doświadczenia jak modelować klasy “silnikowe”. Chociaż klasa szablonowa ma sens w tym przypadku.

#8

Jeśli masz taką sytuację “mniejszy” typ liczbowy na “większy” typ liczbowy to nie ma problemu, tak jak w guint16 → int. W drugą stronę tak różowo nie jest, ale jeśli konwersji w drugą stronę nie masz, to ok.

Raczej tak. Tzn gdyby chodziło tylko o te typedefy, to nie byłby problem od strony programistycznej, no ale głupio, żeby coś w Qt miało zależności do GLib i to tylko dla typedefów.

#9

No właśnie, więc jak najlepiej robić klasę silnikową tak aby łatwo ją było użyć i przez GTK i przez QT?

Dla mnie najlepszym wyborem wydają się typy wbudowane int, double…

EDIT, Tymczasowo widzę że problem odroczyłem, bo Gtk::SpinButton ma metodę get_value_as_int(), ale i tak warto by pomyśleć co by było gdyby nie było więc

#10

Ja bym używał po prostu standardowych typów, takie jakie są w danym przypadku potrzebne (ew. typdefów z inttypes.h) - bo to jest najbardziej przenośne i nie trzeba się zastanawiać, jaki fronted zostanie do tego dopisany. Natomiast późniejsza współpraca danego kodu z typedefami z Qt/Gtk to w sumie kwestia pamiętania, żeby (przynajmniej bez odpowiedniego zabezpieczenia) nie przypisywać wartości pojemniejszego typu, do mniej pojemnego (no ale to już problem tego, kto pisze frontend :))

#11

Ok, no więc dzięki (;