<div dir="ltr">Zdravím, <div><br></div><div><a href="https://cs.wikipedia.org/wiki/C_(programovac%C3%AD_jazyk)">https://cs.wikipedia.org/wiki/C_(programovac%C3%AD_jazyk)</a> <br></div><div><br></div><div>Osobně jsem také něco v C spáchal, ale tento jazyk mi nijak k srdci nepřirostl. Jsem jen občasný programátor, a zápis v jazyku C se mi těžko čte. Chápu, že je velmi úsporný a pokud jej někdo používá každý den, jistě se rychle orientuje. Pro mě platí, co jsem četl v jedné příručce " Zápis programu mnohem častěji čtete, než píšete. Prot by měl být program dobře čitelný".</div><div><br clear="all"><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">S pozdravem<br>ing. Pavel Poucha<br>jednatel<br><a href="mailto:pavel.poucha@papouch.com" target="_blank">pavel.poucha@papouch.com</a><br>Tel. +420 777 232 485<br><br>Papouch s.r.o. - vývoj<br>Papouch store s.r.o. - obchod</div><div>Papouch production s.r.o. - výroba</div><div>Workmonitor s.r.o. - monitorování výroby</div><div dir="ltr"><br></div><div dir="ltr">Máte-li chuť, navštivte naše stránky <a href="http://www.papouch.com/" target="_blank">http://www.papouch.com/</a></div></div></div></div></div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">út 5. 9. 2023 v 15:29 odesílatel ajtservis <<a href="mailto:info@ajtservis.cz">info@ajtservis.cz</a>> napsal:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">jsem "ne_ceckar", a znam jen asembler pro x51 a pozdeji deplphi/pascal.<br>
cecko je podle me evolucne prvni nadstavba nad asemblerem a pak uz se to <br>
vezlo ? :-).<br>
t.<br>
<br>
Dne 05.09.2023 v 15:24 Martin Záruba napsal(a):<br>
> Když vidím, s čím tu všichni bojujete, tak mám pocit, že jsem dělal <br>
> dobře, že jsem se bránil jazyku C v jakékoli podobě. Nakonec mě stejně <br>
> dostihl v podobě nutnosti udělat program pro Arduino.<br>
> <br>
> Uznávám, že zápis je velmi úsporný. Například<br>
> <br>
> i++;<br>
> <br>
> nenapíšete asi v žádném jiném jazyku úsporněji. Na druhou stranu.... <br>
> Použili jste někdy někdo zápis<br>
> <br>
> if (A=B) {};<br>
> <br>
> a přitom je syntakticky správně. Kompilátor pochopitelně nic nehlásí a <br>
> já nemohl pochopit, proč program nefunguje. Holt zvyk z Pascalu, že tak <br>
> je to dobře.<br>
> <br>
> Nebo třeba to, že typ char obsahuje znaménko a tudíž porovnání <br>
> nefunguje. Nebo že v řetězci nesmí být 0x00.<br>
> <br>
> V krátkém, jednoduchém programu je asi to, že můžete porovnat cokoli s <br>
> čímkoli (když víte jak) a konverzi typů většinou neřešíte, vlastnost, <br>
> která zkracuje zápis. Ale zásadně zvyšuje pravděpodobnost chyby. Já vím, <br>
> Pascal je užvaněný a begin-end asi je opravdu horší, než {}, ale úžasné <br>
> je, že pokud chcete přiřadit k sobě něco, co k sobě nepatří, musíte to <br>
> zcela jasně říct, jinak je to syntaktická chyba.<br>
> <br>
> Nechci vyvolat flame, ale co je na C tak úžasné? (Fakt mě to pouze <br>
> zajímá, protože na to nemohu přijít)<br>
> <br>
> Martin Záruba<br>
> <br>
> Dne 5.9.2023 v 10:51 Pavel Hudeček napsal(a):<br>
>> Myslím, že je lepší mít program funkční proto, že vím co dělám, ale i <br>
>> přesto v něm zbytečně nevymejšlet koniny:-)<br>
>> Jestli se má zobrazit řádek textu, tak nejspíš stejně bude potřeba, <br>
>> aby někdo měl čas si ho přečíst, takže není důvod šetřit nějaké <br>
>> nanosekundy. Tzn. dal bych tam normální funkci. A ať si s ní optimizér <br>
>> pak udělá co chce.<br>
>><br>
>> PH<br>
>><br>
>> Dne 05.09.2023 v 8:46 Jan Waclawek napsal(a):<br>
>>> 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 <br>
>>> 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 <br>
>>> dlho<br>
>>> som hladal v C99 kde to presne je, ze vysledok vyrazu ma ten isty typ <br>
>>> ako<br>
>>> su konvertovane typy operandov, lebo to nie je v kapitole Expressions <br>
>>> 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 <br>
>>> 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 <br>
>>> dobre<br>
>>> :-).<br>
>>><br>
>>> A teraz, co je lepsie? Mat zhodou okolnosti funkcny program nad <br>
>>> ktorym by<br>
>>> ma ani nenapadlo sa zamysliet; alebo sa na nefunkcnom programe <br>
>>> 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>
>>>> 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 <br>
>>>> 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 <br>
>>>> druhym; ale<br>
>>>> niekedy chcem vypisovat retazce pod seba zarovnane na pravy okraj. <br>
>>>> To prve<br>
>>>> vedie na volania typu:<br>
>>>><br>
>>>>     LcdBPrint(doteraz_napocitane_znaky_od_laveho_okraja * <br>
>>>> FONT_XSIZE, riadok<br>
>>>> * FONT_YSIZE , retazec);<br>
>>>><br>
>>>> a to druhe na<br>
>>>><br>
>>>>     LcdBPrint(LCD_XMAX - strlen(retazec) * FONT_XSIZE, riadok * <br>
>>>> FONT_YSIZE,<br>
>>>> retazec);<br>
>>>>    Vravim si, takto je to dost neprehladne, a pritom sa tam to <br>
>>>> nasobenie furt<br>
>>>> opakuje. A tiez, tie dve veci su navzajom dostatocne podobne. Tak co <br>
>>>> 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 <br>
>>>> : 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, <br>
>>>> 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>
>> _______________________________________________<br>
>> HW-list mailing list  -  sponsored by <a href="http://www.HW.cz" rel="noreferrer" target="_blank">www.HW.cz</a><br>
>> <a href="mailto:Hw-list@list.hw.cz" target="_blank">Hw-list@list.hw.cz</a><br>
>> <a href="http://list.hw.cz/mailman/listinfo/hw-list" rel="noreferrer" target="_blank">http://list.hw.cz/mailman/listinfo/hw-list</a><br>
> <br>
> _______________________________________________<br>
> HW-list mailing list  -  sponsored by <a href="http://www.HW.cz" rel="noreferrer" target="_blank">www.HW.cz</a><br>
> <a href="mailto:Hw-list@list.hw.cz" target="_blank">Hw-list@list.hw.cz</a><br>
> <a href="http://list.hw.cz/mailman/listinfo/hw-list" rel="noreferrer" target="_blank">http://list.hw.cz/mailman/listinfo/hw-list</a><br>
> <br>
<br>
-- <br>
AJT SERVIS s.r.o.<br>
<br>
Oparno 65<br>
Lovosice<br>
410 02<br>
<br>
ICO:04203879<br>
DIC:CZ04203879<br>
<br>
email:<br>
<a href="mailto:info@ajtservis.cz" target="_blank">info@ajtservis.cz</a><br>
<br>
tel.<br>
777 584 558<br>
_______________________________________________<br>
HW-list mailing list  -  sponsored by <a href="http://www.HW.cz" rel="noreferrer" target="_blank">www.HW.cz</a><br>
<a href="mailto:Hw-list@list.hw.cz" target="_blank">Hw-list@list.hw.cz</a><br>
<a href="http://list.hw.cz/mailman/listinfo/hw-list" rel="noreferrer" target="_blank">http://list.hw.cz/mailman/listinfo/hw-list</a><br>
<br>
</blockquote></div>