ceckovy kviz
spam na nagano.cz
spam na nagano.cz
Úterý Září 5 17:52:33 CEST 2023
Podivejte se na platformio.
L.
Sent from MailDroid
-----Original Message-----
From: "Martin Záruba" <swz na volny.cz>
To: hw-list na list.hw.cz
Sent: út, 05 zář 2023 17:48
Subject: Re: ceckovy kviz
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/d2d9f2d1/attachment.htm>
Další informace o konferenci Hw-list