Nastal čas na kakao - Ladění - MujMAC.cz - Apple, Mac OS X, Apple iPod

Odběr fotomagazínu

Fotografický magazín "iZIN IDIF" každý týden ve Vašem e-mailu.
Co nového ve světě fotografie!

 

Zadejte Vaši e-mailovou adresu:

Kamarád fotí rád?

Přihlas ho k odběru fotomagazínu!

 

Zadejte e-mailovou adresu kamaráda:

Soutěž

Sponzorem soutěže je:

IDIF

 

Jaký fotograf/ka získal/a cenu za nejpopulárnější příspěvek v Nikon Photo Contest?

V dnešní soutěži hrajeme o:

Seriály

Více seriálů



Informace

Nastal čas na kakao - Ladění

21. prosince 2004, 00.00 | Ty nevíš táto to ti bylo k pláči, kos tuhle pral se s počítači a hledal chybu v programu... tedy, omlouvám se čtenářům i panu Halasovi; nechal jsem se unést nadpisem článku. Pravda ovšem je, že v minulém dílu našeho seriálu jsme si slíbili, že dříve, než se pustíme do přehledu služeb tříd objektové knihovny Foundation Kit, se blíž podíváme právě na ladění – tedy odhalování a opravy chyb.

Ty nevíš táto to ti bylo k pláči, kos tuhle pral se s počítači a hledal chybu v programu... tedy, omlouvám se čtenářům i panu Halasovi; nechal jsem se unést nadpisem článku. Pravda ovšem je, že v minulém dílu našeho seriálu jsme si slíbili, že dříve, než se pustíme do přehledu služeb tříd objektové knihovny Foundation Kit, se blíž podíváme právě na ladění – tedy odhalování a opravy chyb.

Chyby překladu

Pokud snad uděláme chybu, již může odhalit už samotný překladač – nejspíše půjde o nějaký překlep, zapomenutý středník nebo podobně – je to jednoduché. Xcode takové chyby automaticky zobrazí v okně (v záložce "Errors and Warnings"), a po klepnutí na kteroukoli z nich nám ji zobrazí v editoru.

To je jednoduché, prosté a samozřejmé; za zmínku snad stojí jen několik drobností:

  • Xcode nepřekládá nutně zdrojové soubory v témže pořadí, v jakém jsou zobrazeny v okně. Při delším překladu se proto může někdy stát, že vidíme zároveň chyby a varování ze současného i z minulého překladu (protože na odpovídající zdrojový soubor ještě nedošlo) – to může někdy být trochu matoucí;
  • Objective C, jako všechny jazyky, založené na jazyce C, dovoluje spoustu "prasáren", jež mohou být leckdy i nebezpečné; je proto vhodné důsledně kontrolovat i "warningy". Kupříkladu varování, jež je na minulém obrázku zvýrazněno, indikuje, že jsme zapomněli na znak '@' před řetězcovou konstantou, a kdybychom jej ignorovali, program by "spadl" (protože bychom se pokoušeli pracovat s textem jako kdyby to byl objekt);
  • Povšimněte si také druhé chyby ("statically allocated instance..."). Právě tak překladač Objective C hlásí zvláště mezi javskými programátory oblíbenou chybku – zapomenutou hvězdičku v deklaraci proměnné, jež obsahuje objekt známé třídy (tedy v našem případě "NSXMLParser xml" místo správného "NSXMLParser *xml").

Běhové chyby, ladění a gdb

Daleko zajímavější než chyby při překladu je hledání a odstraňování chyb běhových. Knihovny Cocoa a jazyk Objective C jsou naštěstí navrženy tak šikovně, že při dodržení základní opatrnosti obvykle programy fungují správně hned na první pokus; pokud tomu tak ovšem není, můžeme se někdy docela zapotit.

