Sorry if this has been brought up before but is there a way to use a debugging tool locally? All the code can seem fine but fail a test. If that happens the project won’t build so I can’t debug. Is there a way around this? Debugging to see why a test failed worked fine on the C track.
I’m not sure I understand.
Are you talking about code that does not compile, or code that compiles but does not pass the tests?
If there are compilation errors you will have to look at the error messages and try to fix them.
If the code compiles you can debug it like any other program.
I’m not sure I understand either.
If you want to use the online editor, you can see the output of std::cout for the failed exercises.
In a nutshell I’m talking about catching semantic errors. It is possible to copy source and header file to a new project and write my own main then use a debugging tool there. Using cout all over the place is not fun. On the C track a test could fail and still the project would be built and I could watch variables. On the C++ track a failed test prevents a build.
Using a bad example (I can’t think of a specific one from an exercise right now), the goal might be to multiply some the input by 2.5 deep in a process. The code that’s written multiplies by 2, (whoops! shouldn’t have that result defined as an int) so the wrong result is being produced. If a test fails the project won’t build and you can’t watch variables. Yes, you can usually see the result in the test output but in more complicated code that might not be very helpful. You can also debug with many print statements but that is tedious. How do you catch semantic errors?
I’m not suggesting rewriting all the *_test.cpp but was hoping someone who know more about the test framework might know some preprocessor directives or something that could run the code inside a test and continue with the build even if a test failed.
You could move the #if defined(EXERCISM_RUN_ALL_TESTS) for each test. Everything that is inside the definition is ignored if you do not pass the flag to the compiler. So you can build even if some parts are not yet done.
That is the whole reason the macro is there in the first place.
You do not need to rewrite the whole test file, just move that line.
Yeah but the thing is that I don’t really care about the debugging the tests that pass, it’s the ones that fail that I want to debug
1 Like
Sorry for the late answer, here is what I use for debugging C++.
The simplest way to start debugging C++ is using VSCode. Depending on your environment, OS, etc, there are different tools required by VSCode as prerequisite.
- Visit VSCode page and get familiar with the C++ tools for your environment.
Introductory Videos for C++ - checkout one of the exercises and make sure it compiles, it doesn’t need to pass the tests, just make sure your environment is setup correctly.
- try to setup VSCode configuration as explained in 1.) and give it a try.
If the configuration does not work for you, you might consider adapting it. Sometimes, the step-by-step debugging does weird things. That is because the compiler optimizes the code and the code you see on the editor is not one-to-one to the code in the executable, therefore you might want to remove the optimization flags, (you will find these flag parameters in the args options).
Here is the setup on MacOS for nucleatide_count exercise, you might want to adapt it for your exercise.
.vscode/tasks.json:
{
"tasks": [
{
"type": "cppbuild",
"label": "C/C++: clang++ build active file",
"command": "/usr/bin/clang++",
"args": [
"-fcolor-diagnostics",
"-fansi-escape-codes",
"-g3", // Enhanced debug information
"-O0", // No optimization
"-std=c++17", // C++ standard
"main.cpp",
"nucleotide_count.cpp",
"-o",
"${workspaceFolder}/nucleotide_count"
],
"options": {
"cwd": "${workspaceFolder}"
},
"problemMatcher": ["$gcc"],
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
.vscode/launch.json
{
"configurations": [
{
"name": "Debug C++ Program",
"type": "cppdbg",
"request": "launch",
"program": "${workspaceFolder}/nucleotide_count",
"args": [],
"stopAtEntry": false,
"cwd": "${workspaceFolder}",
"environment": [],
"externalConsole": false,
"MIMode": "lldb",
"preLaunchTask": "C/C++: clang++ build active file",
"setupCommands": [
{
"description": "Enable pretty-printing for gdb",
"text": "-enable-pretty-printing",
"ignoreFailures": true
}
]
}
]
}
Then open the main.cpp, add a breakpoint (the red dot next to the line number) and runt Debug C/C++ file.
You will see the variables on the inspection panel on the right.
The main file will not call all the functions under test, but you can modify main. Add your code and play around calling whatever you want.