<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Tak to ja pujdu asi trochu proti
proudu. <br>
</div>
<div class="moz-cite-prefix">Dlouhou dobu jsem se branil Ccku a
zpetne to vyhodnocuju jako obrovskou chybu. Veci, ktere popisujete
jsou dane spis neznalosti, nez chybou jazyka. Pokud jste psal pro
Arduino, tak jste nejspis pouzil C++ a ne C. Kompilator hlasi
spoustu chyb, ale Arduino IDE ma vypnute varovani, takze o nich
nevite. Napriklad na ten (A=B) upozorni urcite. Datovy typ char
neni v jazyce specifikovan, takze je implementacne zavisle, jestli
je signed, nebo unsigned, ale pri porovnavani opet kompilator
dokaze vypsat varovani, ze porovnavate znamenkovy typ s
neznamenkovym. Pokud si zapnete, ze se varovani maji brat jako
chyby, tak to prehlednout ani nemuzete. C++ je navic v porovnavani
podstatne striktnejsi, nez "obycejne" Ccko, ale pokud mu reknete
C-stylem pretypovani, tak kompilator nema co kontrolovat. Dalsi
vec pak je, ze muzete pouzit lintery, ktere maji opravdove
vyvojove prostredi primo v sobe, nebo se daji doplnit jako zasuvne
moduly. Napr. cppcheck ve VSC, nebo clang-tidy v Clion - osobne
povazuji clang-tidy za podstatne lepsi, nez cppcheck - dokaze
totiz napriklad upozornit na to, ze se nejaka metoda da udelat
const, nebo doporuci pouziti iteratoru kde to jde namisto
"hloupeho" for... indexovani. <br>
</div>
<div class="moz-cite-prefix">Pro me je pouziti C++ v
mikrokontrolerech fakt dost podstatny skok v efektivite
programovani. Vzdycky rikam: Pokud chcete videt vyhody C++ a
objektoveho programovani, tak si vezmete NTC termistor, DS18B20 a
433MHz senzor teploty a zkuste napsat pro tyhle 3 cidla program,
ktery bude vypisovat namerene teploty na seriovy port, pricemz
nevite, kolik bude kterych cidel pripojenych. A az to budete mit
hotove, tak zkuste ten kod rizsirit o pripojeni nejakeho teplotni
cidla pres I2C, nebo treba nejaky IP teplomer. Na tomhle
primitivnim prikladu se da ukazat pouziti objektoveho
programovani, dedicnost, sablonovani (template) C++. A muze to
fungovat i na beznem "nano" Arduinu (alespon do te doby, nez
zacnete pouzivat prilis vyskou abstrakci). A az to budete mit
hotove, tak zmente procesor treba na STM32, nebo ESP32, nebo
SAMD21...</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Pavel Brychta</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Dne 05. 09. 23 v 15:24 Martin Záruba
napsal(a):<br>
</div>
<blockquote type="cite"
cite="mid:3135ca3a-90cb-4e7a-d5a7-3e7e6735c1f7@volny.cz">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p><font face="Arial">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.</font></p>
<p><font face="Arial">Uznávám, že zápis je velmi úsporný.
Například <br>
</font></p>
<p><font face="Arial">i++; <br>
</font></p>
<p><font face="Arial">nenapíšete asi v žádném jiném jazyku
úsporněji. Na druhou stranu.... Použili jste někdy někdo zápis
<br>
</font></p>
<p><font face="Arial">if (A=B) {};</font></p>
<p><font face="Arial">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.</font></p>
<p><font face="Arial">Nebo třeba to, že typ char obsahuje znaménko
a tudíž porovnání nefunguje. Nebo že v řetězci nesmí být 0x00.<br>
</font></p>
<p><font face="Arial">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.</font></p>
<p>Nechci vyvolat flame, ale co je na C tak úžasné? (Fakt mě to
pouze zajímá, protože na to nemohu přijít)<br>
</p>
<pre class="moz-signature" cols="72">Martin Záruba</pre>
<div class="moz-cite-prefix">Dne 5.9.2023 v 10:51 Pavel Hudeček
napsal(a):<br>
</div>
<blockquote type="cite"
cite="mid:7a11485d-45f5-a235-e27f-374348b33c3f@seznam.cz">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:-) <br>
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. <br>
<br>
PH <br>
<br>
Dne 05.09.2023 v 8:46 Jan Waclawek napsal(a): <br>
<blockquote type="cite">Je pravda, ze to makro je v tomto
pripade nerozumne, a ta funkcia je <br>
rozumnejsie riesenie. <br>
<br>
(Na druhej strane, ta posadnutost pravovernych C++-karov tym
const... <br>
zhodou okolnosti v tomto konkretnom programe ten retazec
konstruujem...) <br>
<br>
Ale neviem, ako by mi to malo dojst. Aj som to skusil, gcc s
-Wall a <br>
-Wpedantic nic nevyhlasil. A ani nema dovod. Ale ano, zakryje
to problem. <br>
<br>
Ano, cely problem je v tom, ze strlen() ma navratovy typ
unsigned <br>
(spominany size_t), a -strlen() je teda uplne rovnako unsigned
(dost dlho <br>
som hladal v C99 kde to presne je, ze vysledok vyrazu ma ten
isty typ ako <br>
su konvertovane typy operandov, lebo to nie je v kapitole
Expressions kde <br>
by som to cakal, ale v kapitole 6.3.1.8 Usual arithmetic
conversions). <br>
Inaksie povedane, ak je retazec dlhy povedzme 3, tak -strlen
je u <br>
32-bitoveho mcu 0xFFFFFFFD. <br>
<br>
Cize v makre to ((xx) < 0) je vzdy false a optimalizator to
true vetvu <br>
vyhodi. <br>
<br>
Funkcia to zachrani tym, ze pri volani sa ta unsigned value
skonvertuje na <br>
signed. To je sice, prisne vzate, implementation defined, ale
u twos <br>
complement (co je defacto standard a od C23 bude povinne) to
dopadne dobre <br>
:-). <br>
<br>
A teraz, co je lepsie? Mat zhodou okolnosti funkcny program
nad ktorym by <br>
ma ani nenapadlo sa zamysliet; alebo sa na nefunkcnom programe
naucit, ze <br>
size_t je unsigned a miesanie unsigned so signed zvykne
dopadnut zle, <br>
takze sa tomu treba vyhybat? <br>
<br>
wek <br>
<br>
<br>
----- Original Message --------------- <br>
<br>
To je jednoduché - vy pravověrní C-čkaři pouľíváte makra i
tam, kde se <br>
to vůbec nehodí. Kdybyste pouľívali raději statické inline
funkce jako <br>
static inline void LcdBXPrint (int xx, int yy, const char * s)
{ <br>
LcdBPrint( (((xx) < 0) ? LCD_XMAX : 0) + (xx) *
FONT_XSIZE, (yy) * <br>
FONT_YSIZE, s); <br>
} <br>
pak vám dojde, ľe argument xx nemůľe být unsigned (resp.
size_t), pokud <br>
má vyhodnocen jako záporný a problém zázračně zmizí. <br>
<br>
Mrazík <br>
<br>
On 03. 09. 23 23:00, Jan Waclawek wrote: <br>
<blockquote type="cite">Mam funkciu <br>
<br>
void LcdBPrint(uint32_t x, uint32_t y, char * s); <br>
<br>
ktora vypise retazec na LCD s rozmermi LCD_XMAX, LCD_YMAX na
poziciu x, y <br>
pixelov od laveho horneho rohu. <br>
<br>
Vypisuje to neproporcionalnym fontom s rozmermi znaku
FONT_XSIZE, <br>
FONT_YSIZE. <br>
<br>
Z nejakych dovodov chcem vypisovat retazce zarovnane jeden
za druhym; ale <br>
niekedy chcem vypisovat retazce pod seba zarovnane na pravy
okraj. To prve <br>
vedie na volania typu: <br>
<br>
LcdBPrint(doteraz_napocitane_znaky_od_laveho_okraja *
FONT_XSIZE, riadok <br>
* FONT_YSIZE , retazec); <br>
<br>
a to druhe na <br>
<br>
LcdBPrint(LCD_XMAX - strlen(retazec) * FONT_XSIZE,
riadok * FONT_YSIZE, <br>
retazec); <br>
Vravim si, takto je to dost neprehladne, a pritom sa tam
to nasobenie furt <br>
opakuje. A tiez, tie dve veci su navzajom dostatocne
podobne. Tak co keby <br>
ze si napisem makro, do ktoreho bud zadam kladne x, co
znamena pocet <br>
znakov od laveho okraja, alebo zaporne x, co znamena pocet
znakov od <br>
praveho okraja: <br>
<br>
#define LcdBXPrint(xx, yy, s) LcdBPrint( (((xx) < 0)
? LCD_XMAX : 0) + <br>
(xx) * FONT_XSIZE, (yy) * FONT_YSIZE, s) <br>
<br>
Ked pisem zlava, tak mam <br>
<br>
LcdBXPrint(doteraz_napocitane_znaky_od_laveho_okraja,
riadok, retazec); <br>
<br>
co je pekne, prehladne, a funguje. Ale ked pisem zlava, tak
<br>
<br>
LcdBXPrint(-sizeof(retazec), riadok, retazec); <br>
<br>
nefunguje. <br>
<br>
Preco? <br>
</blockquote>
</blockquote>
_______________________________________________ <br>
HW-list mailing list - sponsored by <a
class="moz-txt-link-abbreviated" href="http://www.HW.cz"
moz-do-not-send="true">www.HW.cz</a> <br>
<a class="moz-txt-link-abbreviated moz-txt-link-freetext"
href="mailto:Hw-list@list.hw.cz" moz-do-not-send="true">Hw-list@list.hw.cz</a>
<br>
<a class="moz-txt-link-freetext"
href="http://list.hw.cz/mailman/listinfo/hw-list"
moz-do-not-send="true">http://list.hw.cz/mailman/listinfo/hw-list</a>
<br>
</blockquote>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
HW-list mailing list - sponsored by <a class="moz-txt-link-abbreviated" href="http://www.HW.cz">www.HW.cz</a>
<a class="moz-txt-link-abbreviated" href="mailto:Hw-list@list.hw.cz">Hw-list@list.hw.cz</a>
<a class="moz-txt-link-freetext" href="http://list.hw.cz/mailman/listinfo/hw-list">http://list.hw.cz/mailman/listinfo/hw-list</a>
</pre>
</blockquote>
<p><br>
</p>
<pre class="moz-signature" cols="72">--
Pavel Brychta
<a class="moz-txt-link-freetext" href="http://www.xPablo.cz">http://www.xPablo.cz</a></pre>
</body>
</html>