Problém může být právě v tom, jak vysokou úroveň služeb Cocoa nabízí: v "obyčejném" vývojovém prostředí, jež "za nás" takřka nic neudělá, můžeme snadno vyjít od funkce main a krokovat celý běh programu. V Cocoa to samozřejmě není možné – vždyť naprostá většina služeb je skryta kdesi na standardních knihovnách, a my jsme si je vyžádali jen nepřímo: kde hledat kód, který zajistí třeba korektní vazbu mezi obsahem textového pole a uživatelskými předvolbami, když jsme toho dosáhli bez jediného programového řádku, výhradně prostřednictvím "bindings"?

Každopádně, nenechte se vystrašit – tohle za normálních okolností problém nebývá, služby Cocoa vyšší úrovně "just work". Debugger potřebujeme většinou jen na odhalení případných chyb v našich vlastních algoritmech; a v tom, samozřejmě zhola žádný problém není.

Základní služby debuggeru jsou jednoduché a snadno jich můžeme využít přímo prostřednictvím grafického uživatelského rozhraní Xcode: do téže lišty, v níž se zobrazují chyby a varování při překladu, můžeme klepnutím myši na libovolný řádek umístit breakpoint, na němž se zpracování programu zastaví. Pak jen spustíme aplikaci příkazem "Build and Debug" (nebo jen "Debug", pokud víme jistě, že nechceme poslední změny ve zdrojovém kódu překládat):

Xcode otevře samostatné okno debuggeru a v něm spustí program. Na každém breakpointu se běh programu automaticky zastaví, a můžeme používat ovladačů v okně pro krokování programu, prohlížení obsahu proměnných a podobně.

Podívejte se na ladicí okno na posledním, třetím obrázku v tomto článku: lišta příkazů obsahuje ty nejčastěji používané služby (zvláště tedy "Continue", "Step Over" – která krokuje program, považujíc podprogramy a volání metod za atomické akce – a "Step Into", jež naopak do podprogramů a metod vstupuje). Zvláště pro ty, kdo pracují s rozsáhlými projekty, může být velmi zajímavá služba "Fix": ta umožňuje opravit zdrojový kód, a přenést opravu do laděného programu okamžitě – aniž bychom proto ladění ukončili a znovu spustili.

Ze dvou panelů pod příkazovou lištou je důležitější ten vlevo; v něm vidíme obsah zásobníku, tedy dynamický stav programu: seznam rutin a metod, jejichž kód vedl na současné místo v programu. Ty z nich, pro něž má debugger k dispozici zdrojový kód, jsou zobrazeny černě; můžeme na kteroukoli z nich klepnout myší, a v dolní části okna se zobrazí odpovídající kód. Panel vpravo obsahuje hodnoty hlavních proměnných aktuálního objektu i momentální rutiny; ty jsou docela šikovné, ale v praxi je mnohdy pohodlně nahradí konsole, o níž se zmíníme za chvilku.

V dolní části okna pak vidíme aktuální zdrojový kód se zvýrazněným řádkem, na němž se právě program nachází. V liště vlevo můžeme opět přidávat či rušit breakpointy. Chceme-li jen "o pár řádků popojet", není nutné přidávat dočasný breakpoint: stačí myší odvézt červenou šipku, jež označuje aktuální řádek, na požadované místo, a tam "pustit" – program se ihned spustí dál, a na místě, kde jsme šipku nechali se opět zastaví.

Pokročilejší programátoři jistě uvítají to, že Xcode neobsahuje vlastní proprietární debugger; namísto toho využívá zcela standardní a nesmírně silný ladicí program gdb. Jeho služby můžeme využívat prostřednictvím konsole; příkazem "Console Drawer" ji otevřeme, a v ní můžeme gdb řídit přímo pomocí jeho příkazové řádky.

