Registrace nového uživatele     Návod     Kluby     Archív  Lopuchu     Lopuch.cz  

Komu se nelení,
tomu se zelení.

Lopuch.cz

Jméno:
Heslo:
Podpora LCD:
 
Klub C, C++ [ŽP: neomezená] (kategorie Programování) moderuje Šéf Lopuchu.
Archiv

Články

Jak bezpečně ukončit vlákno z DllMain
FastAllocPool - urychlení častých alokací a dealokací
Akce a zpráva jako objekt
Tuply v C++
Efektivní alokátor malých objektů a tady druhý a třetí díl
Šablony: Být vládce kvalifikátorů
Vracíme z funkce objekty
Základy komunikace mezi procesy (ve Windows)
Multiple Interface a Instance Factory
Multithreading v C++ (ve Win32)
  Nastavení klubu     Nastavení práv     Homepage     Anketa     Přítomní     Oblíbené     Lopuch     Kategorie  
autor: 
text: 
vyplnit a 
Help
 Titulek, text příspěvku  
Opište pozpátku následující text bez prostředního znaku: mkvxgpy
[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  
bredy 1.7.2006 23:49  501
Kdokolivale co kdyz je otevriSoubor cizi API funkce
Správná otázka. Mohu tě ubezpečit, že co autor to vlastní systém zabezpečení chyb. Vem si kteroukoliv third-part knihovnu a uvidíš to sám. Návratové kódy, failstate objektu, výjimky, errno, last error, atd. Třeba WinAPI používá lásterror (GetLastError). Pro MT aplikace má každý thread vlastní proměnnou lasterror, takže se thready neovlivňují. Novější WinApi (Com+) používají HRESULT, což je číslo, dost šíleně sestavené obsahující typ chyby, id chyby, kód výrobce a kód modulu. v Com+ každá funkce buď vrací nulu (Ok) nebo HRESULT, a jiný návratový hodnoty nemá. V Alias Maya se zase chyba vrací přes pointer nebo referenci na proměnnou předanou jako parametr volané funkce. Pak si musíš status zkontrolovat. A ještě ve WinApi, třeba MFC pro objekty CInternetConnection využává výjimky pro hlášení chyb připojení k internetu.

V zásadě tedy, pokud používám cizí Api, buď si napíšu wrapper (i DirectX doporučuju ten čas tomu věnovat). nebo odchytávám chyby knihovny na nejnižší možné úrovni a používám schránku chyb. Kód chyby do ní předávám bez změny s tím, že si poznačím, o jaký modul se jedná. Při chybě pak vracím false nebo failobject (nebo NULL), s tím, že nadřazený level najde důvod chyby ve schránce (vidíš, to je trochu obdoba varianty last error, s tím, že zacházení s chybou lze na všech úrovních libovolně přetěžovat.) Pokud third part knihovna vyhazuje výjimky, snažím se je všechny odchytávat na nejnižší úrovni a házet do schránky (a dále již provádět řízený návrat).

To že se v C++ často výjimky v API nepoužívají je řekl bych kvuli jejich problematické implementaci. Překladač (aspoň tedy MSVC) je stále implementuje tak, že výjimky mají dost velkou režii i když je vlastně nepoužíváš.

Tady vlastně Java má něco co ani nepotřebuje, ale hodilo by se to do C++. Povinná specifikace throw u funkcí. Zatímco Java si poradí i s výjimkami, které někdo neočekává (např. NullPointer) takže by ani seznam vyhazovaných výjimek nepotřebovala, v C++ by se to náramě hodilo. Kdyby překladač výužil znalost které volání způsobí kterou výjimku, pak by si podle mého názoru stack unwind mohl odpustit a výjimku by řešil už v době překladu. Prostě by výjimka nebyla nic, než speciální návratová hodnota z funkce, a program by jen hodnotu odtestoval a v případně pozitivního výsledku by provedl příslušnou čistící část funkce (jenž by překladač připravil už během překladu) bez nutnosti znát který objekty je nutné vyčistit (protože právě by překladač dopředu věděl, kde může nastat výjimka).

Je zajímavý, že
try{
  Object1 a;
  Object2 b;
  Volani(); //haze vyjimku
}
catch(Vyjimka e)
{
  e.VypisPopis();
}

lze dobře implementovat. jako

  Object1 a;
  Object2 b;
  if ((Vyjimka e=Volani()).JeVyjimka) {e.VypisDuvod;return false;}

V prvém případě bude kód obohacen o několik instrukcí exception handlingu, v druhém případě o jeden test a čistící části, kterou zabezpečí příkaz return - kdyby se vědělo. že Volani vyhazuje výjimku Vyjimka, nemusel by přehladač vymýšlet žádný exception handling...


[ 380 ] <Novější  <<<Nejnovější  Nejstarší>>>  Starší>  

(c) 2001-2011 Lopuch.cz   
Kontakt