New Release VC++ 2008 Startup Projects

[MeDiCS]

Building a debug version of your add-on is absolutely vital for proper testing and debugging of your code: beyond being able to step through the code with the debugger and inspect variables, debug versions fill unallocated memory with 0xCDCDCDCD or some other pattern so the add-on will crash if unallocated or freed memory is used as a pointer. In fact, you should only build a release version of your DLL when you are doing final testing before making some sort of public release, such as a beta release or later.

He isn't developing right now, so I see no problem in asking why he is compiling a debug version.

Also:

VC++ 2008 is my first Microsoft programming experience, so I might miss something important.

Depending on his experience, debugging this may be a bit too much right now.

 

[dbeachy1]

That said, I'd like to point out that it's absolutely imperative that you build release versions when you go to distribute it or put it up on OrbitHangar, because debug versions won't work without VS installed on the computer (or the necessary DLLs acquired elsewhere).

That's an excellent point. Yet another reason to only make release builds public is that debug builds will of course run somewhat slower than release builds. And don't forget to do some final testing with the release build as well before making it public.

One more note regarding public releases: it's always a good idea to ensure that your add-on's zip isn't missing any files by installing it to a brand-new Orbiter instance and verifying that it runs correctly (i.e., that no files are missing).

EDIT:

He isn't developing right now, so I see no problem in asking why he is compiling a debug version.

Also:

Depending on his experience, debugging this may be a bit too much right now.

With all due respect, I disagree. Speaking as a software engineer by profession, you should always start your project by using debug builds. Why in the world would you want to build a release build before even testing it?

As for the debugger, it is easy to use. And actually looking at the variables and stepping through the code at runtime to see what it is doing is an excellent way to learn it. Sooner or later any add-on developer worth his salt will need to use the debugger, so why put off using it? Speaking from experience, it certainly makes debugging much easier. Take the CTD, for example: without the debugger it's basically a shot in the dark trying to figure out which line in his project is causing it. Whereas with the debugger, the CTD will cause the debugger to pop up the line in the source code on which it crashed.

 

[Hielor]

One more note regarding public releases: it's always a good idea to ensure that your add-on's zip isn't missing any files by installing it to a brand-new Orbiter instance and verifying that it runs correctly (i.e., that no files are missing).

Ideally on a fresh install of Windows if possible, or a computer that doesn't have Visual Studio installed, so you can notice any other dependencies you might have introduced.

 

[MeDiCS]

With all due respect, I disagree. Speaking as a software engineer by profession, you should always start your project by using debug builds. Why in the world would you want to build a release build before even testing it?

As for the debugger, it is easy to use. And actually looking at the variables and stepping through the code at runtime to see what it is doing is an excellent way to learn it. Sooner or later any add-on developer worth his salt will need to use the debugger, so why put off using it? Speaking from experience, it certainly makes debugging much easier. Take the CTD, for example: without the debugger it's basically a shot in the dark trying to figure out which line in his project is causing it. Whereas with the debugger, the CTD will cause the debugger to pop up the line in the source code on which it crashed.

I can't really argue with a professional, specially because I don't have years of experience, but I prefer to use a combination of unit testing and carefully placed printf/fwrite/etc, than to push my hair until I have none trying to make sense of a compiler-generated assembly. This is, of course, when I'm the one writing the code.

Edit:
Just to complement before I read 'printf() debugging is noobish'. I only use this in rare cases when I can't phantom the reason my unit tests are failing. I also have time, and prefer to know what is going to happen exactly before writing the first line of code.