Příkazů, jimž gdb rozumí, je nespočet, a nemůže je popisovat; jen se stručně zmíníme o těch nejdůležitějších:

  • pomocí příkazu help získáme podrobné informace o jakémkoli dalším příkazu;
  • příkazy p a po umožňují zobrazit hodnotu zcela libovolného výrazu (včetně výrazů, jež volají rutiny a metody z našeho programu!), jako čísla nebo jako objektu;
  • příkaz condition dovoluje omezit breakpoint velmi obecnou podmínkou – běh programu se na daném místě zastaví pouze v případě, že podmínka je splněna;
  • ještě bohatší služby nabízí příkaz command; jeho prostřednictvím můžeme libovolnému breakpointu přiřadit skupinu příkazů, jež se provedou kdykoli program na breakpoint narazí (na konci skupiny ovšem může být i příkaz continue, chceme-li, aby program bez přerušení pokračoval).

Obsah seriálu (více o seriálu):

Tématické zařazení:

 » Rubriky  » Informace  

 » Rubriky  » Agregator  

 » Rubriky  » Začínáme s  

Diskuse k článku

 

Vložit nový příspěvek   Sbalit příspěvky

 

no teda

Autor: Pepa Muž

Založeno: 21.12.2004, 10:36
Odpovědí: 0

Nic proti Vám ani proti Vašim vynikajícím článkům.
Ovšem zápis z prvního screenshotu
if (!url} error=@"bad URL"
else {
...
}

teda moc pozdější čitelnosti kódu nepřidají. :-)

Odpovědět na příspěvek

RE: no teda

Autor: OC Muž

Založeno: 21.12.2004, 21:21

To jsem nepochopil -- je snad na tom kódu cokoli, co by nebylo na první pohled zcela zřejmé??? Já tam nic takového nevidím?

Prostě a zcela evidentně, pokud se nepodaří inicializovat objekt "url", ohlásí se chyba "Bad URL"; samozřejmě v reálné aplikaci by bylo to hlášení lokalizovatelné, jenže lokalizační primitiva jsme zatím "nebrali", takže jsem to jimi nechtěl komplikovat...

Takže v čem je problém?!?

Odpovědět na příspěvek

RE: RE: no teda

Autor: Ondra Nekola Muž

Založeno: 22.12.2004, 09:21

Zrejme v indentaci.

Odpovědět na příspěvek

RE: RE: no teda

Autor: JJ Muž

Založeno: 22.12.2004, 14:16

No obecně se if dává spíše na samostatný řádek a následující příkaz se odsazuje... Je fakt, že číst Tvůj kód je pro mě občas obtížnější právě kvůli takovým drobnostem (a jedno- či dvoupísmenným názvům proměnných ;-) ).

Odpovědět na příspěvek

Styl; vice info o gdb

Autor: Adam Nohejl Muž

Založeno: 24.12.2004, 21:46
Odpovědí: 0

Dekuji za dalsi prima dil serialu. Zda je podmineny prikaz ve vzorovem kodu na stejnem radku jako podminka, je mi celkem ukradene. Kazdy ma svuj styl, a tenhle serial tu snad neni od toho, aby ucil stabni kulture.

Uvital bych ale delsi povidani o debuggeru. Vim, ze to je trochu mimo linii serialu, ale kdyz jsem to zahledl v tomto dile uz jsem se tesil... Neslo by to, Ondro? Co myslite, vy ostatni, mate jeste nekdo zajem?

Odpovědět na příspěvek

RE: Styl; vice info o gdb

Autor: OtO Muž

Založeno: 28.12.2004, 18:43

Pro Nohejla:NE

Pro OC:Tak jak je to podane, je to vporadku, diky.

Odpovědět na příspěvek

 

 

Vložit nový příspěvek

Jméno:

Pohlaví:

,

E-mail:

Předmět:

Příspěvek:

 

Kontrola:

Do spodního pole opište z obrázku 5 znaků:

Kód pro ověření

 

 

 

 

 

Přihlášení k mému účtu

Uživatelské jméno:

Heslo: