Je jazyk C skutočne ťažký?

[BoneFlute]

Vědět, že je operátor >> implementation defined (většina lidí to neví a předpokládá, že se jedná o aritmetický shift).

Pak by si asi měli přečíst dokumentaci. Stejně tak by někdo mohl říct, že v Rustu většina lidí neví, že chování + závisí na tom, jestli kompilujete Debug nebo Release. Nebo v C#, že se chování ToUpper a ToLower řídí aktuálním locale a někdy můžete dostat fakt nečekané výsledky. Nebo v Gleamu, dělení 0 vrací 0, není to chyba. A takových situací jsou hromady ať už jste v Rustu, C, C++, Go nebo F#. Je lepší nepředpokládat a přečíst si dokumentaci.

Přesně tak. Znalost jazyka je nutná pro každý jazyk. A řeči typu "jazyk neděla co chci" = jen lenost si ho nastudovat. Každý jazyk se musí nastudovat, i ty moderní. Jestli to je někomu bližší, a snažší uchopit, tak budiž, ale ve výsledku je potřeba to nastudovat a tomu se člověk nevyhne ani v tom Rustu, ani C#. Každý jazyk má svá specifika a toto jsou dobré příklady že i v jiných jazycích se lze lehce střelit do nohy.

Já nemám problém si něco nastudovat.  Ale mám problém když jazyk říká "ano, o to se ti postarám, někdy, možná". Tím spíše, že C měl být "přenositelný assembler". No, nepovedlo, se nevadí, jedeme dál.

[Reklama]

[snugar_i]

Dále nechápu to s tím assemblerem. C přesně odpovídá tomu jak jsou věci v assembleru. Je to de-facto portabilní assembler. A právě ten kdo prozkoumá věci v C až na úroveň asembleru, tak ten má pak v těch věcech jasno a žádná mentální zátěž to pro něj už není. Mentální zátěž je, když v tom jasno právě nemá a musí to pořád vyhodnocovat.

No právě že assembleru neodpovídá (viz shiftování signed intu). Tím, že se snaží být ne jeden assembler, ale všechny assemblery najednou (s tím, že každý se vlastně chová trochu jinak), tak se z něj stává guláš, kde spousta věcí musí fungovat polovičatě, jako v každé abstrakci.

Takže pokud prozkoumáš C až na úroveň assembleru, tak podle standardu C ti to je k ničemu, protože stejný kód se ti na procesoru xyz bude chovat úplně jinak.

[xyz]

Hosi, nepresvedcili jste me. To ze je C nizkourovnovy jazyk, je jasne. Ale proc bych mel psat
a << -1 To je jasny, ze je to undefined behaviour.

Ale porad si myslim, ze to neni nijak slozity jazyk, pouze jsou v nem zaludnosti.

Pokud by C byl dokonala abstrakce nad CPU, tak by se v nem nedal psat operacni system, drivery, embedded kod. Nebo mi chcete rict, ze v Haskellu jde napsat operacni system?

[Jiří Havel]

Hosi, nepresvedcili jste me. To ze je C nizkourovnovy jazyk, je jasne. Ale proc bych mel psat
a << -1 To je jasny, ze je to undefined behaviour.

O takovém shiftu tady celou dobu nebyla řeč. Mluvilo se o :

Kód: [Vybrat]

a >> 1
kde a je signed integer.

[BoneFlute]

Hosi, nepresvedcili jste me. To ze je C nizkourovnovy jazyk, je jasne. Ale proc bych mel psat
a << -1 To je jasny, ze je to undefined behaviour.

Ale porad si myslim, ze to neni nijak slozity jazyk, pouze jsou v nem zaludnosti.

Pokud by C byl dokonala abstrakce nad CPU, tak by se v nem nedal psat operacni system, drivery, embedded kod. Nebo mi chcete rict, ze v Haskellu jde napsat operacni system?

Operační systém v Haskellu

Tak on je rozdíl mezi tím, když musíš psát inline assembler a mezi tím, když si musíš pamatovat, že toto se sice tváří, jako že ok, ale ok to není.

[Reklama]

[Jiří Havel]

BTW, ještě se tu neobjevil Preprocessor iceberg :
https://jadlevesque.github.io/PPMP-Iceberg/

[Martin Sivák]

Ale porad si myslim, ze to neni nijak slozity jazyk, pouze jsou v nem zaludnosti.

C je syntakticky jednoduchý jazyk. Ale není jednoduchý na použití.

V porovnání s veškerou konkurencí kromě čistého ASM mu chybí jakékoliv pomůcky pro efektivní práci. Není skoro žádná standardní knihovna. Člověk si to prostě musí odedřít s malloc/free, pointery a polem. A pořád u toho dávat pozor.

Někdy je to nutné, ale většinou ne.

[Jožka Niemand]

Jenže na té adrese může být registr která má nenahraditelnou speciální funkci či význam. To je naprostý nesmysl to řešit tak jak říkáš. To může udělat jenom teoretik který k tomu prakticky nikdy nečmuch.

To je velmi neobvyklé, že by byl speciální registr nějakého mikrokontroléru na adrese 0, kdy jsi na to prakticky narazil a musel jsi to řešit? Neříkam, že neexistují architektury, kde to tak je, ale zajímalo by mě, kde jsi to prakticky potkal? Pokud se totiž něco takového stane, máš opravdu problém. Buď musíš do assembleru a provést zápis tam, nebo dělat v C něco hodně nestandarního a doufat, že se to nerozbije s novou verzí překladače.

