ceckovy kviz

Martin Záruba swz na volny.cz
Úterý Září 5 17:47:52 CEST 2023 

Dík za názory, mnohé jsou zajímavé a pro mě určitě podnětné.

Protože pro to Arduino musím něco (ne úplně jednoduchého) usmolit, 
existuje nějaká možnost:

1) Donutit ArduinoIde, aby hlásil ty překlepy s chybějícím rovnítkem v 
if a asi i mnohé další

2) Použít něco lepšího pro Arduino

Mě třeba pije krev, že pokud mám zapnutý monitor na seriovém portu 
arduina a chci nahrát nový program, musím ho vypnout, nahrát, zapnout. 
Nechápu, že povel pro download ho přechodně nevypíná.

Martin Záruba

Dne 5.9.2023 v 16:48 Pavel Hudeček napsal(a):
> No asi tak nějak:-)
> Jazyky jsou prostě více či méně odlišné a proto je potřeba více či 
> méně odlišně uvažovat při jejich používání. A zrovna Pascal vs C jsou 
> na té škále odlišnosti tak daleko, že lidé musí mít jiné psychologické 
> vlastnosti, aby v nich byli ochotni dobrovolně psát.
>
> Další věc je, že prasit se dá v každém jazyku. C a z něj odvozené 
> jazyky jsou na vastní syntaxi úsporné, což zas dává víc prostoru na 
> délky názvů a komentáře, které narozdíl od syntaxe jazyka programátor 
> ovlivní. A to má pak velký vliv na čitelnost později.
>
> Ale s tím if = je zajímavé, že jsem věděl, že to vede k warningu, ale 
> nenapadlo mě, že to bude "suggest parentheses", warning který často 
> vypínám, protože jinak otravuje při banálních kombinacích and/or, 
> které mi bez závorek přijdou přehlednější. Já mám prostě závorky = 
> pozor je to složitější.
>
> PH
>
> Dne 05.09.2023 v 16:06 Jindroush napsal(a):
>> Dobry den,
>> vychazite odjinud a ohybate si to ke svym lety nabytym navykum. 
>> Kazdy, kdo programuje v C, vase vytky nebude prakticky chapat, 
>> protoze nic z toho neni 'zvykem' delat tak, jak delate. Tj. kazdy C 
>> programator by mel vedet, jake typy kdy pouzit a to, jak vypada C 
>> retezec. Tj. na ukladani osmibitove hodnoty neupouziju char, ale bud 
>> 'moderni C99' uint8_t ze stdint.h, nebo si provedu typedef unsigned 
>> char byte, nebo v nejhorsim budu porad pouzivat unsigned char (s 
>> riziky neprenositelnosti)
>>
>> Jinak samozrejme zapis
>> if( A=B ) {} je zcela legalni a kazdy zdravy kompilator s obvykle 
>> 'rozumnymi' (nikoli nutne vychozimi) nastavenimi (-Wall) vypise neco 
>> jako toto:
>> <source>:7:10: warning: suggest parentheses around assignment used as 
>> truth value [-Wparentheses]
>>     7 |     if( a=b )
>>       |         ~^~
>>
>> Na C je uzasne to, ze je vsude, existuje pro nej mraky kodu, 
>> knihoven, kompilatoru, dalsich naradi. Tomuhle se nejspis zadny jiny 
>> jazyk nemuze rovnat.
>>
>> Ja u Pascalu vzdy trpel a nikdy jsem nechapal jeho lokalni 
>> popularitu, vzdy jsem vnimal jen sama omezeni a uzvanenost a zadne 
>> prinosy v porovnani s C.
>>
>> J.
>>
>> On 05.09.2023 15:24, Martin Záruba wrote:
>>>
>>> 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 bywww.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/82dfa24f/attachment.htm>

Další informace o konferenci Hw-list