<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    No asi tak nějak:-)<br>
    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.<br>
    <br>
    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.<br>
    <br>
    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ší.<br>
    <br>
    PH<br>
    <br>
    <div class="moz-cite-prefix">Dne 05.09.2023 v 16:06 Jindroush
      napsal(a):<br>
    </div>
    <blockquote type="cite"
      cite="mid:41c46bd9-a82b-c2aa-8590-5f094f7aca87@seznam.cz">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div class="moz-cite-prefix">Dobry den,</div>
      <div class="moz-cite-prefix">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)<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">Jinak samozrejme zapis <br>
        if( A=B ) {} je zcela legalni a kazdy zdravy kompilator s
        obvykle 'rozumnymi' (nikoli nutne vychozimi) nastavenimi (-Wall)
        vypise neco jako toto:<br>
      </div>
      <div class="moz-cite-prefix"><source>:7:10: warning: suggest
        parentheses around assignment used as truth value
        [-Wparentheses]<br>
            7 |     if( a=b )<br>
              |         ~^~<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">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. <br>
        <br>
        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.<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">J.<br>
      </div>
      <div class="moz-cite-prefix"><br>
      </div>
      <div class="moz-cite-prefix">On 05.09.2023 15:24, Martin Záruba
        wrote:<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>
        </blockquote>
      </blockquote>
    </blockquote>
  </body>
</html>