Visual studio code debugger size of variables
When we have something more meaningful contained in the variables, the descriptions will get longer, of course:Ī few tips about the entries in autoexp.dat: Given the volume of information in the matrix class, I decided to leave out the labels, simply listing the contents with each row separated each by a comma. The second is clearly longer - once again it uses the "g" type specifier for each of the 16 entries in the 4x4 matrix. I chose to leave in the labels, x, y & z, to improve readability. Without going into details, this means that they are floating-point values that should be abbreviated to significant digits only. The first is fairly simple: it simply tells Visual Studio to display each of the X, Y and Z values of the point, but using the "g" type specifier. Here are the two entries I added to the autoexp.dat file: So, let's look at what we can do for AcGePoint3d and AcGeMatrix3d. I'd also recommend looking at the various types listed in the file itself - as usual real-life examples often paint better pictures than abstract descriptions. Thereafter follow some specifics regarding the syntax - for an alternative source of information regarding this, you might also try this CodeGuru article. The part in angle brackets names a member of the type and an optional Watch format specifier. I won't reproduce the whole description of the format here, aside from this brief statement:Īn AutoExpand rule is a line with the name of a type, an equals sign, and text with replaceable parts in angle brackets. So what can we do? The autoexp.dat rules format is very simple and is documented in the header of the file itself. You need 5 clicks just to determine that the xform variable is actually the unit matrix, which is way too much. Here's what you get when you expand these two variables: The data displayed for xform (an AcGeMatrix3D) tells you nothing whatsoever of any use - it's the address of the 2D array holding the matrix contents. The default view of the pickpnt variable (an AcGePoint3d) is OK, but all those zeroes do make your eyes hurt. Here's the default view of two very common ObjectARX datatypes, AcGePoint3d and AcGeMatrix3d: So let's look at an example of the problem - as it relates to ObjectARX - and how this technique helps. The technique seems to be specific for native (presumably C++?) code, but the above link refers to techniques to implement this type of functionality for VB.NET and C#.
The clicks you use to get down to data all add up, especially when dealing with a particularly repetitive debugging task, so this feature can really be helpful. It's basically a text file that informs the Visual Studio IDE which information is especially relevant in a particular class, so that this information can be displayed automatically (and in the appropriate format) in the watch window, without you having to expand the various datatypes. The autoexp.dat file's default location (for Visual Studio 2005) is:Ĭ:\Program Files\Microsoft Visual Studio 8\Common7\Packages\Debugger\autoexp.dat During a recent technology discussion, Ahsan shared some information with our Bangalore-based team on some advanced debugging techniques, and I thought it would be a great topic for this blog.
This feature of the Visual Studio was brought to my attention by Ahsan Ali, a programmer in the Inventor Engineering team who was based over in Bangalore at the same time I was (we had both previously worked in the US - he had come across from Tualatin while I had moved there from San Rafael). OK, maybe that's not so long ago, relatively (11 short years), but the point is that in spite of having followed the Visual Studio technology over this period, I've so far been completely unaware of the autoexp.dat file.
I've been using Visual C++ (and afterwards Visual Studio) since it was 16-bit, back in version 1.52.