Názor k článku
Programovací jazyk C má nejnižší oblíbenost v TIOBE za posledních 15 let od Petr M - Ono jde o abstrakci. Problém je třeba řešit...

  • Článek je starý, nové názory již nelze přidávat.
  • 31. 8. 2016 13:56

    Petr M (neregistrovaný)

    Ono jde o abstrakci. Problém je třeba řešit na úrovni, na které existuje. Když dělám komunikační protokol, tak musím vědět, po jaké jedu lince - např. UART_write(), ... Nenapíšu to dost abstraktně na to, abych nemusel nic měnit. A ovlivní to někdy celkem dost věcí, takže potom jsou na řadě zvěrstva jako psaní wrapperu, struktura s referencema na funkce, balení do maker,... Volbou namespace a automatickým výběrem funkce s odpovídajícím chováním by se hodně věcí vyřešilo.

    Výjimky jsou sice prasárna, ale nepotřebuje tak moc zásobníku ve standardu. Ono třeba udělat několik nezávislých instancí hierarchovckýho stavovýho automatu a v něm mimo stavu reportovat chyby je docela divočina. Co je tam chyba návrhu? Stavový automat, ošetření chyby, nebo absence výjimek (a ne, pokud je každá instance parseru v jiným vlákně pod FreeRTOS, tak setjmp nepomůže).

    S čistotou enumu, nebudem si lhát. Mimo cyklu (kde stejně musím mít napsanou poslední položku známýho jména, abych věděl, kolik jich je, protože něco jako countof(enum) nebo foreach neexistuje), je to jenom svázání symbolických jmen s hodnotou a datovým typem. I v tom blbým Pascalu můžu napsat
    var x: array[mujenum] of Integer;
    a když v C napíšu
    int q[enum mujenum];
    tak mě to pošle do ...
    Vyložebně se enum hodí pro zobrazení symbolickýho jména v debuggeru. Jinak jeho použití kulhá.

    Bitový enum chci právě proto, abych nemusel psát rovnítka v klasickým enumu, pokud ten vnitřní stav je složením několika hodnot (fmRead | fmWrite) A pokud jde o #define, to je věc preprocesoru, bez typové kontroly, bez varování,... takže čím méň, tím líp. Je to univerzální hack na věci, který jazyk neumí ve standardu.

    Bitový pole u hardware je jakž takž OK. V dalším levelu, třeba parser protokolu, to přetáhnu na jinou platformu a jsem v pr...

    Částečná definice struktury, to je dost zásadní věc. Při rozšíření struktury nebo smazání položky, která je inicializovaná na X místech, to háže nepěknou chybu. A někdy je problém na straně architektury ve VHDL u výrobce křemíku. Víš, jak by bylo krásný si třeba udělat instanci periferky jako const struct, inicializovat natvrdo a jenom zkopírovat, místo přiřazování registru po registru? Jenomže ti pitomci tuhle nechají 100B pauzu, támhle je u SPI2 registr, který u SPI1 není a u SPI3 má jinou funkci... A někdy (nemožnost rozšířit strukturu, nepodpora přetěžování) je výhodnější vzhledem ke spotřebě paměti použít jednu strukturu s pár položkama navíc. A na mojí úrovni se prostě nechci starat o to, že tam je potřeba vložit pět libovolných intů jako výplň navíc :(

    Rozšíření struktur je celkem důležitá věc. Pokud mám několik modulů se stejným základem (např. různý komunikační linky) a u jedné chci přidat DMA, tak by pěkně odpadl wrapper, který pro společný funkce jako init() hodí strukturu zabalenou ve struktuře jako argument... Napsat to je práce navíc (i když #define to schová skoro bez zvýšení nároků).

    Pouze externí const je za trest pro všechny, kdo nejsou schopní lokální proměnnou zapouzdřit jako static dovnitř modulu a kdokoliv se dostane bez varování kamkoliv. Aspoň by jednou museli přemýšlet.

    A ta lenost má vliv vždycky. Když musím pro každý modul psát něco jako
    #define write(data, size) UART_Write(han­dleWithDma->uart, data, size)
    pro deset funkcí a zbytečně, tak to tak jako tak stojí čas a editor/IDE to za tebe neudělá...

    Množiny, no ty jsem nepotřeboval už od včerejška :/ Zvyk je železná košila.