[elektro] cé típus

[Topybear]

E szerint a doksi szerint a PIC C18-ra is igaz, hogy a signed int
-32768 - 32767.

https://www.sonoma.edu/users/f/farahman/sonoma/courses/es310/lectures/c_prog.pdf


Topy

Topybear <topybear at gmail.com> írta (2014. május 16. 10:15):
> Az int alapból signed szokott lenni és jellemzően -32768-32767 az
> értéktartomány. Az a 38000 negatív számba fordul ebben az esetben.
>
> Topy
>
> Skandar Graun <sgraun at gmail.com> írta (2014. május 16. 9:52):
>> pos = 9500 (0x251c)
>> cel = 38000 (0x9470)
>>
>>
>>
>> Amit írsz, azt elfogadom, csak a problémám pont az, hogy ebből a kettőből
>> 0x6f54-nek kéne kijönni, bármilyen cast esetén... ehelyett 0x5f6f54 jött ki.
>> Ahogy mozog a pos, közelíti a célt, az 5f érték nem változik,
>> átbillenésnél, ahol a pos nagyobb lesz, mint a cél, 0x5ffff6-ra változik...
>> nem pedig negatívra.
>>
>>
>> 2014. május 16. 9:43 SZIGETI Szabolcs írta, <szigiszabolcs at gmail.com>:
>>
>>> Hali!
>>>
>>> Hogy az utolsó miért nem működik, az egy jó kérdés, de megjegyzés az előtte
>>> lévő példákhoz.
>>>
>>> Ha két int-tel végzel művelet, akkor az eredmény int lesz, minden esetleges
>>> alul-, túlcsordulással és csonkolással. Ezt hiába rakod long-ba, nem segít.
>>> Arra kell kényszeríteni a C fordítót, hogy eleve longokkal végezzen
>>> műveletet. Tehát arra vigyázz, hogy ne a kifejezés eredményét, hanem a
>>> tago(ka)t castold.
>>>
>>> Analóg módon a
>>>
>>> double a;
>>> int x=5;
>>> int y=2;
>>>
>>> esetében az
>>> a=x/y esetén a értéke 2.0 lesz, a=(double)(x/y) szintén,
>>> a=(double)x/y viszont a helyes 2.5 értéket fogja adni, mert nem int, hanem
>>> float osztást fog alkalmazni.
>>>
>>> Én megnézném, hogy milyen assembly-t generál a fordító, abból eldönthető,
>>> hogy jó-e vagy sem. Milyen konkrét értékre kaptad ezt?
>>>
>>> Szabolcs
>>>
>>>
>>>
>>>
>>> 2014. május 16. 8:12 Skandar Graun írta, <sgraun at gmail.com>:
>>>
>>> > Sziasztok!
>>> >
>>> > PIC C18
>>> >
>>> > int     h1_prop_err;
>>> > int     huzo_1_cel;
>>> > int      huzo_1_pos;
>>> >
>>> > huzo_1_pos = 100;
>>> > huzo_1_cel = 400;
>>> >
>>> > h1_prop_err = huzo_1_cel - huzo_1_pos;
>>> >
>>> > így jó.
>>> >
>>> > De ha:
>>> >
>>> > long     h1_prop_err;
>>> > int     huzo_1_cel;
>>> > int      huzo_1_pos;
>>> >
>>> > h1_prop_err = huzo_1_cel - huzo_1_pos;
>>> >
>>> > akkor nem jó, a long változó második byte-jába bejön egy 0x5f érték
>>> >
>>> > ha:
>>> >
>>> > long     h1_prop_err;
>>> > int     huzo_1_cel;
>>> > int      huzo_1_pos;
>>> >
>>> > h1_prop_err = (long)(huzo_1_cel - huzo_1_pos);
>>> >
>>> > akkor is.
>>> >
>>> > ha:
>>> >
>>> > long     h1_prop_err;
>>> > int     huzo_1_cel;
>>> > int      huzo_1_pos;
>>> >
>>> > h1_prop_err = ((long)huzo_1_cel - (long)huzo_1_pos);
>>> >
>>> > akkor is.
>>> >
>>> > Ha kimaszkolom &0x0ffff-el, akkor eltűnik, de akkor nem tudom kezelni a
>>> > negatív számokat.
>>> >
>>> > Mi nem jó?
>>> > -----------------------------------------
>>> >           elektro[-flame|-etc]
>>> -----------------------------------------
>>>           elektro[-flame|-etc]
>>>
>> -----------------------------------------
>>           elektro[-flame|-etc]