Vlákno názorů k článku Propojení Pythonu s nativními knihovnami s využitím balíčku cffi (3) od Calculon - To předávání odkazem vs. hodnotou je docela sranda...

ja C znam dobre uz 25 let, ale vidim to porad u dalsich lidi. Je to nekonzistence a dalsi jazyky (ktere se od C odvozuji) se tomu pochopitelne vyhnuly.

Mluvim o tom, ze predavani parametru je nekonzistentni v pripade poli a to skutecne je. S ukazateli by to nemelo mit nic spolecneho.

Celkom by ma zaujímalo čo by ste zmenili, aby odovzdávanie parametrov bolo konzistentné.

vse predavani hodnotou (ma to tak treba Go).

To má ale taky záludnosti (stejně jako třeba Swift), hodnotou se předává hlavička kolekcí, ve které je ukazatel :)

Medzi C a go je skoro 40 rokov. Tvorcovia go mali prístup k neporovnateľne rozsiahlejšej báze znalostí. Nečítal som o histórii vzniku C ale nechce sa mi veriť, že keď sa pri návrhu rozhodli pre odovzdávanie parametrov hodnotou, že by to nezvažovali aj pre polia. Ale hodnotová sémantika znamená kopírovanie a v tej dobe bol hardvér oveľa slabší ako teraz a pamäť bola vzácna, tak to asi vzali ako rozumný kompromis.

Tvorcovia go celkovo moc nerozmyslali o veciach vznikutych po roku 1970.

jen na okraj: CSP vyslo az v roce 1978

(ale jo, neuvazovali o class-based OOP a malo o DLL/so, coz je asi dobre, aspon v nasi uzce nice)

Class-based uvažovali a zavrhli, ne? Nebo se špatně pamatuju? Podobně jako Rust.

jj taky myslim, ze to byl cisty kompromis pro tehdejsi HW

Hlavně to vzniklo v jiném kontextu. C pro psaní přenositelných OS (proto “portable assembly”), podobně jako Rust pro jádro prohlížeče (v prvopočátku). Go zase pro síťové služby, proto důraz na souběžnost a NIO. Navíc C nevzniklo na zelené louce.

Ono to není divné, prostě C je nízkoúrovnější. Nám na škole říkali, že C vlastně pole nemá, jen syntaktický cukr okolo pointerové aritmetiky. Asi to je jen slovíčkaření, ale je fakt, že v porovnání s modernějšími jazyky to mást může.

jj presne k takovym myslenkovym zkratkam to potom vede. Neco podobneho se pise v ucebnicich atd. a fakt ma hodne lidi co i v cecku neco udelali pocit, ze type *x == type x[]

Aky je teda medzy tym prakticky rozdiel?

tak treba ze sizeof() se bude dost zasadnim zpusobem lisit. Cecko totiz pole v compile time zna, umi spocitat jejich velikost, rozlisit typ dvou poli se stejnymi typy prvku atd. atd.

a samozrejme pointerova aritmetika (resp.pointerove operatory) s poli nebudou presne funguovat (takove x++ apod.).

9. 6. 2023, 08:22 editováno autorem komentáře

No v tom pripade ale treba rozlisovat staticky alokovane pole a dynamicky alokovane pole.
Navyse kazde pole ide priradit do pointeru.

No a to je ta nekonzistence, si zkuste co na zacatku zmate kazdeho

#include <stdio.h>

int main(void) {
    char x2[] = {1,2,3};
    char *x1=x2; /* u vsech ostatnich typu se vyzaduje &x2 */

    printf("%p %p\n", x1, x2);

    /* tvarime se ze pole a pointer je to same */
    printf("%d %d\n", x1[0], x2[0]);

    /* nechteny dusledek x[y] = *(x+y) = *(y+x) = y[x] */
    printf("%d %d\n", 0[x1], 0[x2]);

    x1++;
    /* ovsem x2++; nelze */

    printf("%p %p\n", x1, x2);
    printf("%d %d\n", x1[0], x2[0]);

    return 0;
}

Ked tvoj prilad upravis na:

char * const x1=x2;

Tak sa to uz spravat konzistene bude.

to bych tedy nerekl :)

Uz nebude mozne spravit x2++ a to bol jediny prakticky rozdiel vo vasej ukazke.

ano, je to tak (a ma to dalsi dusledek - free(x2) uz bude legalni, kdyby tam jen visel nekonstantni pointer, tak neni jistota, co se stane).

Ta druha nekonzistence byla v tom tvrzeni, ze pole jde priradit do pointeru (u jinych typu byste to asi u pohovoru nerekl bez uzardeni ne?) A tyto vety strasne matou lidi, co na C prechazi (protoze samozrejme jsou a soucasne i nejsou spravne).