[8] Samozřejmě by bylo možné HALTS upravit tak, aby to certifikovalo i STL konstrukce. Ale vzhledem k tomu, že STL je součást ISO standardu jazyka, tak bychom rovnou nemuseli věřit ani kompilátoru a interpreteru (také je napsali lidé) a kde jsme s tou bezpečností v C# a Javě?
Ta funkce func samozřejmě důvěryhodná není, proto je také uvedeno v HALTS, že na ní závisí důvěryhodnost funkce filter.
Pokud se bude každé vlákno chovat správně, pak se bude chovat správně i ve vícevláknovém prostředí (záměrně opomíjím komunikaci mezi vlákny, protože té se funkce filter netýká).
[12] Nebezpečné konstrukce mohou být použity, pokud lze zaručit, že nevykonají nic špatného, třeba operátor++ u většiny iterátorů udělá to, že inkrementuje svůj vnitřní ukazatel, přitom konstrukce it != end zaručuje, že nepřeteče mimo svoje pole (u std::list to zrovna nedělá kvůli povaze listu).
Z C++ se nemusí nic odstraňovat. Je nutné si být vědom, co děláš, ne programovat jako zběsilý (jak to dělá spousta javovských pisálků).
[14] .NET neznám, ale přetečení hodnoty v Javě výjimku opravdu nevyhodí. Pokud programátor netestuje návratové hodnoty, je prase. V C++ jsou také výjimky.
Pořád pleteš C a C++. V C++ se strcpy nepoužívá (a ani tam není explicitně definované, je pouze uvedeno, že je v cstring), v C++ jsou std::stringy (a ani ty strcpy nepoužívají). Ale i kdyby strcpy bylo vhodné použít, pořád lze ověřit, že bude kopírovat správně, pokud je použita ve správném kontextu (víme, co je na vstupu i na výstupu).
