Názory k článku
GLib: Práce s řetězci (1)

Jak to tak vidim, tak nektere knihovny v posledni dobe soutezi o to, kdo bude mit nejdelsi nazvy funkci.
Uz samotny nazev g_strdup_vprintf mi prijde oproti glibc vasprintf pomerne dlouhy, ale u g_get_upper_bound_vprintf (ci nejak tak, myslim, ze ten nazev byl puvodne skoro pres pul stranky me 80-znakove obrazovky) uz snad museli vyhlasovat soutez o nejlepsi nazev nekde na freshmeatu...

Proc vlastne GLIBC takhle naprosto zbytecne duplikuje to, co je k dispozici pod ANSI C a vymysli vlastni funkce pro to, co uz pod jinym nazvem existuje jinde ? Proto, aby se ztizilo portovani aplikaci napsanych pro glibc na systemy zalozene na jine C knihovne ? Me osobne to prijde docela ... rekneme ... nemoudre.
Ale nakonec - cely svet je Linux, ze ? Takze nejaka portabilita nema prece vyznam, to se uz nenosi :-]

Predem bych Vas chtel upozornit, ze tento clanek nepojednava o GLIBC (coz je implementace funkci standardniho C), ale o knihovne GLib, ktera jistym zpusobem stoji 'nad' temito funkcemi a dodefinovava nektere dalsi dulezite funkce a datove typy.
Kdybyste si me clanky precetl pozorneji, zjistil byste, ze funkce knihovny GLib nejsou jen nejake predelavky ANSI cecka - vetsina funkci je novych a v ANSI norme je nenajdete; dalsi funkce nejakym zpusobem vylepsuji ty standardni...

Autori knihovny GLib navic prohlasuji moznost prenosu zdrojaku na win32, takze ty narazky v posledni vete mi prijdou docela ... rekneme ... nemoudre :-].

Co noveho a lepsiho prinasi napr g_strdup() nebo g_strndup() ?

Mate pravdu, g_strdup() nebo g_strndup() nedela v podstate nic prevratneho. Stejne tak byste mohl napadnout treba datove typy gchar, gint atd (viz. 1. dil). Nevim, co autory vedlo k zarazeni takovych funkci, presto bych vsak chtel rict, ze prinos knihovny GLib nelze zmensovat. GLib implementuje mnoho vykonnych funkci a velmi prispiva k prenositelnosti: co treba datove typy gint32 apod., u kterych na VSECH platformach mate jistotu, ze budou stanovene delky?
Co treba funkce g_strcasecmp()? Nejsem si jist, jestli ji standardni ANSI C definuje. V dalsich dilech se mozna dovite o dalsich funkcich (tedy jestli zustanete ctenarem): napr. spojite seznamy, hashovaci tabulky, obsluha udalosti, automaticke doplnovani textu atd.
Navic funkce a typy knihovny GLib pouziva knihovna GTK (slouzi pro programovani v X-Window), takze jeji alespon zakladni znalost jiste neni na skodu.

ad gint32 & spol: opet vynalezli kolo a udelali to jinak nez to co jiz existuje - *BSD uz nejaky ten patek ma int32_t, u_int32_t apod. primo v (sys/types.h). I na nekterych ne-BSD systemech se tyto typy vyskytuji. IMHO tyto typy musi byt definovany ve standardnich hlavickach operacniho systemu - jiste je nesmysle, aby program zavisel na glibc v pripade, ze jen potrebuje urcitou velikos typu.
strcasecmp() _je_ standardni soucast ANSI C (stejne jako napr. setlocate(), strxfrm() atd).
Pokud kazdy programator bude zcela jasne vedet, ze g_* jsou neportabilini a pouzivat je jen tehdy kdyz je potrebuje, pak je vsechno v poradku. Obecne je asi moudrejsi zavadet API, ktere je 'stadardni' a snazit se byt maximalne kompatibilni s tim, co jiz existuje. Je to jista vyvojarska zodpovednost, kterou by mel projevit autor jakekoli obecne knihovny funkci.

Tak jako GLIBC urcite obsahuje hodne uzitecnych funkci, ktere usnadnuji programatorovi praci a je

Spolehat se na to, ze na nejakem BSD uz existuji int32 apod, nezni take zrovna moc prenositelne. Urcite je sposta systemu, kde takove typy definovany nemaji. Proc by tedy GLib nemohla byt onim prvkem, na ktery se lze spolehnout?

Funkce g_strcasecmp() skutecne vola standardni funkci strcasecmp() - ovsem jen v pripade, ze na danem systemu existuje! Pokud se pri instalaci knihovny GLib zjisti, ze na dane platformne strcmp() neni, podminenym prekladem se pouzije alternativa implementujici vlastni verzi tohoto prikazu (podobne i s jinymi funkcemi). To je dalsim dukazem PRENOSITELNOSTI knihovny GLib.