[? DAN ARMADARAS:?] Hi, Ek is [? Dan Armadaras?]. Vandag, ons gaan kyk na debugging. Nie net gaan ons praat oor 'n paar tegnieke, maar ook ons ​​gaan om te kyk na sommige van die funksies vervat binne die CS50 IDE wat toelaat jy maklik 'n program te ontfout. Net een voorbeeld van iets wat verkeerd kan gaan en dit is eintlik iets wat ons reeds gesien het nie. In hierdie geval, dit is 'n C program dat 'n heelgetal aanvaar van die gebruiker, verdeel dit deur twee, en bied die uitset terug na die gebruiker. En van wat ons gesien het vroeër in lesings, ons weet dat hierdie eintlik sal veroorsaak spesifieke tipes afdeling probleme wanneer ons onewe getalle. 

Spesifiek, sal ons net weggooi niks na die desimale punt. Nou, ons weet dat hierdie gebeur met die geval te wees. En as ons hardloop dit, kan ons bevestig ons vermoedens, eerste, deur die opstel. En dan, deur die loop en betree 'n onewe getal is. 

Dit is niks nuuts nie. Maar dit is eintlik 'n voorbeeld van 'n fout wat kan bestaan ​​binne 'n groter program dit word moeiliker om op te spoor. Selfs al weet ons wat die probleem is, die ware kern van die saak kan probeer om te identifiseer spesifiek waar die fout voorkom, die identifisering van wat die probleem is, en dan Ensiklopedie. So bied dit as 'n voorbeeld van wat kan iets dat ons weet reeds, maar kan begrawe word binne ander elemente van die kode. 

So opening van hierdie ander bron kode lêer as 'n voorbeeld, hierdie afdeling probleem is nou deel van 'n groter program. Tog kan 'n bietjie wees bietjie slinks, en ons kan maklik in staat wees om identifiseer nie, veral aangesien ons dit net bespreek. Maar ons kan uitvind dat dit probleem kan bestaan ​​op 'n groter skaal. 

As ek dit stel en nou hardloop dit, tik 'n vreemde nommer, ons kan sien dat ons nie presies kry die uitset dat ons kan verwag. In hierdie spesifieke geval, ons kan sê dat ons wil al die getalle te tel van een tot 'n paar spesifieke nommer. En ons kan sien dat ons het 'n verskeidenheid van kwessies hier as ons uitdruk, eenvoudig, 0 en 1 wanneer ons verskaf 'n inset van 5. 

So het ons reeds weet dat daar is hier 'n probleem. Maar ons kan nie presies weet waar hierdie kwessie werklik bestaan. Nou een van die maniere wat ons kan probeer om dit op te los is iets wat ons het reeds met. Ons kan net gebruik dit op 'n groter skaal. 

On line 14, ons het hierdie printf funksie, wat ons toelaat om die druk van die staat van verskeie stukke van inligting. En dit is iets wat jy moet hefboom binne jou program om te probeer om uit te vind presies wat gebeur in verskeie reëls van die kode. So selfs al is dit nie die finale uitset dat ons eintlik wil produseer uit hierdie program, steeds ons dalk 'n debug het state waar ons kan probeer om uit te vind presies wat gebeur binnekant van ons kode. 

So in hierdie geval, sal ek printf met die debug tag. In hierdie geval, dit is net 'n debug string dat ek up-om sodat dit baie duidelik in die produksie van my kode wat dit is wat ek wil om te wys. En uitset hier die aantal dat ons bereken. 

In hierdie geval, kan ek wil presies weet wat voor gebeur en na 'n paar spesifieke berekening. So ek kan 'n printf gebruik voordat en na die lyn van die kode. In hierdie geval, ek kon selfs maak dit 'n bietjie meer duidelik deur te sê debug voor en ontfout na so dat ek myself nie te verwar met verskeie reëls wat identies lyk. 

Nou as ons dit en hardloop heropstel dit 'n getal soos vyf weer ons kan sien dat ons nou uitset voor en na en vind dat ons nie gedoen het nie 'n duidelike afdeling of duidelik dat die aantal dat ons eintlik wil doen. Nou in hierdie geval, dit is nie regtig 'n duidelike uitset. Dit is nie regtig 'n duidelike uitkoms wat ons wil uit hierdie spesifieke program. 

