This time we're going to be looking at different parts of the visual studio D bugger you should be using.

It doesn't matter how good a programming you think you are.

Eventually, you're gonna need to debug something.

And if you watched any of my videos, you know that I'm quite a fan of the visual studio tools, and they've got some very powerful features that can really help you debug your code.

The eight bits in this video aren't in any particular order this time.

What should be enough to give you a good understanding of the D boogers capabilities so you can experiment for yourself?

Let's get started.

I'm sure if you programmed in visual studio, you're quite familiar with how to compile and run your program.

And if you run the d bugger, your program runs and exits and we get some outputs and you might have a little council window or logging facility, which he could have used to captured that what your program is done.

However, sometimes it's a lot more useful to just look your programming running in real time.

Now you may notice I've popped a little keyboard on the screen, and this is to show you some of the keyboard shortcuts that I'll be using in visual studio with any D bugger.

The first and most important part is actually getting to the code, But you want to de book.

You don't want to start from the very beginning of your program every single time.

So I like to press the cursor where I wanted to be on.

Then press the control and F 10 buttons.

And as you can see, the D bugger has started on this yellow arrow here indicates what line of code is about to be executed.

Let's take a minute just to set up the environment to something useful.

If you go to the debug menu, appear in select Windows, the things that you'll want to see are the autos locals, the call stack, possibly the feds on a memory window.

You want at least one memory window.

That's enough to get started.

So knowing that Control and F 10 will start and run to a location just pressing F 10 on its own will execute it line by line.

Let's first have a look out to the locals window, the locals window will display all of the variables that are in the current scope of your program.

Now my program only contains in Maine sweaty variables I've defined are all local, and we can see here for this in a it's appear and it's currently not.

That's a value.

That's because, of course, it's not been defined yet.

This line of code has not been executed.

As soon as I press half 10 we see that a has assumed the value seven on it, recognizes of type end Press F 10 again, and we've executed the next line.

Now where value be has been attributed the value eight and it's a float and so forth we can see as we step through the code.

These update themselves automatically when we use a more complex type, but something well established within the c++ language.

Like a string, the de booger also actually makes it quite useful to see what the contents of this string is.

So we know that behind the scenes of string is effectively a link list, but the D burger is intelligent enough to tell us.

Actually, it's a string on the value of the string in this case is hello.

By selecting the arrow next to the S here on, it's a type string.

It could be expanded to show what the string consists off so we can see its size.

We can see how much memory has been allocated to representing this string, and we can see the individual elements here in the container.

This hierarchical way of looking at data is quite common in the de booger on it will do the same for strokes and classes.

This, of course, is a different way off storing a string.

If we just allocated buffer directly, we can see who appear.

The buff has been allocated as an array, including the ah, the escape character.

This is the D bugger being quite clever, and it recognizes that both is actually a char on.

It will just keep displaying the data associated with this char pointer until it reaches the escape character.

Another powerful, yet potentially dangerous feature of the deep ogre is you can edit the values off the memory.

So if we wanted to change the value of Interview A, which is currently seven to something else, let's say three.

We just double click on it and set the value.

And that's it.

It's done.

It is now three, even though in our code it's quite clearly seven on.

We haven't done anything to set it, but we have changed it behind the scenes.

Sometimes another useful thing to do is to set this to Hexi decimal display, where we can see the hex equivalents of the values.

This may look untidy at first, but later on, if you're starting to work with bit strings and bitter raise, this could be quite a useful tool leading straight on into bits.

Seven.

We can see how Pointers Air also handled by the de Booger, using the variables I created earlier.

I'm going to create a couple of pointers to those variables.

So in this first line here, I'm creating an interview pointer to the variable.

Eh?

If we have a looking at the booking window, we can see that P A.

Here is currently undefined.

That's the zero x c C C C c.

I'll pop this back into decimal view, and we see here some curly brackets with some question marks in this is the D Boger, telling us what the value is at that point of location and is currently undefined.

So let's define it by stepping to the next line of code we can now see The Pointer has been given a memory address on it contains the value seven and this is we're having a memory window can also be quite useful.

We can just click and drag that address into the memory window and have a look at it directly, and we can see, of course, appear in the first element is our four bites.

Representing the interview on its value is seven.

If we wanted to, we can change the value of this memory by right clicking on selecting added value.

Any memory that changes gets highlighted red, and we'll see a bit more of this later home.

Let's have a look now at the floating point pointer, we can see the deep bugger knows what type it is and displays the data accordingly.

And if we have a look at this in a memory window, this is the hex decimal equivalent of our floating point value, which, of course, doesn't make much sense to mere mortal humans.

So to make this more readable, you can right click and choose a particular data format to display.

In this case, I know my floats are 32 bit floating points, so I will change the memory display to 32 bit floating point on.

We can see the first value is eight, which is the actual value that the pointer is pointing to.

Let's put that back.

If I press F 10 again, we've now given the P both somethingto look out.

We've given it the value buff, which was our character string before.

And as you might expect, there's little difference between the buffer created here.

And he pointed to the buffer created here because they are one and the same.

But if we drag that over to a memory window and have a look, we see that some hex decimal characters here, which represents our world and actually shows you that in the memory with an asking interpretation.

