Programovanie ccs C

[niki31]

Chcem sa spýtať skúsenejších programátorov na jednu vec, ohľadne porovnávania dvoch premenných. V ccs C som narazil na takýto problém. Ak vytvorím podmienku kde sa porovnávajú dve premenné, jedna je znamienková a druhá neznamienková, výsledok porovnania je chybný. Pri porovnaní dvoch čísiel napr. 5 > 2 je výsledok false. Je toto normálne aj v iných kompilátoroch alebo to je nejaký kix? Chápem že záporne číslo by bolo vyhodnotené ako väčšie lebo má nastavený znamienkový bit ale dve kladné čísla ? V žiadnej učebnici ani v manuáli kompilátora sa o tom nič nepíše.

[peterple]

veľmi divné. Až priam štandartu odporujúce. Ten hovorí že v prípade že sa porovnáva signed a unsigned tak sa signed pretypuje na unsigned. Takže 5>2 musí platiť za každých okolností.

[maskrtnik01]

tak sa signed pretypuje na unsigned

A čo to spraví so znamienkom? Povedzme -5 > 2?

[niki31]

No je to divné, doteraz som sa stým nikde nestretol.
Vždy sa porovnávalo bez ohľadu na typ premennej a fungovalo to. V c to nefunguje a hľadať furt takéto chyby, to je zážitok.
Už som si aj začal písať zoznam podobných vecí, lebo ich je tam viac.

[peterple]

Niki: tým som chcel povedať že 5>2 by malo platiť aj v tvojom kompilátore. To že sa ti zdá že to neplatí znamená že si niečo prehliadol.

maskrtnik:
so znamienkom to neurobí nič. pretypovanie nič nemení len hovorí kompilátoru že pre túto chvíľu sa na tento kus pamäte pozeraj ako na celé číslo bez znamienka. To znamená že ak tam bude číslo -5 tak sa mu to bude zdať ako UINT_MAX-5+1

[maskrtnik01]

Toto som chcel vedieť. Či to vynuluje, obráti polaritu na kladnú......alebo to znamienko proste zoberie ako MSB uint-u.

[niki31]

Laboroval som s tým dva dni a nepodarilo sa mi zistiť prečo to robí. Nakoniec som musel v celom programe pomeniť typy premenných na unsigned.

[peterple]

V takýchto prípadoch kuknem na vygenerovaný asm a zvyčajne mám o chvíľu jasno.

[niki31]

To je sice pravda ale nič to na veci nemení. Je nemysliteľné laborovať s každou blbosťou pol dňa a zvlášť, ak sa v programe nachádza tisíckrát.
Skôr by ma zaujímalo či to nejde nejako prenastaviť alebo čo.

[maskrtnik01]

V takýchto prípadoch kuknem na vygenerovaný asm a zvyčajne mám o chvíľu jasno.

Ak asm rozumiete - nie každý to vie čítať a chápať.

[peterple]

Čo chceš prenastaviť? Normu ako pracujú kompilátory? Stále nejak moc neverím že ten test 5>2 bol false. Inak dnes každý slušný kompiler na takú konštrukciu hodí varovanie. A keď som s C začal tak som rýchlo zistil že varovania sa nevyplatí brať na ľahkú váhu. Keď sa niekomu C nepáči, tak tu má dnes mraky jazykov kde je cestička umetená. Java má všetko signed. Javascript má double, a tak podobne. Ale vždy je niečo za niečo. Za bezstarostný život sa platí. Cckar navyše píšuci pre MCU by mal vedieť ako a prečo to vo vnútri tak funguje.

[pocitujlasku]

maskrtnik: ak niekto programuje mcu v C, tak sa poklada za normalne, ze vie aspon trocha asm, lebo potom vie co sa deje vnutri

[Andy99]