En dit is, weer 'n bietjie slinks. Maar, miskien, een van die dinge wat ons kan doen as die spesifikasie gesê dat ons wil hierdie deel deur 2 en voeg 1-- so met ander woorde, ons wil dan up-- te rond ons kan weet dat ons kon doen daardie spesifieke ding, in hierdie geval. Nou hier weet ons dat ons sal wees in staat om 1 te voeg tot ons gehalveer nommer. 

Kom ons heropstel hierdie en bevestig dat hierdie gedra die manier wat ons wil. Ons kan nou sien dat voor met, ons het die nommer 5. Nadat ons die nommer 3, wat volgens ons spesifikasie, is wat ons wou doen. Maar as ons kyk na die uitset hier, kan ons sien dat ons 'n ander kan hê fout geheel en al, wat is dat ons begin ons telling van 0. 

Nou weer, dit is iets wat ons gesien het in die verlede en ons kan baie maklik op te los. Maar in hierdie geval, ons het ook die voordeel van die gebruik van die printf verklaring direk binnekant van die lus vir om te weet presies waar die fout is wat plaasvind. So printf state baie nuttig om te help jy bepaal waar presies in jou bronkode, 'n spesifieke fout voorkom. 

En dit is ook belangrik om te besef dat, soos ons skryf kode, ons kan aannames oor die toestand van 'n program. Of ons kan aannames oor wat deel van die program is eintlik reg of verkeerd wanneer later as wat ons bou op die program en maak dit deel van 'n komplekse en groter program dat ons besef dat 'n aspek van wat is eintlik karretjie. 

Die gebruik printf werklik kan help vernou en identifiseer die streke van 'n program wat nie kan word presies gedra die manier waarop ons verwag nie, op grond van ons aannames. Maar daar is ander instrumente beskikbaar, asook, wat ons toelaat om te probeer om figuur waar 'n fout is wat plaasvind en ook spesifiek die dinge wat gebeur binnekant van die program. 

Sodat die gebruik van printf is baie nuttig wanneer ons wil om spesifieke areas van identifiseer 'n program wat 'n fout het. Maar dit raak ook vervelige na 'n rukkie. In hierdie geval, dit is 'n relatief eenvoudige program met net een of twee veranderlikes. En dit is baie maklik vir ons om druk die waarde van daardie veranderlikes in die konteks van die groter program. 

Maar ons kan 'n ander het program wat baie veranderlikes het. En dit kan nie heeltemal wees so maklik om te gebruik printf om te probeer om te evalueer wat gebeur aan elke een van daardie veranderlikes as die program uitvoering. Daar is 'n program wat bestaan bekend as 'n debugger program. In hierdie geval, die een wat ons sal gebruik is die GNU debugger, of GDB, wat ons toelaat om die interne ondersoek werking van 'n program in 'n baie meer gedetailleerde manier. 

Ons kan eintlik voer GDB uit die opdrag lyn hier deur eenvoudig te tik en die GDB opdrag wat ons wil ontfout. In hierdie geval, tel. Nou in hierdie geval, kan ons sien dat dit bring ons by 'n spoedige dat GDB sê. En ons kan eintlik voer opdragte GDB om werklik te begin uitvoering van die program, stop dit by sekere punte, evalueer die veranderlikes en inspekteer die veranderlikes wat bestaan ​​in die program staat op daardie oomblik, en so aan en so voort. Dit bied 'n baie krag om ons. 

Maar dit gebeur net so dat die CS50 IDE ook bied 'n GUI of 'n gebruiker koppelvlak vir GDB dat ons toelaat om dit te doen sonder die command line interface hoegenaamd of glad selfs. Die manier wat ek kan toegang tot daardie is deur die gebruik van die debug knoppie by die top van die CS50 IDE. Nou in die verlede, wat ons het gesien is dat ons die opdrag lyn te stel en dan loop 'n program. 

Die debug knoppie doen beide van die stappe. Maar dit sal ook bring die blad debugger op die ver regs wat ons toelaat om 'n verskeidenheid te inspekteer eienskappe van die program soos dit die uitvoering. As ek op ontfout, in hierdie geval is, sal dit te bring 'n nuwe blad in die konsole venster aan die onderkant. 

En jy kan sien dat hierdie blad het inligting op die heel boonste. En ons kan grootliks ignoreer. Maar een van die dinge wat ons wil aan om in kennis is dat dit uitset dieselfde ding wat ons sou kry as ons probeer om te hardloop maak op die C-program in die terminale venster. 

