Re: Chyba v C - velmi podivné chování

Turbyho turbyho na gmail.com
Středa Duben 22 08:56:51 CEST 2020 

https://microchipdeveloper.com/faq:16

t

> 22. 4. 2020 v 8:28, Zuffa Jan <ZuffaJ na cgc.sk>:
> 
> 
> Army neprogramujem,
> len tie malinke PICka. ARM asi nie je dobry priklad.
> Take male picko ma 2kB FLASH a 128B RAM
>  
> j.
>  
> From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of Tomáš Hamouz
> Sent: 22. apríla 2020 8:17
> To: HW-news
> Subject: Re: Chyba v C - velmi podivné chování
>  
> To je standardně zažitý omyl, který se traduje z dob kdy překladače příliš neoptimalizovaly.
> Současné překladače dělají hodně dobrou práci.
> 
> Pokud mohu mluvit z vlastní zkušenosti a pokud je možno ARM považovat za mikročip, tak mě naopak překvapuje 
> kde všude překladač (GCC) inlinuje, a to i v případě že mám optimalizaci nastavenou na Debug.
> 
> Nehledě na to že lze použít  __attribute__((always_inline)).
> 
> Tomáš 
> 
> 
> > Ako obcasny programator si dovolim povedat ze rozbijanie do funkcii je super vec a
> > a sprehladnuje kod, ale vo svete mikrocipov mi to moc nesedi. Tam to intuitivne laka
> > k efektivnejsiemu kodu aj co sa tyka zbytocnych volani. Predsa je to rezia navyse
> 
> > j.
> 
> > -----Original Message-----
> > From: Hw-list [mailto:hw-list-bounces na list.hw.cz] On Behalf Of Jan Waclawek
> > Sent: 21. apríla 2020 22:07
> > To: HW-news
> > Subject: Re: Chyba v C - velmi podivné chování
> 
> > Ja som po urcitom case prisiel na to, ze privela pismeniek je
> > rovnako zle ako primalo. Samozrejme je tazke utrafit nejaky zlaty
> > stred; a co je este tazsie, je utrafit tie spravne pismenka a ich
> > spravnu polohu tak, aby to pomohlo mojmu buducemu ja prip. niekomu inemu.
> 
> > A tie "coding standards" typu hlavicka funkcie a rozbijanie do
> > funkcii su podla mna vo vacsine pripadov kontraproduktivne (to je
> > samozrejme slovo do bitky, rovnako zbytocnej ako su napr. diskusie o
> > zatvorkovaco-zalamovacich styloch (zbytocnej, pretoze sa ma pouzivat len a len One True, samzorejme)).
> 
> > V tomto konkretnom pripade by som ja asi pouzil tu pomocnu
> > premennu; ale co je podla mna ovela dolezitejsie je, ze ak by som aj
> > zachoval ten vyraz tak ako je, rozbil by som ho do jednotlivych
> > riadkov a kazdy riadok by som okomentoval; vratane toho finalneho porovnania s cislom 3.
> 
> > wek
> 
> 
> 
> > ----- Original Message ---------------
> 
> > preco chcete setrit pismenkami?
> 
> > podla mna je dolezitejsie aby to bolo lahko citatelne komukolvek.
> 
> > lebo ak chcete mat portovatelny kod tak musi byt trocha odolny,
> > taktiez pri testovani ked potrebujete vediet ktory vyraz ma aku hodnotu, alebo pre logovanie.
> 
> > je kopec rieseni ktore na prvy pohlad zjednodusuju program ale
> > nakoniec sa mozu skaredo vypomstit
> 
> 
> >>>>A bylo by docela zajímavé se podívat jak  se liší zkompilovaný kód v obou pøípadech.
> 
> >>>>Myslím že by tam velké rozdíly nebyly.
> 
> > to by aj mna by zaujimalo :)
> 
> 
> > On 21. 4. 2020 12:39, Pavel Hudecek wrote:
> 
> >> No jo, ale to pak na místì použití není vidìt, jaké že ty podmínky 
> >> jsou. Pøedpokládám, že funkce bude dle firemních pravidel definována 
> >> v nìjakém externím souboru. Nedej bože, když takových sad podmínek 
> >> bude víc. To pak budou názvy tìch funkcí tak dlouhé, že urèitì poruší 
> >> nìjaké délkové pravidlo, ohlednì délky øádku:-)
> 
> >> Normálnì bych pro zvýšení pøehlednosti dal mezery okolo + (což jsem 
> >> ale pro zabránìní zalomení v mailu vynechal). Uvažoval bych ještì o 
> >> další závorce okolo souètu.
> 
> >> Použití funkce pro mì pøehlednost jasnì snižuje:-) Navíc MIN_A_COUNT a 
> >> REMAING_COUNT jsou vyloženì matoucí názvy pro podmínky nesouvisející s 
> >> count:-) Jinak teda proti použití define nic nenamítám, bìžnì 
> >> používám, ale zas je to zbyteèná komplikace do ukázky typu kódu v mailu.
> 
> >> K èemu teda máme rùzné jazyky, když bychom nemohli využívat jejich výhod?
> 
> >> PH
> 
> >> *Od: *Tomáš Hamouz <mailto:tomas.hamouz na divesoft.com>
> 
> >> Myslím že lepší otázka zní, jak to napsat tak aby bylo na první pohled 
> >> jasné co daný výraz vyhodnocuje,
> >> bez ohledu na poèet písmenek.
> 
> >> Abych planì nekritizoval, nejspíš bych to udìlal takhle, ale protože 
> >> nevím úèel celé konstrukce,
> >> tak by bylo tøeba lepší zahrnout i porovnání s trijkou. Podmínku 
> >> malého poètu písmenek zcela zjevnì
> >> nesplòuju, ale to zcela zámìrnì, protže bych se v tom rád vyznal i po 
> >> nìkolika letech kdy jsem to nevidìl.
> 
> 
> >> #define   MIN_A_COUNT               2            // vyznam teto konstanty
> >> #define   REMAING_COUNT       12        // vyznam teto konstanty
> >> #define   MINIMAL_COND_COUNT   3        // vyznam teto konstanty
> 
> >> static inline int count_test_conditions(int a, int b, int x, int y)
> >> {
> >>     int count = 0;
> >>     if (a < MIN_A_COUNT) {++count;}        // oduvodneni teto podminky
> >>     if (a > b) {++count;}                  // oduvodneni teto podminky
> >>     if (x < y) {++count;}                  // oduvodneni teto podminky
> >>     if ((a%x) == REMAING_COUNT) {++count;} // oduvodneni teto podminky
> >>     if (b < y) {++count;}                  // oduvodneni teto podminky
> >>     return count;
> >> }
> 
> >> if (count_test_conditions(a, b, x, y) > 3) {
> >> }
> 
> 
> >> A bylo by docela zajímavé se podívat jak se liší zkompilovaný kód v 
> >> obou pøípadech.
> >> Myslím že by tam velké rozdíly nebyly.
> 
> 
> 
> >>       
> 
> >> Otázka tedy zní, jak ho upravit, aby prošel a pøibylo co nejménì 
> >> písmenek:-)
> 
> >> PH
> 
> >> *Od: *as5sgm na gmail.com <mailto:as5sgm na gmail.com>
> >> >>> If ((a<2)+(a>b)+(x<y)+(a%x==12)+(b<y) > 3) {
> >> Tento riadok kodu by nepresiel review a ani MISRA rules, vsade kde su 
> >> aspon dvaja vyvojari :)
> >> Miro
> 
> >> On 21. 4. 2020 10:37, Pavel Hudecek wrote:
> >> Vzhledem ke komutativnosti sèítání by poøadí mìlo bejt irelevantní, 
> >> kromì toho posledního >, ale to má nižší prioritu než +, takže se musí 
> >> vyhodnotit jako poslední.
> 
> >> No a že to nebude fungovat v jiných jazycích? To je snad normální. 
> >> Nebo všechny mají ++, printf, pointery jako Delphi, nepotøebují 
> >> deklarovat promìnné jako VB6, … ?
> 
> >> Pøíkazù je tam 0, takže omezení na max. jeden na øádek to taky 
> >> nepøekraèuje.
> 
> >> PH
> 
> >> *Od: *Michal Gregor <mailto:a2x1nptda8 na email.cz>
> >> Spravne se maji slozite podminky prevest do funkci. Plati zasada jeden
> >> radek jeden prikaz. A nespolehat se na interni "tajne" funkce
> >> compilatoru. Co kdyz to nekdo skopiruje do C++? Nebo do uplne jineho 
> >> jazyja.
> 
> 
> >> Dne 21.04.2020 v 8:46 Jan Waclawek napsal(a):
> >> > A nemohlo to byt skor o tom, ze v takychto vyrazoch
> >> >
> >> >>> If ((a<2)+(a>b)+(x<y)+(a%x==12)+(b<y) > 3) {
> >> >
> >> > nie je zarucene poradie vyhodnotenia pod-vyrazov, aj keby mali vedlajsie
> >> > efekty?
> >> >
> >> > wek
> >> >
> >> >
> >> > ----- Original Message ---------------
> >> >> Sa vam dvom do toho zamontujem, som nieco nasiel vo svojom archive, ale
> >> >> Ty si mimo podozreni :)
> >> >> Skor si ja pofajcim, ze uz kedy som daval do placu citat z normy, ktory
> >> >> si teraz dal aj Ty :-D
> >> >>
> >> >> https://list.hw.cz/pipermail/hw-list/2011-July/399004.html
> >> >>
> >> >> miro
> >> >>
> >> >> On 21.4.2020 1:17, Jan Waclawek wrote:
> >> >>> Hm, tak ja vidim vyhody skor v tych 6 ifoch a 1 pomocnej premennej...
> >> >>>
> >> >>> Ale ak by si nahodou nasiel odkaz, kde ten JW z minulosti povedal, ze
> >> >>> vysledkom podmienky nemusi byt 0 alebo 1, tak by som Ti bol vdacny.
> >> >>>
> >> >>> wek
> >> >>>
> >> >>>
> >> >>> ----- Original Message ---------------
> >> >>> Tak?e se po pár misících mu?u vrátit k tomu, ?e jedna z výhod C je 
> >> mo?nost
> >> >>> dilat vici, jako:
> >> >>>
> >> >>> If ((a<2)+(a>b)+(x<y)+(a%x==12)+(b<y)>  3) {
> >> >>>
> >> >>> Co? v jiných jazycích vede na 6 ifu a 1 pomocnou prominnou.
> >> >>>
> >> >>> PH
> >> >>>
> >> >>> Od: Jan Waclawek
> >> >>>
> >> >>> Hm, tak potom by som mal asi tomu JW z minulosti jednu tresnut...
> >> >>>
> >> >>> Konkretne teda, C99, 6.5.8 Relational operators #6:
> >> >>> Each of the operators<  (less than),>  (greater than),<= (less than or
> >> >>> equal to), and>=
> >> >>> (greater than or equal to) shall yield 1 if the specified relation 
> >> is true
> >> >>> and 0 if it is false. 92)
> >> >>> The result has type int.
> >> >>>
> >> >>> Ten footnote 92) je kuzelny:
> >> >>>    The expression a<b<c is not interpreted as in ordinary 
> >> mathematics. As the
> >> >>> syntax indicates, it
> >> >>> means (a<b)<c; in other words, ??if a is less than b, compare 1 to c;
> >> >>> otherwise, compare 0 to c??.
> >> >>>
> >> >>> wek
> >> >>>
> >> >>>
> >> >>> ----- Original Message ---------------
> >> >>>
> >> >>> Mil jsem nijak za to, ?e to byl právi jistý JW, kdo mi tu onehdá 
> >> vyeetl, ?e
> >> >>> spoléhat se, ?e výsledkem podmínky je 0 nebo 1 není správné:-)
> >> >>>
> >> >>> PH
> >> >>>
> >> >>> Od: Jan Waclawek
> >> >>>
> >> >>>> A jinak teda ten kód udilá to, ?e pokud je splnina podmínka v 
> >> závorce, nastaví se bit 0 na výstupní (zda to bude bit 0 není 
> >> zarueeno, ale jinak skoro jisté).
> >> >>>
> >> >>> Preco by to nemal byt bit 0?
> >> >>>
> >> >>> _______________________________________________
> >> >>>
> >> >>>>>
> >> >>>>>     DDRB |=(1<CLK_UP);
> 
> > _______________________________________________
> > 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
> _______________________________________________
> 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/20200422/d006bbad/attachment-0001.html>

Další informace o konferenci Hw-list