Uz dlhsie sledujem tuto temu a neda mi to. Chapem, ze vysledok moze byt rozdielny ci uz vzavislosti od pouzitych typov premennych alebo aj nastavenia kompilatora. Ale zaujimalo by ma, ci by si nemohol ukazat cast toho kodu, ktora robi spominane problemy. S tym, ze tam bude vidiet definicia, inicializacia, pouzitie ako aj porovnanie danych premennych.

[maskrtnik01]

maskrtnik: ak niekto programuje mcu v C, tak sa poklada za normalne, ze vie aspon trocha asm, lebo potom vie co sa deje vnutri

Tak aritmetiku od skoku ešte rozoznám. Ale čo arduinisti napríklad? Pre nich je PORTB |= (1 << 4) cryptotext.

[pocitujlasku]

Presne na to narazam. Arduino sam dost intenzivne vyuzivam lebo nemam casu navyse a podstatne mi to ulahcuje ked robim rozne blbosti domov. Ale oni skoncili, ked napr. nalepia viac kniznic, pricom niektore z nich pouzivaju rovnake prerusenie, alebo port a program zrazu nefunguje ako ma. Ja si to vtedy viem fixnut, lebo poznam strukturu atmelu, co-to som uz robil jak v asm, tak C.
Je to podobne, ako ked niekto, kto vie poskladat PC sa vyhlasi za odbornika. Ale netusi, ze existuje nejaky bios/uefi, netusi, ze sa tam riesia nejake IRQ (schvalne, komu tato skratka este nieco povie), nevie ako komunikuju spolu zariadenia, nevie nastavit frekvenciu pamate, nasobic... Ja mam za sebou niekolko stovak poskladanych pc, zacinal som v dobe win98, w2k, kde sa este obcas co-to muselo nastavovat rucne, takze mam prehlad aj o tom, ako funguje vnutri pocitac.
Ked sa tak nad tym zamyslim, ja cokolvek som skusal, tak vzdy som skoncil na tom, ze som po nociach studoval ako to vlastne funguje, a na zaklade toho mi bolo hned jasne na co si dat pozor a kde su pripadne obmedzenia.

[niki31]

Po veľkom hľadaní na nete som zistil, že C všeobecne nevie porovnávať signed a unsigned. Rozoberali to už na viacerých fórach. Celkom názorne to je popísané na stackoverflow.

https://stackoverflow.com/questions/2084949/comparison-operation-on-unsigned-and-signed-integers

Predtým som to nemohol nájsť lebo som nevedel ako problém správne pomenovať. Ja programujem 99% vecí v assembleri, takže nemám problém to obísť alebo vyriešiť inak. Samozrejme sa to dá v C riešiť pretypovaním a pod. ale o to nejde. Je skrátka zarážajúce že v manuáloch sa o tom striktne mlčí. Predsa je absurdné aby sa programátor škrabal poza uši po nociach, pri obyčajnom elementárnom porovnávaní. Od toho sú predsa manuály, príručky a učebnice, nie?
Keby som vopred o tomto probléme vedel, mohol som si ušetriť fúru času.

[martin knocik]

V manualoch sa o tom nemlci. ak si precitas knihu Ucebnica jazyka C od Herouta, tak tam najdes celu kapitolu venovanu konverzii datovych typov. a implicitn0mu (skrytemu, automatickemu) pretypovaniu.

Problemom je rôzne správanie rôznych kompilatorov. GCC pre velke x86 pri operacia signed s unsigned skor pretypuje na vasi datovy typ, kompilator od Texas Instruments v COde composeri śetrí pamat a vysledkom su casto pretecenia. (ten vypise len warningy).

Predsa je absurdné aby sa programátor škrabal poza uši po nociach, pri obyčajnom elementárnom porovnávaní. Od toho sú predsa manuály, príručky a učebnice, nie?
Keby som vopred o tomto probléme vedel, mohol som si ušetriť fúru času.

Popis práce programátora Tiež som sa s tým natrápil ked som na problem s prototypovaním narazil prvý krát.