Hier kan ons sien dit loop klang, en dit het 'n verskeidenheid van vlae, en dit is die samestelling van ons count.c lêer, wat die geselekteerde blad teen die tyd was dat ek getref debug. So dit is baie nuttig omdat nou die gebruik van hierdie debug knoppie, kan ons gelyktydig te stel en dan die program uitvoer dat ons eintlik wil hardloop. 

Een van die vlae wat belangrik is, in hierdie geval, Ons het eintlik al met behulp van vir die langste tyd maar ook net het 'n paar hand gewapper [onhoorbaar], wat is hierdie een hier. In klang, dit sê -ggdb3. In hierdie geval, wat ons is vertel klang, ons samesteller, is dat ons wil hê dat ons program saamstel. Maar ook wat genoem simbool inligting sodat die samesteller eintlik toegang om 'n groot deel van die onderliggende inligting vervat in die program. 

Meer spesifiek, die aantal funksies wat ek het, die name van die funksies, die veranderlikes, die tipes dat diegene veranderlikes is, en 'n verskeidenheid ander dinge wat die debugger help voer sy operasie. Nou is daar is iets anders dit is belangrik om te noem wanneer ons bespreek loop 'n program in hierdie manier. 

Let daarop dat dit eintlik gelei tot 'n nuwe blad in ons konsole langs die onderkant. Ons het nie meer om interaksie direk met die terminale venster. Maar hierdie nuwe blad is eintlik 'n terminale venster. Dit is net om die lopende spesifieke program wat ons geskep het. 

Let daarop dat aan die onderkant, in kombinasie met 'n paar uitset deur kletteren die samesteller en GDB, wat ons kan grootliks te ignoreer, dit eintlik toon die opbrengs van ons program op die heel onderste. Nou is dit belangrik om te besef dat dit 'n venster eintlik sal jou toon die uitset van jou program maar kan ook insette te aanvaar vir daardie program, as well. 

So wat sê kennisgewing Gee 'n getal, wat dieselfde uitset wat ons gehad het het in die terminale venster voor. Maar dit is nou getoon in hierdie nuwe blad. Ek kan 'n aantal insette. En dit sal eintlik funksie as ons verwag wys ons ons ontfout, uitvoer, die uitset wat kan wees karretjie, Soos ons vantevore gesien het. En op die heel onderste, dit het eintlik 'n paar ekstra uitset van die BBP net sê dat hierdie program voltooi het. 

Nou as jy gesien het in hierdie bepaalde loop deur, dit was nie besonder nuttige want selfs al het ons die debugger spyskaart kom up, was dit nog steeds 'n lopende program. Op geen punt het dit eintlik breek uitvoering vir ons in staat wees om al inspekteer die veranderlikes wat binne. Daar is iets anders wat ons moet doen ten einde om GDB kry om te erken dat ons wil om die uitvoering van die program breek en nie net toelaat dat dit om voort te gaan gewoonlik as ons sou in enige ander geval. 

Ten einde uitvoering te breek, op 'n sekere spesifieke lyn, ons nodig het om te skep wat is genoem 'n breek punt. En 'n breek punt is baie maklik geskep in hierdie CS50 IDE deur jou muis en aan die linkerkant klik direk van 'n paar spesifieke lyn nommer. Sodra ek dit doen, 'n rooi dot verskyn, wat dui dat daardie lyn is nou 'n breek punt. 

En die volgende keer dat ek hardloop GDB, dit sal ophou uitvoering op daardie breek punt wanneer dit die lyn van die kode bereik. Nou is dit 'n belangrike ding om te besef dat dit nie noodwendig die geval dat elke reël van die kode is eintlik toeganklik is. As ek 'n funksie te skep hier vir example-- leemte f-- en net nie 'n gedrukte lyn here-- hallo world-- as ek nooit hierdie funksie, dit sal die geval wees dat, As ek 'n breek punt hier, die funksie sal nooit genoem word. En daarom is dit veral breek punt sal nooit eintlik stilstaan uitvoering van die program. 

So kom ons sê dat ek korrek te skep 'n breek punt op sommige reël van die kode wat sal eintlik uitgevoer word. Nou in hierdie geval, dit is die eerste lyn in die belangrikste funksie. So sal dit beslis die geval wees dat, so gou as ek begin uitvoering, die heel eerste lyn sal bereik. GDB sal uitvoering breek. En dan, sal ek in staat wees om interaksie met die debugger. 

