Dotaz: jak na "namespace" v C

[jiri vejsada]

pro vetsi linuxuvy projekt v C, pro ktery bude event. prispivat vice clenu je treba vyresit problem s kolizi jmen funkci. Tak jak to delaji v glib, gnome mohou ty jmena funkci "glib_nekomu_pripadat_trochu_prislis_dlouhe". Nezna nejaky ostrileny projektant lepsi moznost. Jak by jste to delali?

Odpovědi

[Petr]

Vetsi projekty v jazyku C vyuzivaji tzv. modularity -> Projekt je rozdelen do nekolika modulu. Kazdy modul spravuje nejakej logickej celek a exportuje pouze potrebne funkce, oastatni funkce jsou deklarovany jako static.

[jiri vejsada]

kdyz nejaky log. modul sestava napr. z 30 funkci a exportuje napr. jednu funkci, musi byt z duvodu static deklarace vsechny tyto funkce v jednou souboru? To je jiz kvuli make trochu nevyhoda, ne?

Ale take jsme o tom uvazovali, nase obavy v projektu jsou, zdali je to mozno obecne tak rozdelit, ze bude prevazna cast funkci skutecne "pro vlastni potrebu" a jen minimum na "export".

Ten problem je, ze projekt zpocatku vubec nevi, kdo co bude dodavat a realizovat - napr. bude vice programatoru dodavat moduly pro sklady a ta obava je, ze kazdy druhy pouzije "get_store_value" ....

[unchallenger]

Nemusí být v jednom souboru. Ale pak musíš něco vědět o linkeru a resolování symbolů. K tomu je asi nejlepší si přečíst článek How to write shared libraries[1] od Ulricha Dreppera, který je velmi dobře napsaný. Je tam popsáno několik možností jak, vysvětlit linkeru, že se symboly ,exportují` jen v rámci knihovny.

Kromě toho je 30 funkcí celkem málo, obvzvlášť tvoří-li jeden logický celkek, dát je do jednoho souboru je zdaleka nejjednodušší řešení.

[1] Týká se tedy hlavně knihoven; nevím, jak je ten váš projekt strukturovaný, ale normálním lidem stačí dvě úrovně filtrování prostoru symbolů -- objekt (.o) (což zařídí static ve zdrojáku) a knihovna (viz článek). Navíc lze moduly natahovené dynamicky (dlopen() a spol.) natahovat s RTLD_LOCAL, a používat jiný mechanismus inzerování, co modul obsahuje, než špinění globálního prostoru.

[Anselm]

Už při návrhu definujte rozhraní modulů tak, aby nedocházelo ke kolizím jmen. Exportujte pouze funkce realizující toto rozhraní. Nepoužívejte přiliš obecná jména, u funkcí operujících nad daty nějaké struktury použijte jako prefix jméno té struktury. Zapomeňte na globální proměnné.

[jiri vejsada]

... Už při návrhu definujte rozhraní modulů tak, aby nedocházelo ke kolizím jmen...

to by me zajimalo, ale zatim si nedovedu predstavit jak je to mysleno. Bylo by mozno uvest nejaky priklad? Mam si to predstavit tak nejak, ze napr. pro sklady bude na zacatku vsech funkcnich jmen store_ a u faktur napr. invoice_ ...?

[unchallenger]

Kód se píše jednou, ale čte mnohokrát.

Píšeš-li C knihovnu a nepoužíváš pro všechny symboly prefix podle jména knihovny, tak se ti všichni vysmějí a vzápětí vynadají. To vysvětluje to glib_. Pokud projekt neexportuje žádná API, pro rozšiřující moduly nebo vůbec pro cokoli, tak si to samozřejmě dělej, jak chceš, ale větší projekty obvykle nějaká API exportují.

Co se týče zbytku -- to je ta část nekomu_pripadat_trochu_prislis_dlouhe, tak ten se týká odlišení jmenných prostorů jen částečně:

1. Metody objektů jsou normální funkce C, a tedy v globálním rozsahu platnosti (nebo jak se to jmenuje česky -- zkrátka scope). Jediný způsob, jak se s tím rozumně vypořádat, je přidat jméno třídy do jména metody (BTW v C++ se to děje také, ale dělá to kompilátor). Tudíž co bys jinde zapsal container->add() nebo container.add(), jmenuje se [gtk_]container_add().

2. Nikdo neví, co dělá mbsnrtowcs(). Tedy někdo asi ano, ale... Funkce gtk_spin_button_set_snap_to_ticks() by se při zachování předchozích bodů stále mohla jmenovat gtk_spnbtn_ssc2(). Pak bys četl cizí kód a na každou druhou funkci se musel dívat do dokumentace, co dělá (tedy, kdyby nějaká použitelná existovala, takže spíš do zdrojáku). Naproti tomu každý ví, co dělá gtk_spin_button_set_snap_to_ticks() (pokud zná widget GtkSpinButton).

A teď k tomu, co máš dělat ty: Dělej to stejně. Psát dlouhá jména funkcí je práce textového editoru a umí to dobře. Zvolíš-li rozumně prefixy knihovna_, modul_ či objekt_, nemusí být ty názvy ani tak hrozně dlouhé, ale podstatná je stejně ta popisná druhá část, ne prefix[y].

[jiri vejsada]

dik za obsahly prispevek. Rozjedeme to tim smerem, sam jsem zvedav jak se budou jednotlivi vyvojari drzet te umluvy, aby ta popisna cast nebyla zbytecne dlouha.

Napadlo me jeste, ze by nebylo od veci, kdyby se daly najit podobne veci nejak shromazdene na jednom miste, aby se to nemuselo problematicky vzdy dohledavat. Takova nejaka rukovet praktickych postupu v programovani. Nic podobneho jsem zatim nevidel.

[Hynek (Pichi) Vychodil]

Mě osobně dlouhá jména nepřijdou problém, protože moje vývojové prostředí (vim) je bez problémů doplňuje za mě (^P), stejně tak mi nevadí ani krátká jména, protože když chci vidět co která funkce dělá tak se na ni kouknu (^[) a pokud je komentovaná, tak je to celkem rychlé. Pokud ne, tak někomu vynadám. (Nejčastěji sobě.) V takovém malém projektíku

hynek[sfmat]$ cat *.c *.h|wc
   9428   33383  271711

který píšu objektově, ale v ANSI C (kvůli přenositelnosti na platformy co C++ neznají, ano i takové jsou mezi námi) mi to nedělá velký problém.