Rätt så mycket OT här, men håll tillgodo, några tips här kan vara användbara:
Citat:
Ursprungligen postat av
A-Good-Man
Vill bara förtydliga att allt jag skrivit tidigare i tråden handlar om att se variablernas värden i källkodsfilen när man debuggar. I Disassembly-fönstret däremot funkar det fint att se värdena utan att man behöver göra något.
Jag vet inte riktigt hur du menar ?
Ditt program måste vara i körläge, dvs under körning, för att du ska kunna se innehållet
i variablerna.
Men bara de variabler som finns i scopet.
De variabler som tex bara finns inne i tex loopar, dvs inom måsvingarna { }
är undefined och inte allokerade än, och kan enligt Standard C/C++
syntax innehålla garbage values. Detta beror helt på hur kompilatorn
har assemblerat koden.
Och från körtillfälle till körtillfälle.
Värdena hos sådana undefineds (tex utanför scopet) kan dessutom
variera från körning till körning.
Det krävs en hel del träning för att lära sig använda debuggern effektivt,
och tyvärr rätt så lätt att snöa in sig på detaljer.
Om du vill debugga tidskritiska sektioner så går det ofta inte att
singlesteppa källkoden/asmkoden, utan man får förlita sig på debugutskrifter, tex
det bekväma och lättanvända TRACE makrot.
Tex om man skriver device drivers som måste utföra instruktioner
inom vissa tidsramar. Så går de inte att debugga på vanligt sätt.
Det är synnerligen obekvämt att använda små skärmar för programutveckling och
en stor rymlig skärm är guld värd - man får otroligt mycket mera gjort, och ett helt "nytt
flyt" i utvecklingen, och att an känner sig som att ha full kontroll utan att behöva tex växla fönster
hela tiden.
Guld värt är också att ha en bekväm arbetsställning med ett rejält externt tangentbord och extern skärm, och en bekväm kontorsstol och en del föredrar till och med sk trackballs som man kan få flera funktioner jjämfört med en sk pekplatta.
Eller man kan tex ha två möss att växla mellan.
Vissa funktioner kan vara avstängda hos debuggern för att det blir störigt och rörigt i fönstret om det är för litet skärmutrymme.
Därför kan jag tänka mig att på Macar att skärmen är alldeles för liten för att vara riktigt användbar.
Optimalt brukar vara 3 skärmar, en skärm visar outputen från ditt rullande program.
En skärm visar IDE-fönstret, och en skärm har du manual-/hjälp-sidorna öppna.
En fjärde skärm kan tex visa header-filens deklarationer.
Lägg dig till med goda vanor redan från början.
Tex att varje steg som du tycker har lyckats med så kan du tex duplicera projektet och sedan fortsätta utvecklingen på den nya duplikatprojektet med de nya kopiorna av källkodsfilerna, så fortsätter du därifrån. Kom också ihåg dina egna headers.
Man kopierar då hela projektmappens träd med nytt namn, och bara fortsätter med en nya projektfilen.
En del jag känner, de klonar hela disken med OS, VS2022, och projekten, när de tycker att en version är färdigutvecklad. På så vis kan de "frysa" och starta sin utvecklingsmiljö från den punkten (klonen), och undvika att VS uppdaterar tex headers i onödan. Vet dock ej om man gör ett avsteg från licensavtalet men har dock inte stött på det själv.
Ett mycket intressant sätt att effektivisera debuggsessionen kan vara att använda remote debugging, förutsatt att du har två eller flera datorer. Du kan till och med debugga två eller fler program på det sättet om bägge programmen måste kommunicera/samverka med varandra.
Men manualhjälpen för remotedebugging är rätt så dålig, det enda som hjälper är träning och åter träning.
En gammal programmerarräv jag känner kör ibland sina skärmar i monokromt läge, dvs gråskala
för att han tycker att det ibland är störigt med syntax highlight och andra finesser osv.
Sedan är det en annan sak är det att han tycker att han ser skarpare i svartvitt läge.
Och har särskilda brillor.
Lycka till !!