Jy kan verskeie lyne soos gestel inspeksiepunte, as jy wil. Ons kan ook 'n lyn te skep up hier in hierdie segment van die kode wat sal nooit bereik word nie. En ons kan ook 'n verdere hieronder. Die rede is dat ons sou wil hierdie ons sal doen gaan in 'n bietjie meer detail in net 'n oomblik. So vir nou, laat my net te skakel hierdie bykomende breek punte sodat ons kan kyk na wat gebeur toe ek 'n enkele break punt in my program. Ek het het 'n paar veranderinge aan hierdie program. So ek nodig het om dit te red. Ek sal op debug sodat ek kan begin die opstel en dan uitvoering van die debugger. 

Ons sal sien dat, na oomblikke, die lyn wat ons as die breek gekies punt is uitgelig in geel. Ons kan ook sien dat in die regs bo in die debug paneel dat die ikoon pouse het gedraai in 'n bietjie speel ikoon. Dit beteken dat ons breek uitvoering, in hierdie spesifieke geval. En slaan die Play knoppie sal ons toelaat om uitvoering te hervat op daardie spesifieke punt. 

Let daarop dat daar is 'n paar van die ander knoppies beskikbaar in hierdie debug paneel, ook. Stap oor, wat my toelaat om voer dat een reël van die kode en stap oor na daardie lyn na die volgende een, wat in hierdie geval, sou beteken dat die printf verklaring is uitgevoer. En dit sal dan breek uitvoering op die lyn 13, soos so. 

En daar is ook 'n stap in funksie, wat is nuttig as ek ander geskep het funksies elders in die bronkode. En ek wil om te stap in daardie funksies eerder as voer wat funksie as 'n geheel. Maar ons sal meer kyk na die stap in funksie in net 'n oomblik. Nou sien 'n paar ander dinge wat werklik bestaan ​​binne hierdie debug paneel. 

Ons het hierdie paneel het die noem stapel, wat ons wys waar ons presies. In hierdie geval, ons is binne- van die belangrikste funksie. Ons script genoem count.c. En ons gebeur op wees lyn 13, kolom een, wat is presies wat die gemerkte streek van die bron-kode dui, as well. 

Nou sien dat hierdie toon ook onder die plaaslike veranderlike artikel al die veranderlikes wat bestaan ​​binne hierdie funksie. Dit is belangrik om daarop te let dat al die veranderlikes verskyn in hierdie lokale veranderlike artikel binne 'n funksie, selfs nog voordat hulle gedefinieer word. Ons kan hier sien dat ons 'n veranderlike genoem num, het 'n standaard waarde van 0, en dit is van die tipe int. 

Nou voordat ons eintlik inisialiseer al hierdie veranderlikes, ons is nie noodwendig gewaarborg om 'n waarde van 0 te sien. En afhangende van ander teregstellings wat jy gedoen en die toestand van jou geheue wanneer jy eintlik hierdie program, jy dalk vind dat jy moenie waardes van 0 nie sien en in plaas daarvan, 'n ander gek getalle. 

Maar moenie bekommerd wees oor dit. Dit gaan nie relevant te word totdat jy eintlik inisialiseer die waarde. Nou in hierdie geval, kan ons sien dat Ek het 'n paar uitgevoer uitsette. En ek is, nou, gestop uitvoering. Maar in hierdie geval, wat Ek wil regtig om te doen is nou stap oor die lyn van die kode sodat ek kan eintlik soektog van die gebruiker vir daardie int wat ons wil gebruik in ons program. 

Nou in hierdie geval, toe Ek getref stap oor, kennisgewing dat die breek of eerder die CV knoppie verander om hierdie knoppie Stop omdat hierdie kode is eintlik die uitvoering. Wat gebeur nou is dat dit wag vir ons om insette inligting soos ons kan sien deur ons uitset teks aan die onderkant. 

So nou, dit is nie eintlik gestop, selfs al is dit, soort van, verskyn te wees, want niks gebeur nie. Maar dit net so gebeur dat in my spesifieke geval op die lyn 13, Ek wag vir die gebruiker insette. En so GDB is nie in staat om te inspekteer 'n program soos dit loop. 