Off the Hexi decimal characters bit sixes about navigating functions, using the deep Okay, so if I control in f tend to this line, it's executed all the code that we saw before, and we can see where we are in our current call stack.

At the moment we're just in Maine, highlighted by the blue line appear on.

There's a little yellow arrow telling us where we are now.

If I pressed F 10 again, what's going to happen is I'm going to step over that line.

It has executed the line of code on.

We can verify this by looking at the local variables it says appear.

Function one returned the value 49 which if we go and have a quick look at function one by expanding it, we could say it's just the square of whatever the argument.

Waas, however, what if we wanted to debug function one?

Well, we have two approaches.

The first is we can select a line in function, one that we want to de book and press control in F 10.

Of course, our program will go on to that line, and if we have a look at our call stack, we can see Mayne was the original function that was cold, which is here on.

We've now called our function one.

Once you're inside this function, we compress F 10 to step through the code as normal.

And when we get to the end of the function, pressing of 10 again will take us to where our program currently is up to.

The second way to debug the function is to control in F 10 to it, and you can now press F 11 to step into the function on back out.

Stepping into an over functions on any other kind of call in your program is vital to debugging as there's pretty much always a 1 to 1 relationship between the nature of how you're stepping on the order off the program execution.

However, this is where things get a little bit daunting.

Let's say I control in F 10 to this string declaration.

Well, of course, we know that string is actually an object is not a primitive type.

So if I pressed F 11 I start to step into the constructor off the string and you can see it gets quite complicated.

I start stepping through this code.

We can see how everything works, but I'll be pressing F 11 for a long time here.

So sometimes I need to step out off the code and two step out of a function it shift in F 11 hold down the shift hold on F 11 and Eventually I get back to where I waas.

The code is still executed, even though it's called stepping out.

And now I can just press f tend to carry on as normal bit five breakpoints.

Break points are very traditional way of debugging on for visual studio.

You can set the break point by selecting the line and clicking somewhere to the left here when we set it like a big red circle appears on.

This will tell the running program to stop when it gets to that coat.

So I'm not going to press control and have 10 this time.

I'm just going to run it and we could see with the yellow arrow is where we're up to our execution.

It stopped at the break point.

I personally don't tend to use this very much, and I prefer control in at 10.

However, it does have some useful advantages.

Take this code, for example.

I have a little four loop that's doing something repeatedly, but let's assume I discover a bug were something only starts to effect the program when eyes equal to value 55.

I could sit here now pressing F 10 on monitoring the variable window appear are monitoring the value of eye until it is equal to 55.

I'll be here all day and said, What I can do is set a more intelligent breakpoint.

So I said to break point and click on the little gear next to it.

And the condition I'm looking for is that the break point is only active.

When I is equal to 55.

Let's close the window and run our program.

So the program has stopped.

I put my cursor over the I value.

I can see Yep, Eyes 55.

That saved me quite a bit of time.

But what happens if I don't have a value to break on?

One of the things I can do is say Please only break once.

That break point has been hit a certain number of times.

So to do that, we're going to the breakpoint settings, choose a condition and we can choose hit count.

So when this particular line of code has been executed, say 55 times again and we run it, we can see the break point has now been hit on the 51st iteration of this loop, where, of course, eyes is 54 now, but that's OK.

I'm close enough.

I don't mind stepping through a couple of lines.

Bit.

Four passes and Visualize is now.

This is quite a modern feature of the visual studio D Bugger on.

I'm sure this is a section of it that's going to expand in the future.

Visual studio now contains ways off displaying more complex data times.

So in here I've created String, which contains some HTML code, such as the body on DA Link.

Andi.

I've also got a Jason object, which I've pinched from the Jason website from the example page on.

Yes, they look.

They look quite terrible, but it is a popular way of manipulating data.

Let's see how the deep ogre handles these.

So I'm going to control an F 10 to it, and we'll look at the HTML on first, so we'll find available at the moment.

It's not been defined as anything, but as soon as I click on here, we can see it's just a string for all intents and purposes.

But right next to it, there's a little magnifying glass, and I can choose how wish to visualize this string and if I choose the HTML visualize er, it actually displays HTML, and this is the link that we created.

In fact, it's so good I can click on the link and it takes you to my website.

This isn't a fully functional html Dreiser, but it's good enough.

A similar thing happens for the Jason object the Jason object now contain to string.

So let's have a look at that using wth e Jason Visualize er well, I should expect it breaks it up into the tree.

Frustratingly, though it doesn't actually let you edit anything within the Jason object.

Maybe that will come in a future version.

In fact, I'm quite sure that, as development of the visual studio de Booger continues, we'll see this list grow and grow and grow with lots of common data types.

Bit.

Three.

Edit and continue.

And this is where we're going to start really breaking our programs and doing lots of dangerous debugging strategies.

But you'll never know.

They might just help you out occasionally.

Here, I've got two identical lines of code.

I'm calling my function with same argument on just giving it to a different variable each time.

Well, if we look at the code.

From my function, we can see it, simply squares the value and returns it.

So for the first value, I'd expect 36 and put my cursor over a one here and we see.

Of course, the value is 36.

We can validate that by looking at the locals window.

Just point out the autos window at the moment is like a summarized locals version.

So the de Booger has decided.