Out of the box Visual Studio Code is great but doesn’t do save+compile+debug very well.  The default debugging configuration just runs the debugger on existing code without saving or compiling first.

But the task system is GREAT and makes almost any possible automation pretty straightforward.  Here’s a quick example.  First set up any command line tasks you might need in your tasks.json file (Terminal > Configure Tasks > pick any task), eg:


{
    // See https://go.microsoft.com/fwlink/?LinkId=733558
    // for the documentation about the tasks.json format
    "version": "2.0.0",
    "tasks": [
        {
            "label": "echo",
            "type": "shell",
            "command": "echo Hello",
            "group": "build"
        },
        {
            "label": "Build cmake-debug",
            "type": "shell",
            "command": "clear && bash -i -c 'at dbd'",
            "group": {
                "kind": "build",
                "isDefault": true
            }
        },
        {
            "label": "Build cmake-release",
            "type": "shell",
            "command": "clear && bash -i -c 'at dbr'",
            "group": "build",
            "problemMatcher": [
                "$msCompile"
            ]
        },
        {
            "label": "cmake",
            "type": "shell",
            "command": "clear && bash -i -c 'at dba'",
            "group": "build",
            "problemMatcher": [
                "$gcc"
            ]
        },
        {
            "label": "Go",
            "dependsOn": [
                "Build cmake-debug"
            ],
            "problemMatcher": [
                "$gcc"
            ]
        }
    ]
}
That contains a few single-shot tasks, and another multi-task one called “Go”, where you can chain as many other tasks together as you need in the dependsOn array.  When you run Go, it will run the others in the specified order.  Here, you might note that I only needed one task in my chain (my one task does all the steps I need), but I want to future-proof by using a multi-task pattern.
From there, you can configure your … ermm.. configurations (Debug > Open Configurations).  That’s what code calls your debug task, and it’s more than a task as it figures out a lot about your compiler and debugger for you.  The configuration property we want here is called preLaunchTask, and we will specify our Go task so it runs right before the debugger starts up, eg:

{
    // Use IntelliSense to learn about possible attributes.
    // Hover to view descriptions of existing attributes.
    // For more information, visit: https://go.microsoft.com/fwlink/?linkid=830387
    "version": "0.2.0",
    "configurations": [
        {
            "name": "(gdb) Launch",
            "type": "cppdbg",
            "request": "launch",
            "program": "${workspaceFolder}/cmake-debug/at_server",
            // "args": ["localhost","8000","localhost","at_viper_dev_test","b0g0","test"],
            "args": ["localhost","8000","localhost"],
            "stopAtEntry": false,
            "cwd": "${workspaceFolder}",
            "environment": [],
            "externalConsole": true,
            "MIMode": "gdb",
            "setupCommands": [
                {
                    "description": "Enable pretty-printing for gdb",
                    "text": "-enable-pretty-printing",
                    "ignoreFailures": true
                }
            ],
            "preLaunchTask": "Go"
        }
    ]
}

I love my asserts. I use them like crazy throughout my code and catch errors faster than you and your whole testing department. :> The computer does exactly what I ASK of it, which sometimes is not the same as what I EXPECT of it. So I wrap up my expectations with assert macros so my computer friend and I stay on the same page. Happy happy joy joy.

In Qt, we have the Q_ASSERT macro. Qt default behavior is to abort on any Q_ASSERT macro failure. This is weird to me (even if it is common). Almost universally, I want to SEE what’s going on when I hit an assert. Sometimes the assertion turns out to be wrong and may need adjusting. Even if it’s right, sometimes it’s helpful to check the effect of the failed assertion. And certainly, being able to walk back up the stack trace is critical to determine where things went wrong. I can kill the program easily if I WANT to, but I may want to continue – it should be my choice. It’s a no-brainer!

So I don’t use Q_ASSERT. Here’s my cross-platform C++ assert macro hackery. It’s not perfect but it’s getting me by so far… (continued…)

I’m the last person to praise Microsoft – with the amount of money they bleed from the human race, there is no room to give them any slack. To their credit, corporations of their magnitude almost always decay into bureaucracy and inefficiency, and they could be worse. Case in point, Visual Studio. It kicks ass. Here’s a quick rundown of what it does for me when debugging my Qt app. This is in comparison to Qt Creator, which is awesomely streamlined and elegant. But when you are debugging, every bit of comfort is gold:

  • if you set things up as i did, you can step right through the Qt source with no pain
  • the watch window takes far fewer steps to manipulate
  • the debugger can dereference pointers better
  • the debugger can dereference iterators better
  • code completion in the editor can also handle dereferenced iterators
  • debugger can show long strings much better
  • you can step over a function back up to the caller without dropping to the next line of code in the call routine (for when multiple calls take place on one line)
  • debugger doesn’t head south when often browsing out of array bounds (inevitable if you are watching variables)

I’ll add to this list as seems fit. I should probably also start a list of the advantages of Qt Creator, it is really nice to work with on linux and Mac. Including Eclipse would round out the list nicely… but for now, back to teh coding. :> Check out this recent post for instructions on getting VS set up with Qt, it’s easy.

Qt’s Phonon library has an awesome goal: abstract video and audio services to simplify cross-platform development. It has worked great for me out of the box using Qt 4.7 on linux and Mac OS X. Windows setup took a bit of elbow grease. Here are the cheatnotes to get you through it quickly.

NOTE: The Qt mingw setup worked fine for me when I was setting up my first Windows development environment, do not hesitate to go that route. All you need is the Qt SDK for Windows. Free is good!

But this time around, I opted for using Visual Studio 2010, since I already had it installed and I wanted to compare. I’ve read that there is no support for using the open-source-licensed Qt with Visual Studio, but the official Qt download page for the Visual Studio Add-In clears things up – it says the add-in “can be used for development together with all Qt licenses”. Let’s fire it up and try it out! (continued…)

UPDATE: CDB (the Qt name for the Windows debugger) sucks – no variable monitoring, etc. Useless. If you can, switch to Visual Studio to build Qt apps under windoze. See these posts instead.

The last time I set up to build my Qt apps under Windoze, I just selected the Mingw option and everything seemed to work just fine. For some reason I fell down the rabbit hole of using Visual Studio this time. I could give two craps about that, I just want it to work and get out of the way. But I had to stumble through these steps first:

  • Install Visual Studio 2010
  • Install LGPL Qt SDK for Windows
  • Also install Visual Studio Add-in from the same page
  • Add c:\Qt\4.7.1\bin to the PATH variable.
  • Build Qt from a Visual Studio prompt:
    cd C:\Qt\2010.05\qt
    rm /S /Q c:\Qt\2010.05\qt\tmp
    nmake confclean
    nmake clean
    configure -debug-and-release -opensource -shared -no-qt3support -qt-sql-sqlite -phonon -phonon-backend -webkit -platform win32-msvc2003
    nmake
  • Install Debugging Tools for Windows 32-bit Version. Only install the shit in the red circle:

    Debugging Tools options

  • Then browse here:
    C:\Program Files\Microsoft SDKs\Windows\v7.1\Redist\Debugging Tools for Windows

    and run dbg_x86.msi to install the 32-bit stuff…

  • Then run QT, select Tools->Options, and select this path in the CDB tab:
    C:\Program Files (x86)\Debugging Tools for Windows (x86)

    … what bs…

  • Write some freakin’ QT code, geesh…