Odpor k STL

5.7.2006 16:57 | Přečteno: 1490× | Rouhání největší

Jednou z poměrně málo pochopitelných věcí je odpor k STL u programátorů v C++. Někteří pro něj mají pádné důvody, ale u těch ostatních většinou nevím o jediném rozumném argumentu, proč STL nepoužívat.

Prakticky každý program vyžaduje nějaký mechanismus ukládání dat v paměti. Velice záleží na tom, jaká data ukládáme a jak s nimi potřebujeme pracovat. Nelze zapomenout ani na časté dilema "operační versus paměťová složitost". Proto je dobré mít možnost s daty pracovat efektivním, univerzálním a přenositelným způsobem, s výběrem metody, jak se budou data ukládat.

V jazyce C++ máme standardně k dispozici velice silné prostředky k realizaci tohoto cíle. Skrývají se pod zkratkou STL (Standard Template Library, standardní knihovna šablon). STL je běžně součásní standardní knihovny C++ (např. libstdc++), kromě toho existují i další implementace, např. STLPort. V knihovně jsou obsaženy šablony pro kontejnery a celá řada dalších zajímavých věcí, včetně efektivní implementace řetězců.

Když jsem začínal programovat v C++, právě STL byla věc, která mě naprosto uchvátila. Již předtím jsem znal Java Collections Framework, kde je filosofie trochu podobná, nicméně i vzhledem k různému charakteru jazyků se řada věcí liší. V každém případě jsem se ale do používání STL vrhl po hlavě a postupně přicházel na výhody i nevýhody. Pravda, nevýhod moc není - i když samozřejmě nějaké také jsou.

Vzhledem k výtečným vlastnostem STL by jeho použití mělo být metodou první volby ve všech případech, kdy tomu nebrání závažné důvody. Už pro tu přenositelnost a spolehlivost to stojí za to. Je tu pochopitelně pár situací, kdy STL raději nepoužívat - zde jsou ty hlavní z nich:

• Kompatibilita. Na mnohých platformách ještě poměrně nedávno nebyla implementace STL k dispozici buď vůbec, nebo v dostatečné kvalitě. Proto pokud někdo potřebuje psát program, který by měl jít zkompilovat i na těchto zastaralých systémech, musí na STL zapomenout (pokud tam z nějakých důvodů nejde použít např. STLPort).
• Výkonnost. V některých méně častých situacích, kdy potřebujeme co nejefektivnější kód za každou cenu, je také lepší naprogramovat si danou věc přímo, bez použití STL.
• Kontrola chování. Šablony jsou poměrně ošemetná věc, a mohou se hlavně se staršími kompilátory chovat všelijak. Proto tehdy, potřebujeme-li mít vše plně pod kontrolou, je vhodnější zvolit jiné řešení.
• Použití frameworku. Mnohé frameworky (např. Qt, gtkmm) používají vlastní reprezentace kontejnerů a dalších objektů. Není příliš vhodné míchat různé druhy objektů, proto ani v tomto případě není STL to nejlepší řešení.
• Nepříjemné ladění. Ladění programů používajících STL je někdy dost obtížné - někdo hovoří až o topení se v podtržítkách. Microsoftí implementaci STL navíc nelze ladit prakticky vůbec. Toto ale nepovažuji za dostatečně silný důvod, protože skoro všechny chyby v programu lze najít ještě mimo vlastní kód STL.

Když vynecháme uvedené důvody (a výjimečně ještě nějaké další), obecně není důvod se používání STL bránit. Přesto se všeobecně setkávám s tím, že programátoři toto řešení zavrhují a raději tráví spoustu hodin návrhem, implementací a laděním vlastních kontejnerů. Jiní se zase moří se složitými operacemi na řetězci typu char*, i když pomocí std::string by to měli hotové za pár minut.

Doporučuji proto, ať se každý, kdo programuje v C++ a nepoužívá STL, trochu zamyslí nad tím, jaký je hlavní důvod. Případně ať se podívá, co mu tato výtečná knihovna skýtá a jak se používá. Možná přijde na to, že to celé bylo zbytečné a že jediným důvodem nepoužívání byly obavy z neznámého.

       

Komentáře

[Josef Kufner]

STL jsou úžacná věc, ale poslední dobou se popzvolna probírám z opojení z STL a zjišťuju, že objektově psaný kód není zas až taková výhra. V konečném důsledku je daleko méně přehledný než strukturovaný v C. Nemyslím návrh, ale kód jako takový. Dohledávat, co se vlastně doopravdy spustí je něco děsnýho.

[Michal Kubeček]

Je otázka, do jaké míry je to jazykem a do jaké míry autorem. Když jsem začínal s C, byl jsem opojen konstrukcemi typu 'while (*s++ = *t++);' nebo 'int f(int n) { return n ? n*f(n-1) : 1; }' a musel jsem z toho vystřízlivět. Když jsem začínal s C++ byl jsem podobně opojen jeho vymoženostmi a byl jsem přesvědčen, že musím za každou cenu overloadovat operátory, používat šablony atd. Z toho prostě člověk musí vyrůst…

[Josef Kufner]

To taky, ale spíš jsem měl na mysli třeba to, že se děděním vytvoří nějaká hiearchie tříd. Metody se různě dědí či nedědí, některé jsou virtuální, některé ne... no a pak když chci vědět co se myslí řádkem

potvoro->hejbni_se();

tak musím prolézt celkem dost kódu a zkoumat co kde je. Kdežto v C mi to grep poví prakticky rovnou a ctags fungují bezchybně. Další lahůdka je, když se v php předá nějaký objekt coby parametr funkce a chci zjistit co se vlastně předalo. To zas není problém v C++, protože tam je uveden typ.

