I can't find solution in Google. I looked at every setting in VS. I couldn't find it. Sorry for possible duplication. But how do I suppress all those addresses in the debugger output? I just want to see the value_=3 and "sand.texture".
Oh. Thanks to #Captain Obvlious I found right answer using format specifiers. Didn't know that Visual Studio have that thing. But here is an answer
Add variable to Watch
Changed that that variable to this [variableName],na
Here is an example:
Related
I am no expert in VSCode, but I saw that since version 1.38 there is the possibility to add watchpoints (a breakpoint which breaks when a given memory area is modified, a feature that is supported by many debuggers), at least for C/C++, see here https://jaxenter.com/vs-code-1-38-161797.html and here https://github.com/microsoft/vscode/issues/58304. Now my version of VSCode is 1.48.2, and I still can't figure out how to do it, and I couldn't find a proper explanation either. If anyone can give an explanation on how to do it (or whether it is possible), for sure it will very beneficial for me and for the VSCode community.
I personally use the CodeLLDB extension for C++ debugging as I use LLDB. The way I create a variable watchpoint:
Put a regular break-point at where the variable is defined
Upon hitting the break-point, find the variable in the Variables pane, right click, and choose Break When Value Changes
Well, i am feeling a little bit foolish asking something like this, but i' have no idea where the main function is in code i got from another person.
It's a pretty large Visual C++ project. So my question is simple, and please forgive me for asking this, but is there an easy way to find the entry point in a c++ solution in visual studio? It may not be called main, because there is a link to MFC tools (so perhaps WinMain).
Thank You!
Debug->Step Into used while you are not debugging should start debugging and will break at the entry point.
ctrl+, will give you some kind of search for member thing, then you look for your main function and it will possibly give you where it is declared.
I love using the Select/When/Otherwise statement in the data step, but my code always needs debugged before it will run properly. I never can remember the exact syntax required and SAS doesn't have very good documentation for it. (I actually can't find any mention of it except in the SCL documentation). Sometime it's because I put a semicolon after the When statements or forget that I need a Do block. Is this feature officially unsupported? If not then why isn't it documented?
Select/When/Otherwise documentaion
I have a couple of simple C++ homeworks and I know the students shared code. These are smart students and they know how to cheat moss. I'm looking for a tool that can rename variables based on their types (first variable of type int will be int1, first int array will be intptr1...), or does something similar that I cannot think of now. Do you know a quick way to do this?
edit: I'm required to use moss and report 90% match
Thanks
Yep, the tool you're looking for is called a compiler. :)
Seriously, if the programs submitted are exactly the same except for the identifier names, compiling then (without debugging info) should result in exactly the same output.
If you do this with debugging turned on, the compiler may leave meta-data in the executable that is different for each executable, hence the comment about ensuring it is off. This is also why this wont work for Java programs - that kind of info is present whether in debug mode or not (for the purposes of dynamic introspection).
EDIT: I see from the comments added to the question that you're observing some submissions that are different in more than just identifier names. If the programs are still structurally equivalent, this should still work.
EDIT: Given that the use of moss is a requirement, this probably isn't the way to go. I does seem though that moss has some support for comparing assembly - perhaps compiling to assembler and submitting that to moss is an option (depending on what compiler you're using).
You can download and try our C CloneDR duplicate code detector. It finds duplicated code even when the variable names have been changed. Multiple changes in the same chunk are treated as just one; if they rename the varaibles consistenly everywhere, you'll get back a report of "one clone" with the precise variable subsitution.
You can try Copy Paste Detector with ignoreIdentifiers turned on. You can at least use it for a first pass before going to the effort of normalizing names for moss. Or, since the source is available, maybe you can get it to spit out its internal normalization of the code.
Another way of doing this would be to compile the applications and compare their binaries, so your examination is not limited to variable/function name changing.
An HEX editor can help you with that. I just tried ExamDiff (not free $) and I was happy with the result.
I'm using the Intel compiler and visual studio and I can't seem to debug values that are in maps. I get a quick preview which shows the size of the map but the elements only show up as "(error)", I'll illustrate with a quick example, i've generated a map with a single entry myMapVariable[6]=1;
if I mouse over I get this "myMapVariable 1"
and in the watch window I get the same thing and expanding on the plus gives a single child entry which says name = "(error)" and value = 0 (which is wrong).
I've added a line to my autoexp.dat debugging file which shows the raw member variables under the child called [raw members]. I've pretty much reached the limits of my ability to dig into this further without help so I would ask if anyone here can provide some insights.
You're most likely using aggressive optimization settings. At least your screenshot is typical of that sort of thing. In that case, the debugger is actively stuffing hot values into registers, and it may be that, at the point you're stopped, the values that are needed to properly visualize the entire map are already discarded and overwritten by something else that is enough (like, say, a pointer to a current node). I would imagine that Intel C++, which is well-known for its high-quality optimization, does this sort of thing even more often than VC++ (but I've seen such with the latter often enough as well).
Consider recompiling the project in Debug configuration (which would disable the optimizer), and see if that helps.
My only suggestion is to make sure the map is initialized and in scope. Otherwise, I'm not sure, I've never seen this but I use VS2008 now.
I have never been able to fix this problem using Intel, but I have now moved to the latest visual studio compiler VS2010 and this is no longer a problem. I'm marking this as the answer because I don't want to leave unanswered questions lying around.