Nou is die volgende keer dat ek 'n paar tree input-- so ek sal dat die getal 5 betree, soos ons gesien het in die past-- getref terug, en ons agterkom dat, onmiddellik, GDB pouses en weer, beklemtoon die volgende reël. Maar let dat nou, as 'n gevolg van ons skryf 'n waarde, ons het wat waarde binnekant opgedateer van ons plaaslike veranderlikes, wat is baie nuttig om presies weet wat dit was hulle aantal in die geheue. 

Nou kan ek toelaat dat hierdie program om voort te gaan speel tot aan die einde van die uitvoering daarvan deur slaan CV. Ons kan sien dat baie vinnig doen die program afwerking uitvoering met dieselfde uitset dat ons gehad het voordat die debugger sluit, en nou hierdie program het heeltemal opgehou. 

Ek toon dat slegs vir die doeleindes van sien wat gebeur wanneer ons eintlik getref CV. Maar ons eintlik gaan wil terug te gaan in hierdie program sodat ons kan probeer om debug presies wat gebeur. Nou dat ek die gebruik van die debugger, kan ek nie hierdie debug printf state nodig. 

So kon ek hulle te verwyder, sal ek doen as nou net om terug te gaan na ons eenvoudiger kode dat ons 'n oomblik gelede. En toe ek spaar die program en dit uit te voer, dit sal weer, gaan na dat die aanvanklike breek punt wat ek gehad het op die lyn 11. En ek sal in staat wees om te inspekteer my veranderlikes as wat ek wil doen. 

Dit gebeur net so dat dit deel is nie baie interessant, En ek weet dat ek gaan om uit te druk hierdie stelling. Voer asseblief 'n nommer. En dan, ek weet dat ek gaan aan die gebruiker vir daardie heelgetal te vra. So miskien, het ek eintlik wil beweeg my breek punt 'n bietjie verder af. 

Jy kan breek punte verwyder deur te kliek, weer, direk aan die linkerkant van die lyn nommer. Dat die rooi dot sal verdwyn, wat aandui dat breek punt nou is weg. Nou in hierdie geval, uitvoering is gestop. En so is dit nie eintlik gaan hervat in daardie spesifieke geval. Maar ek kan 'n breek te stel wys 'n bietjie later. 

En toe ek nou weer my kode, sal dit hervat en vertel die punt van daardie breek punt. Weereens, ek getref CV. Lyk nie soos enigiets gebeur. Maar dit is omdat my kode is wag vir insette. Ek sal 'n nommer 5 gaan, druk Enter, en nou die volgende breekpunt sal getref word. 

Nou in hierdie geval, dit is die reël van die kode dat, voor, ons het geweet gebeur karretjie wees. So laat evalueer wat gebeur op hierdie spesifieke punt in die tyd. Wanneer 'n lyn is uitgelig, hierdie lyn het nog nie uitgevoer is. So in hierdie geval, kan ons sien dat ek 'n nommer, wat Ek het 'n heelgetal genoem num dat 'n waarde 5 het. En ek gaan optree paar wiskunde op daardie nommer. 

As ek stap oor dat ons kan sien dat die waarde vir num het verander in ooreenstemming met die rekenkundige dat ons eintlik gedoen het. En nou dat ons binnekant van hierdie lus of nou dat die lus self is uitgelig, sien ons dat ons 'n nuwe veranderlike genoem i dat gaan gebruik word in die lus. 

Nou onthou voor dat ek genoem dat jy soms is gaan om 'n soort van mal te sien getalle as verstek voor dat die getal of dat veranderlike eintlik geïnisialiseer. Ons kan presies sien dat hier in die hierdie veranderlike genoem i, wat nie nog geïnisialiseer ten tyde van die klem op. Maar ons kan sien dat dit 'n paar nommer dat ons nie eintlik sou verwag. 

Dit is OK. Moenie bekommerd wees oor dit want ons het nie eintlik geïnisialiseer dat die getal, totdat ek stap oor die lyn en die waarde i is geïnisialiseer om die waarde 1. So om te sien dat dit is eintlik die geval is, laat ons stap oor. Ons kan nou sien dat daardie line uitgevoer is. En ons is nou die klem op hierdie printf lyn. 

En ons kan nou sien hoe ons waardes van i en 3 het verander met verloop van tyd. Dit is baie nuttig om te doen, in werklikheid, is om herhaaldelik stap oor lyne. En jy kan eintlik vind wat gebeur binnekant van jou lus en wat gebeur met die veranderlikes binnekant van die lus as wat die program uitvoering voorkom een ​​stap op 'n tyd. 