Zase nadruhou stranu, v C++ lze schovat spoustu kódu, který by jinak překážel a znepřehledňoval. Například přetížením operátorů. Ale to není u slušně napsaného kódu v C problém.

[VícNežNic]

No, ale to by měl být spíše záměr, ne? Aby se člověm nemusel starat kde to je.

[Josef Kufner]

Ale to je výhodou jen do té doby, než je v tom potřeba něco změnit.

[VícNežNic]

Ten uvedený příklad by měl tak na pohled sloužit k tomu, aby se potvora pohla. Samozřejmě, potvora je potvora a může udělat cokoliv, jenže když se programuje tak, že potvora na pohni reaguje tím, že sežere programátora, tak si myslím, že by byl problém všude a při jakémkoliv přístupu

[Sinuhet]

To taky, ale spíš jsem měl na mysli třeba to, že se děděním vytvoří nějaká hiearchie tříd. Metody se různě dědí či nedědí, některé jsou virtuální, některé ne... no a pak když chci vědět co se myslí řádkem

To je spise vysledek chaotickeho navrhu knihovny a pouzivani neintuitivnich jmen. A nebo dusledek vaseho podvedomeho odporu k OO programovani obecne.

[Filip Jirsák]

Nevím, zda to umí nějaká IDE pro C++ (vim to asi nebude ), ale třeba eclipse pro Javu v tomhle docela pomáhá, že je možné prohlížet hierarchii tříd, Ctrl+clickem je možné přejít z použití metody rovnou na její implementaci atd.

[Luk]

CDT plugin do Eclipse to umí - bohužel to ale často blbne

[mrzout]

v php muzes vynutit typ parametru:

class Trida {}

function xxx ( Trida $par ){}

ale mozna jsem te nepochopil, c++ jsem videl jen z rychliku :)

[Luk]

Hlavně nechápu, jak PHP souvisí s STL. PHP je dynamicky typový jazyk, což má své výhody a nevýhody. Takže některé "jakoby samozřejmé" věci jsou tam prostě jinak.

[mrzout]

Ja reagoval na zminku o PHP v komentari.

Do debaty o STL bych se neopovazoval zasahovat :)

[Sinuhet]

A cim vam STL vnucuje OO?

[Josef Kufner]

Tím, že už samo STL jsou třídy, byť ještě nejsou vytvořené pro konkrétní typ? Ale připouštím, že je možné psát strukturovaně a STL používat, ale to není to, nač jsem narážel.

[Sinuhet]

Eh. No on treba takovy vektor je skutecne uvozen slovem class, ale tim jeho podobnost s OO konci. Vyhoda STL je totiz v tom, ze vam OO necpe. Tak byla navrzena.

[elviin]

Nevim, jestli jsem vas pochopil, ale klidne muzete radit pole intu nebo pole brambor. Zalezi na aplikaci:

int pole[] = {4, 4, 4,4 ,4};

std::sort(pole, pole+3); //seradi brambory nebo 4ky nebo streamy 

:)

[VícNežNic]

• v prakticky každém blogu
• proč?
  • ?
  • dá se to nějak zjistit?
• co já s tím?

[Creckx]

STL je super věc...i když je to dávno co jsem dělal v C++ (ještě s winAPI) tak mi tenkrát hrozně pomohla. Dneska už jsem zalehnul u pythona a nějak mě C++ neláká :)

[elviin]

Kdyz jsem zacal pouzivat STL, tak muj kod nabyl na prehlednosti. V podstate veskery problemy resim tak, ze oddeluju data a algoritmy. Vite jake je to poteseni, kdyz je pozadavek na zmenu funkcionality aplikace a ja zmenim jenom typedef nebo zpusob razeni, transformace, funktory, kontejnery. To si pak programator chrochta, ze se nemusi bastlit s forama a whilama - proste zmenim algoritmus, kterymu je jedno s cim pracuje (to s cim pracuje se vyladi politikama nebo treitama). Hlavni kod zustava stejnej a je modularni. Kdyz jsem pridal Boost, tak to je jedna radost.

Ty (negativni) vlastnosti, ktery popsal Luk se daji zeslabovat i posilovat. Proste do toho musi clovek videt, ale neni to, jak se rika raketova veda. Lze udelat aplikaci, kde nemusite pouzit pointer. Vsechno je pod kontrolou STL a iteratoru, u polymorfnich impl. chytrych ukazatelu, ktery si navic muzu delat konstantni, kdyz je treba a neverim si. Proste mam prehled jak v kodu, tak co se tyce pameti. Samozrejme, kdyz nemyslim, zku*vit se da vsechno.

[machr]

STL je super vec. Ze zacatku se mi sice moc nelibila, protoze neni uplne intuitivni a naucit se ji efektivne vyuzivat vyzaduje trochu casu. Ale psat si vlastni containery se me vzne nechtelo, tak sem s ni zacal pracovat a zjistil jsem, ze je to super knihovna.

[Luk]

On je také trochu problém s dokumentací, kde není všechno úplně popsáno tak, jak by se slušelo. A kdo začínal s STL pod Windows, tam je to úplná tragédie - jak jsem kdysi vychvalovat MSDN, tady se k tomu Microsoft postavil hodně macešsky a microsoftí dokumentace k STL je přímo otřesná.

[machr]

ja si vetsinou vystacim s touto strankou...

[elviin]

http://www.dinkumware.com/

[Luk]

Bohužel ne každý ji zná (třeba já jsem ji také neznal). A dokumentace na webu GNU je poněkud méně stravitelná.