ceckovy kviz

Úterý Září 5 16:09:24 CEST 2023

Pane Záruba,
Jsem na tom úplně stejně, mluvíte mi z duše.... Já když píšu program pro
Arduino, vymyslím vždycky příkaz v Pascalu a pak se podívám do reference,
jak to v tom C vlastně napsat

Dne út 5. zář 2023 15:24 uživatel Martin Záruba <swz na volny.cz> napsal:

> Když vidím, s čím tu všichni bojujete, tak mám pocit, že jsem dělal dobře,
> že jsem se bránil jazyku C v jakékoli podobě. Nakonec mě stejně dostihl v
> podobě nutnosti udělat program pro Arduino.
>
> Uznávám, že zápis je velmi úsporný. Například
>
> i++;
>
> nenapíšete asi v žádném jiném jazyku úsporněji. Na druhou stranu....
> Použili jste někdy někdo zápis
>
> if (A=B) {};
>
> a přitom je syntakticky správně. Kompilátor pochopitelně nic nehlásí a já
> nemohl pochopit, proč program nefunguje. Holt zvyk z Pascalu, že tak je to
> dobře.
>
> Nebo třeba to, že typ char obsahuje znaménko a tudíž porovnání nefunguje.
> Nebo že v řetězci nesmí být 0x00.
>
> V krátkém, jednoduchém programu je asi to, že můžete porovnat cokoli s
> čímkoli (když víte jak) a konverzi typů většinou neřešíte, vlastnost, která
> zkracuje zápis. Ale zásadně zvyšuje pravděpodobnost chyby. Já vím, Pascal
> je užvaněný a begin-end asi je opravdu horší, než {}, ale úžasné je, že
> pokud chcete přiřadit k sobě něco, co k sobě nepatří, musíte to zcela jasně
> říct, jinak je to syntaktická chyba.
>
> Nechci vyvolat flame, ale co je na C tak úžasné? (Fakt mě to pouze zajímá,
> protože na to nemohu přijít)
>
> Martin Záruba
>
> Dne 5.9.2023 v 10:51 Pavel Hudeček napsal(a):
>
> Myslím, že je lepší mít program funkční proto, že vím co dělám, ale i
> přesto v něm zbytečně nevymejšlet koniny:-)
> Jestli se má zobrazit řádek textu, tak nejspíš stejně bude potřeba, aby
> někdo měl čas si ho přečíst, takže není důvod šetřit nějaké nanosekundy.
> Tzn. dal bych tam normální funkci. A ať si s ní optimizér pak udělá co
> chce.
>
> PH
>
> Dne 05.09.2023 v 8:46 Jan Waclawek napsal(a):
>
> Je pravda, ze to makro je v tomto pripade nerozumne, a ta funkcia je
> rozumnejsie riesenie.
>
> (Na druhej strane, ta posadnutost pravovernych C++-karov tym const...
> zhodou okolnosti v tomto konkretnom programe ten retazec konstruujem...)
>
> Ale neviem, ako by mi to malo dojst. Aj som to skusil, gcc s -Wall a
> -Wpedantic nic nevyhlasil. A ani nema dovod. Ale ano, zakryje to problem.
>
> Ano, cely problem je v tom, ze strlen() ma navratovy typ unsigned
> (spominany size_t), a -strlen() je teda uplne rovnako unsigned (dost dlho
> som hladal v C99 kde to presne je, ze vysledok vyrazu ma ten isty typ ako
> su konvertovane typy operandov, lebo to nie je v kapitole Expressions kde
> by som to cakal, ale v kapitole 6.3.1.8 Usual arithmetic conversions).
> Inaksie povedane, ak je retazec dlhy povedzme 3, tak -strlen je u
> 32-bitoveho mcu 0xFFFFFFFD.
>
> Cize v makre to ((xx) < 0) je vzdy false a optimalizator to true vetvu
> vyhodi.
>
> Funkcia to zachrani tym, ze pri volani sa ta unsigned value skonvertuje na
> signed. To je sice, prisne vzate, implementation defined, ale u twos
> complement (co je defacto standard a od C23 bude povinne) to dopadne dobre
> :-).
>
> A teraz, co je lepsie? Mat zhodou okolnosti funkcny program nad ktorym by
> ma ani nenapadlo sa zamysliet; alebo sa na nefunkcnom programe naucit, ze
> size_t je unsigned a miesanie unsigned so signed zvykne dopadnut zle,
> takze sa tomu treba vyhybat?
>
> wek
>
>
> ----- Original Message ---------------
>
> To je jednoduché - vy pravověrní C-čkaři pouľíváte makra i tam, kde se
> to vůbec nehodí. Kdybyste pouľívali raději statické inline funkce jako
> static inline void LcdBXPrint (int xx, int yy, const char * s) {
>     LcdBPrint( (((xx) < 0) ? LCD_XMAX : 0) + (xx) * FONT_XSIZE, (yy) *
> FONT_YSIZE, s);
> }
> pak vám dojde, ľe argument xx nemůľe být unsigned (resp. size_t), pokud
> má vyhodnocen jako záporný a problém zázračně zmizí.
>
> Mrazík
>
> On 03. 09. 23 23:00, Jan Waclawek wrote:
>
> Mam funkciu
>
>     void LcdBPrint(uint32_t x, uint32_t y, char * s);
>
> ktora vypise retazec na LCD s rozmermi LCD_XMAX, LCD_YMAX na poziciu x, y
> pixelov od laveho horneho rohu.
>
> Vypisuje to neproporcionalnym fontom s rozmermi znaku FONT_XSIZE,
> FONT_YSIZE.
>
> Z nejakych dovodov chcem vypisovat retazce zarovnane jeden za druhym; ale
> niekedy chcem vypisovat retazce pod seba zarovnane na pravy okraj. To prve
> vedie na volania typu:
>
>     LcdBPrint(doteraz_napocitane_znaky_od_laveho_okraja * FONT_XSIZE,
> riadok
> * FONT_YSIZE , retazec);
>
> a to druhe na
>
>     LcdBPrint(LCD_XMAX - strlen(retazec) * FONT_XSIZE, riadok *
> FONT_YSIZE,
> retazec);
>    Vravim si, takto je to dost neprehladne, a pritom sa tam to nasobenie
> furt
> opakuje. A tiez, tie dve veci su navzajom dostatocne podobne. Tak co keby
> ze si napisem makro, do ktoreho bud zadam kladne x, co znamena pocet
> znakov od laveho okraja, alebo zaporne x, co znamena pocet znakov od
> praveho okraja:
>
>     #define LcdBXPrint(xx, yy, s) LcdBPrint( (((xx) < 0) ? LCD_XMAX : 0) +
> (xx) * FONT_XSIZE, (yy) * FONT_YSIZE, s)
>
> Ked pisem zlava, tak mam
>
>     LcdBXPrint(doteraz_napocitane_znaky_od_laveho_okraja, riadok,
> retazec);
>
> co je pekne, prehladne, a funguje. Ale ked pisem zlava, tak
>
>     LcdBXPrint(-sizeof(retazec), riadok, retazec);
>
> nefunguje.
>
> Preco?
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
>
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20230905/92de7b3b/attachment.htm>