Nou op hierdie punt, ek gestap oor net genoeg dat ek nou aan die einde van my program. As ek stap oor dit, dit sal eintlik ophou uitvoering soos ons gesien het in die verlede. Laat my begin dit weer, so dat ek iets anders kan uitwys, ook. 

In hierdie geval, is dit my nou vra, weer, vir 'n aantal, wat Ek sal weer, betree. Maar hierdie keer, ek gaan om in te gaan 'n groter aantal sodat die lus sal Itereer meer keer. In hierdie geval, ek gaan om 'n waarde van 11 tree. 

Nou weer, want ek wil stel 'n breek punt op reël 15, dit gaan om daardie streep te lig. Ons kan sien dat ons nommer 11 is korrek verteenwoordig in ons plaaslike veranderlikes. Stepping oor daardie, kan ons nou kyk wat gebeur met ons waarde van i as ons voortgaan binnekant van hierdie lus. Dit word aangevul elke keer as ons bereik die top van daardie lus. 

Nou een van die dinge wat kan nuttig wees om te doen tydens uitvoering van hierdie program is vir my om eintlik verander die veranderlikes Midstream te sien Wat gebeur met my program. In hierdie geval, kan ek eintlik dubbel klik op die waarde. Let daarop dat dit 'n teks veld. 

Nou kan ek verskillende betree waardeer heeltemal om te sien hoe my program optree toe ek daardie veranderlike verander het. Nou in hierdie geval, die veranderlike i bevat nou die waarde 10. Maar die program is nog gestop in uitvoering. Toe ek stap oor, ek sien dat die waarde i, wat ek ingeskryf as 10, is nie groter as die waarde van num, wat veroorsaak onmiddellik die lus om te stop uitvoering. 

Nou is dit nie die enigste rede waarom jy sou wil die veranderlike in die plek te verander. Jy kan eintlik wil om te probeer om dit so te verander dat jy kan voortgaan uitvoering van 'n lus of sodat jy kan verander 'n bietjie waarde, voordat dit 'n paar spesifieke stel van rekenkundige bereik wat jy oor om te presteer. 

So nou dat ons eintlik verander die waarde van i as die program is die uitvoering, dit veroorsaak dat die lus om op te hou voortydig, want almal van 'n skielike, i gebeur groter as die waarde wees van num, wat beteken dat die lus nie meer nodig is om uitgevoer word. Verder, is dit gebeur met die wees geval dat ons verander die waarde van i wanneer die lyn 17 uitgelig, wat die punt in die tyd was dat die vir die uitvoering lus was eintlik geëvalueer. 

As ek die waarde van verander het i op 'n ander lyn, sê 19, ons anders sou gesien gedrag omdat lyn 19 sou voltrek voor die lus toestand geherwaardeerde. Nou op hierdie punt, ek is, weer, aan die einde van hierdie program. En ek kan nie toelaat dat hierdie om voort te gaan om toelaat dat my program om natuurlik hou. Maar daar is 'n paar van die dinge wat wat belangrik is om weg te neem is Van hierdie spesifieke bespreking. Jy moet evalueer jou eie aannames oor hoe die kode moet optree. Enige tyd wat jy dink dat 'n stuk van die kode wat jy ken gebeur om te werk, dat 'n rooi vlag gaan dalk rug en evalueer, en seker wees dat jou aanname van hoe dit code bedryf is eintlik waar om hoe dit is uitgedruk in jou bronkode. 

Maar nog meer tot die punt was, wanneer ons die gebruik van die debugger, jy kan breekpunte op sit verskillende reëls van die kode, wat die debugger om sal veroorsaak breek uitvoering by elk van die lyne sodat jy kan evalueer die geheue of selfs verander dit in die plek. En weer, onthou dat jy kan skep verskeie inspeksiepunte sodat jy kan ook hervat uitvoering, slaan oor groot gedeeltes van die kode, en dit sal outomaties breek by die volgende breekpunt. 

Daar is eintlik meer gevorderde kenmerke van die debugger, as well. Maar ons sal na jou verwys sommige daaropvolgende videos om werklik terg uitmekaar hoe om die spesifieke funksies te gebruik. Vir nou, dankie baie dankie vir die kyk. En voorspoed debugging.