Cześć, mam taką sytuację. Jest dll(c++), w którym jest pewna funkcja. Funkcja w parametrze przyjmuje wskaźnik na unsigned integer. W Delphi unsigned integer to po prostu cardinal. Tylko teraz tak. Czy ja muszę deklarować u siebie ten parametr jako PCardinal, czy mogę swobodnie jako PInteger?
Wiadomo, wksaźnik to wskaźnik. Jego rozmiar jest niezależny od typu danych na jaki wskazuje. Pytanie, czy gdzieś później coś się może zwalić? Bo teoretycznie zawartość w pamięci powinna być taka sama, tak?
Będzie ok. Możesz signed'a interpretować jako unsigned'a. Ważne jest, by pojemność typu była zgodna. Pytanie tylko po co wprowadzać takie komplikacje/nieścisłości?
Będzie źle. Wywołujesz tą funkcję po to aby przekazać lub odebrać jakąś tablicę unsigned int, więc przy dużych wartościach nastąpią przekłamania. Np. ty podajesz liczbę ujemną a funkcja rozumie to jako bardzo dużą wartość dodatnią, albo funkcja przekazuje dużą wartość dodatnią a ty to odbierasz jako liczbę ujemną.
http://rvelthuis.de/articles/articles-convert.html bo oczywiście poszukać to za trudne
Generalnie ja nigdy nie przekażę wartości ujemnej, ani bardzo dużej dodatniej(wykraczającej za zakres integera). Tak więc mi też się wydaje, że będzie dobrze, ale chciałem się upewnić.
@Juhas przy wpisaniu/odczycie do/z tabeli każdej wartości będziesz sprawdzać zakres? A dane sam generujesz czy użytkownik wprowadza?
Dane sam generuję i wiem, że nie wykroczą poza zakres.
Tak czy owak odradzam. Za jakiś rok czy więcej przykładowo wrócisz do tego programu tylko zechcesz zbadać "szersze zakresy" i nie będziesz pamiętał (a ze swego kodu nie wyczytasz) o tym że dane muszą być w pewnym zakresie.
Ja tego nie potrafię zrozumieć. Masz jakąś tam wiedzę, coś tam piszesz ale z Twoich postów wynika, że masz tak poryty kod jakbyś po nim koniem z pługiem jeździł. Wszelkie zasady masz głęboko w dupie (co widać choćby tutaj - rozmiar się zgadza to jebać zakres). Większość Twoich problemów potem wynika właśnie z takiego podejścia i później powstają potworki, gdzie próbujesz łatać wcześniejsze wymysły nowymi genialnymi pomysłami zamiast zrobić po prostu tak jak sztuka mówi...
Jestem pewny, że w przyszłości zamiast zmienić typ na Cardinal to będziesz sprawdzał czy wartość się mieści w przedziale 0 do Max(Int) i ignorował całą połowę zakresu wartości, które można przekazać
Ja tego nie potrafię zrozumieć. Masz jakąś tam wiedzę, coś tam piszesz ale z Twoich postów wynika, że masz tak poryty kod jakbyś po nim koniem z pługiem jeździł. Wszelkie zasady masz głęboko w dupie (co widać choćby tutaj - rozmiar się zgadza to jebać zakres)
Zgadzam się.
Skoro masz dwa rozwiązania które mają te same koszty, jedno 'prawie' dobre, drugie dobre, to które wybierasz? Oczywiście że prawie dobre. Jak możesz napisać program na obiektówce albo na goto to jak piszesz? Na goto, bo też 'prawie' dobrze. Gratuluję głupich wyborów. No ale tacy geniusze na drzewach nie rosną, zobaczymy co będzie gdy prędzej czy później wpadniesz w swoje debilne rozwiązania.
Hmm, nie sądzę, że autor chce użyć PInteger zamiast PCardinal tylko dlatego, że ma takie widzi-mi-się. Widocznie on chce interpretować unsigned jako signeda i zdaje sobie sprawę z "przekręcania" intów i to jest właściwie jego celem. Innego rozsądnego wyjaśnienia nie widzę, jeśli się mylę, to czegoś tu nie rozumiem.
Nawet wytłumaczę wam to jego widzi mi się. PInteger jest już zadeklarowany w systemie, zaś PCardinal - nie. Koleś chce oszczędzić jeden wiersz kodu.
Być może jeszcze lepszym rozwiązaniem będzie parametr var albo out typu cardinal, zamiast pcardinal...
albo out
Out z całą pewnością nie jest dobrym pomysłem ze względu na zachowanie FPC które zmniejsza referencję takiego pointera. Szczegółów nie znam, ale to jest powód dla którego wiele procedur które powinny być out jest var (np. FillChar). Co do var to wiele headerów FPC właśnie tak to deklaruje i z tego co wiem jest to rozwiązanie dosyć bezpieczne.
Jest pewna różnica pomiędzy var X:Integer a X:PInteger. Pierwsze sugeruje (i prawie zapewnia) ze nie możemy przekazać nil.