Je ale velmi obvyklé, že procesor po resetu začne vykonávat program od adresy 0. Takže zápisem instrukce skoku na adresu 0 de facto měním vektor "přerušení" typu reset.

[Wasper]

Co s tím? Vyřeší se to tak, že se RAM zadefinuje od adresy 1 a adresa 0 se ignoruje, abychom se vyhnuli problémům s dereferencí null pointeru. Přijdeme o jeden bajt RAM na mikrokontroléru, ale to je nízká cena za vyřešení problémů s adresou 0 a undefined behavior.

Jo, no naprosto geniální tah. Třeba v případě, že takovej Atmel tam má namapovanej jeden registr je to dobrý fundamentalistický přístup do něj prostě nešahat...

[Jiří Havel]

Co s tím? Vyřeší se to tak, že se RAM zadefinuje od adresy 1 a adresa 0 se ignoruje, abychom se vyhnuli problémům s dereferencí null pointeru. Přijdeme o jeden bajt RAM na mikrokontroléru, ale to je nízká cena za vyřešení problémů s adresou 0 a undefined behavior.

Jo, no naprosto geniální tah. Třeba v případě, že takovej Atmel tam má namapovanej jeden registr je to dobrý fundamentalistický přístup do něj prostě nešahat...

Pragmatický přístup je samozřejmě ten, že se pro některé platformy to nedefinované chování dodefinuje. Přece jenom standard C od tohohle dává ruce pryč a dovoluje naprosto cokoliv.

A důsledek je samozřejmě ten, že něco co embedáci u sebe normálně dělají, je na jiné platfomě recept na katastrofu. Může nastat něco co ani nepřipomíná předpokládaný segfault při přístupu na adresu 0.

[Wasper]

Pragmatický přístup je samozřejmě ten, že se pro některé platformy to nedefinované chování dodefinuje. Přece jenom standard C od tohohle dává ruce pryč a dovoluje naprosto cokoliv.

Presne tak bych to bral taky. Standard se snazi byt univerzalni, coz je dobre, tak rika, ze dane chovani nedefinuje, coz je taky dobre, a od programatora se ceka, ze to nebude v prenositelnem kodu delat.
Pokud pro konkretni platformu dava konkretni chovani smysl, nebo je dokonce potreba (viz nejen ten Atmel), necht je to platform specific chovani. Stejne jako treba nepouzivat __asm__ __volatile__ ("cli") jen proto, ze to neni kosher protoze to neni v normach, a nadavat co vsechno se s Arduinem neda delat by bylo trochu ... divne.

[Radek Miček]

V porovnání s veškerou konkurencí kromě čistého ASM mu chybí jakékoliv pomůcky pro efektivní práci. Není skoro žádná standardní knihovna. Člověk si to prostě musí odedřít s malloc/free, pointery a polem. A pořád u toho dávat pozor.

Někdy je to nutné, ale většinou ne.

Dá se to brát tak, že ti kdo v tom programují si staví vlastní knihovnu podle sebe. Například někteří lidé ani nepoužívají malloc a píší si vlastní alokátory. Naopak už se mi několikrát stalo v jiných jazycích se standardní knihovnou, že se v ní něco změnilo a já pak strávil týden přepisováním kódu, aby ho vůbec bylo možné přeložit s novou verzí.

[Radek Miček]

Co s tím? Vyřeší se to tak, že se RAM zadefinuje od adresy 1 a adresa 0 se ignoruje, abychom se vyhnuli problémům s dereferencí null pointeru. Přijdeme o jeden bajt RAM na mikrokontroléru, ale to je nízká cena za vyřešení problémů s adresou 0 a undefined behavior.

Jo, no naprosto geniální tah. Třeba v případě, že takovej Atmel tam má namapovanej jeden registr je to dobrý fundamentalistický přístup do něj prostě nešahat...

Pragmatický přístup je samozřejmě ten, že se pro některé platformy to nedefinované chování dodefinuje. Přece jenom standard C od tohohle dává ruce pryč a dovoluje naprosto cokoliv.

Dodefinování zjednoduší ladění, protože se kompilátor bude chovat podle známých pravidel, ale stejně to nepředejde situacím, které programátor neočekával (pokud například čeká, že po přičtení 1 bude číslo větší, tak tahle vlastnost tu není). Podle mě by bylo lepší, kdyby takovéhle věci vyhazovaly chybu, což bohužel řada jazyků nedělá.

[Jožka Niemand]

Raději nedefinované chování, než za každou cenu vymýšlet konkrétní chování, jež nemusí být intuitivní. Nevím, jak je to ve standardu dnes, ale další operace, jež by měly být IMHO nedefinované: umocňování záporného čísla na racionální, modulo dělení záporných čísel...

[Jiří Havel]

Raději nedefinované chování, než za každou cenu vymýšlet konkrétní chování, jež nemusí být intuitivní.

Tady nastává jeden praktický problém. Konkrétní chování programu, když to UB přece jenom nastane, dokáže tu neintuitivnost dotáhnout do netušených extrémů.

UB umožňuje autorům překladače doplnit tam nějaké příčetné chování. Ale když to neudělají, tak je to strašná past.