[24][27] Je rozhodnutím tvůrců STL, že rychlosti obětují vše. Tedy i rozšiřitelnost, bezpečnost, spolehlivost – to vše šlo do háje.
Takže například iostream like objekty nemají virtuální metody, aby se ušetřilo 0,0000000000001 sekundy při práci s diskovými soubory třeba.
Řetězec není řetězec, není to kompaktní string, je to jednoduché pole bajtů (které jsou někdy brané jako pole char, jindy jako wchar_t, případně si můžete dodělat traits pro další typy). Ale nikdy se to nechová jako celek – programátor prostě dostává pole a musí si hlídat jako znakové kódování (protože basic_string šablona je zkrátka binární pole, nikoli textový řetězec). Stringy v STL nejsou abstrakcí textových řetězců, ale abstrakcí binárních polí stejných typů zakončených nulou (nebo jinak, jak si napíšete v traits).
Kontejnery typu vector, list, atd. nekontrolují předávané parametry (s výjimkou at() metody), takže jakmile chcete prvek mimo rozsah, podle normy je legální, když se program nekontrolovatelně zhroutí, nebo se rozesere, nebo cokoli.
Přitom u kontejnerů je argument rychlosti irelevantní. Pokud budu potřebovat maximální rychlost, napíšu si svůj kontejner na míru. Ten bude klidně 2 ×, možná i 10 × rychlejší než cokoli co jde přes STL. Konkrétní kontejner na psaný na míru včetně vlastních alokací bude vždy rychlejší, než obecná implementace. Když nepotřebuji šetřit každou pikosekundou, což v 99,999999 % nepotřebuji, pak uvítám kontejnery, které se chovají spolehlivě a při nekorektním požadavku vyhodí třeba výjimku a program jede dál.
Napsat si náhradu vlastních kontejnerů za STL je otázkou velmi krátkého času. Ona toho STL zase moc neumí.
Takže STL beru jako defektní od výroby a fakticky ho nepoužívám. Pokud potřebuji maximální rychlost, napíši si to konkrétně – a vždy to bude rychlejší, než STL. Takže STL nenabídne ani maximální rychlost, ani bezpečnost, ani spolehlivost.
ČLÁNKY DO MAILU