Properties in C++?

In the never-ending quest to reduce the duplication of data I’ve been consolidating some data structures into either native structures or managed classes (mainly depending on where they’re modified the most).

While doing this I’ve run across a bit of syntax that I hadn’t seen before in native C++:


I’m used to seeing properties in managed code and I suspect that the various managed C++ implementations (C++/CLI, managed extensions for C++) have something similar but this lovely expression compiled without complaint in plain old native C++.

What gives?  Native C++ doesn’t have properties does it?

The need to go digging has yielded thus:

  1. Microsoft C++ does in fact have properties.

  2. They’re defined via the __declspec keyword.

  3. The compiler translates them into the corresponding getXXX() or setXXX() methods.

  4. The #import directive takes advantage of this when importing type libraries exported from managed assemblies.  This translation from IDL to C++, gets stored in .tlh and .tli files.

See this link for an example of using properties in native C++.

How the Hacker puts your system into debt

In the past I’ve posted on some of the differences between the hacker school of coding and the non-hacker school of coding.  I recently encountered another anecdote along the lines of this thread.

The Hacker needs to provide users with a way to switch between multiple identical windows in a form.  It’d be nice to minimize use of vertical space since monitors tend to have less of it available and this application is image oriented.

Sounds like a job for a ToolBar/ToolStrip right?  It’s got all sorts of built in functionality for adding and removing buttons, responding to user events, customizing the appearance, OS theme support, designer support, etc…  It’ll even support runtime repositioning in case there are users out there that prefer to dock it against a different edge of the form.

Given such an easy way to provide the required functionality (and then some) why doesn’t the Hacker use it?

  1. He doesn’t know that it exists.  One thing I’ve noticed is that coders from the Hacker school tend to have average to below-average recall.
  2. He thinks he can write a better ToolBar.  Part of being a Hacker is not having a good grasp of the big picture.  So his analysis of better tends to ignore things like designer support, accessibility, OS themes, System Preferences, System Events, Display Resolution, etc…
  3. It didn’t occur to him to use a built-in widget.  Hackers don’t think this way.  Oftentimes they were trained in an era where there weren’t very many built-in widgets.  Being Hackers they wouldn’t have used them even if they were available. 

Each of these in some respects arises from the natural desire and concomitant tendency to “subvert the system” that is a hallmark of most Hackers.

Why does this matter?

By writing his own toolbar the Hacker has just raised the technical debt both for himself and for any other team members that have to work with what he has built.

One effect of technical debt is malfunction.  Situations where the Hacker’s homemade toolbar are likely to break: multiple monitors, large DPI fonts, different version of the Common Controls library, OS upgrades.  The homemade toolbar no longer functions as intended and/or no longer matches the native environment.  This debt costs time and money to track down and repair.  Often the Hacker is long gone or, if he’s still there, has completely forgotten the mechanics of his homemade toolbar.

Another effect of technical debt is interface mismatch.  Put another way, Hackers tend to produce software that doesn’t interface with other software well.  So not only does the Hacker make it harder for the team to do its job, he makes it harder for the company to take advantage of the work of others.

In any complex project there are going to be many instances where design decisions need to be made.  Some of these will be obvious, some less-so.  These will often provide a moment at which technical debt can be increased or avoided entirely.  Hackers, because of the reasons outlined in this and earlier posts, will almost always tend to choose the path that increases technical debt.

Do your system and your company a favor; protect it from Hackers.

Moving a project from Visual Studio 2008 to 2010

The project conversion wizard successfully converted the projects (with a few warnings).  The warnings were mainly about non-standard output locations (e.g., setting the targetpath to a common directory instead of using the default targetpath).

Caveats observed so far:

  • The C++ compiler apparently doesn’t like one of our multiline macros.  Since this is an old macro that’s no longer necessary and I generally find macros troublesome commenting it out addressed this issue.
  • The C++ compiler no longer supports targeting Windows versions earlier than Win 2000.  A few old source files explicitly defined _WIN32_WINNT at 0x400 (Win95/NT4!).  It’s probably a good thing that these had to be updated since we don’t target those platforms anymore.
  • SHGetSetFolderCustomSettings(), typically used for desktop.ini chicanery, is no longer supported.  It’s possible that this is showing up because we’ve corrected the _WIN32_WINNT preprocessor definition but since it was being used in a way that we no longer need (or want) this afforded an opportunity to do away with it.
  • The version of the Windows SDK that ships with Visual Studio 2010 doesn’t play nice with the DirectX August 2008 SDK.  So this had to be upgraded (to the February 2010 DirectX SDK).
  • The DirectX SDK no longer includes dxerr9.h/.lib and the utility macros DXGetErrorMessage9() and DXGetErrorDescription9() drop 9 from their names.
  • The build system now detects when a project references a library that targets a more recent version of the framework.  Updating the target framework for the project fixes this.

As was the case with the migration from 200* to 2008 most of the difficulties arise in native/unmanaged code.

Moving Windows Forms with Subversion and TortoiseSVN

If you’re using a subversion client that doesn’t have Visual Studio integration (e.g., TortoiseSVN) then moving a Windows Form can be a pain.  Here’s one slightly-less-painful way:

  1. Right click the form in Visual Studio’s Solution Explorer and exclude it from the project.
  2. Open up Windows Explorer, browse to the directory containing the Form.cs, Form.Designer.cs and Form.Resx files.
  3. Turn on Folders in Windows Explorer.  This will cause the folder tree view to appear.
  4. Select all three files, the right-drag (yes, Windows Explorer supports dragging a selection with the right mouse button) the files to the destination folder.
  5. When you release the right mouse button choose “SVN Move”.
  6. Include the files in Visual Studio project.  I usually do this by turning on “view all files” in solution explorer then using the context menu (right-click) to include the form.

That’s it.  Not too painful when you think about it but doing it this way keeps the linkage between the new location and the old location in subversion.