Visual Studio

Creating and calling functions is one of the most fundamental tasks in C++ programming. The function declaration serves as the primary description of a function’s interface - or contract - with callers, thereby making it the most important piece of code documentation. A good function declaration should convey as much information as possible. I’m sure an entire book could be written on the topic of function interface design, but I’ll just touch briefly on a few factors to consider when designing a function’s interface. ...

Let’s say you have an ObjectARX module with an implicit dependency on another DLL. Your installer puts both your ARX module and the dependent DLL into a private application folder. Windows must be able to resolve the implicit DLL dependency at load time, otherwise it will fail to load your ARX module. Alas, Windows will not automatically search for the dependent DLL in your application folder, even though your ARX module is located there. Therefore your ARX module won’t load because the dependent DLL cannot be resolved. ...

I often encounter cases in ObjectARX programming where numerous boolean flags need to be persisted as part of an AutoCAD database object. For filing and for passing around to other functions, it’s most efficient to package those bit flags into a single unsigned integer. Below is an example that demonstrates how to use a union inside a containing class that can be simultaneously used as either a single unsigned integer or as individual booleans. ...

If you’re developing ARX modules that need to be registered as a COM server, you’re faced with some decisions about how to register them. In the old days before anyone cared about user permissions, registration could be safely accomplished at runtime, even via AutoLISP. Unfortunately runtime COM server registration just doesn’t work reliably any more under limited user accounts, not to mention registry redirection on 64-bit platforms. There is only one reliable way to register COM servers, and that’s doing it at install time under elevated privileges. ...

The MFC version that ships with Visual Studio 2010 is known to cause major explosions in file size when you link statically. To avoid that problem, I use the Visual Studio 2008 build tools for such cases. I recently got quite a surprise when I rebuilt one such MFC application and discovered that the executable had ballooned from 400kb to 2MB in the space of one week despite only very minor changes. ...

If you’re an ObjectARX programmer, you may still be using Visual Studio 2008 because you’ve been told that you must. It’s true that you need Visual Studio 2008 installed to compile native ObjectARX code, but with Daffodil you can do all your work in the Visual Studio 2010 IDE. ...

Heap corruption bugs in C++ code can present some difficult debugging challenges. Often the actual corruption goes unnoticed until some apparently random point in the future when the corrupt memory is accessed by unrelated code. In such cases, it’s almost impossible to infer the location of the bug using typical debugging tools. ...

I have more or less completed the task of migrating my internal projects to Visual Studio 2010. Native C++ programmers are pretty low on the totem pole of programming coolness these days, but Microsoft did throw us a few bones. At this point I have to say I’m ambivalent overall with VS 2010, but I really like some of the architectural changes and I’m excited about the future. ...

I was hoping that Microsoft would address the need to target earlier versions of Visual Studio within the Visual Studio 2010 IDE, but since they decided to punt, I tackled the problem myself. I’ve released my solution as an open source project named Daffodil for Visual Studio. ...

[Update: See Visual Studio 2010 Native Multi-Targeting] Developers, if you use VC Build Hook and/or need the same capability in Visual Studio 2010, please let Microsoft know by voting for a fix. I’ve written before (and here) about the problem. I think it is possible to hack a third party solution, but by far the best solution is for Microsoft to add back the ability to produce ANSI response files in service pack 1.

Visual Studio 2010 shipped today accompanied by .NET Framework 4.0. I blogged before about the switch to using the MSBuild build system, and how that theoretically could be helpful in targeting multiple AutoCAD versions from the same solution. The shipping VS 2010 does not support non-Unicode response files, so out-of-the-box it cannot target VC 7.0 (for AutoCAD 2006 and earlier). When time permits, I’m planning to see if I can find a workaround; in the meantime, I’ll continue to use VS 2008 for ObjectARX.

[Update: See Visual Studio 2010 Native Multi-Targeting] Many of you use my VC Build Hook utility to target multiple versions of AutoCAD from a single solution in Visual Studio 2008. Visual Studio 2010 now includes a new feature called native multi-targeting that performs the same function as VC Build Hook. The new feature works great for using build tools back to VC 7.1, but it does not work with VC 7, which is required for targeting AutoCAD versions 2006 and earlier. ...