B.3. Paranoid Programming

One of the constant paranoias in software engineering is the protection of intellectual property, and I've fallen under this particular spell in the past. Here's a little slice of horror.

The Win32 GUI programmers among you will be well aware of the features and shortcomings of the List-View common control. My first stab at enhancing them was done via MFC, multiple inheritance, and some truly evil tricks. The extended features—colored subitem text and background; per subitem user-data and images; 2D walking edit fields; and so on—were provided by the mixin class CColouredList.^[2]

^[2] Note the naïve use of the CClassName convention. I've heard that this was created to disambiguate the MFC core classes from any that users would create, but no one bothered to mention it to users or the folks writing the "How to write industrial strength applications in MFC in 24 hrs" books. This horrible convention persists in some areas to this day.

class DLL_CLASS CColouredListView


  : public CListView


  , public CColouredList


{


  . . .





class DLL_CLASS CColouredListCtrl


  : public CWnd


  , public CColouredList


{


  . . .

Without having any idea as to whether this component would even be desirable to any potential clients, I nonetheless spent great effort in hiding the implementation of the ever-so-smart control enhancements, by virtue of a delightful artifice:

class _CLCInfoBlock; // Forward declaration


#define _CLC_RESBLK  (208)





class DLL_CLASS CColouredList


  : public COwnerDrawCtrl


{


  . . . // Many, many methods


// Members


protected:


  HWND            &m_hWnd;            // HWND reference.


  _CLCInfoBlock   &m_block;           // Info block.


private:


  BYTE            m_at[_CLC_RESBLK];  // reserved.


};

I'm sure you've guessed the rest: the class _CLCInfoBlock is defined within the implementation file of the CColouredList class. In the constructor of CColouredList, an instance of _CLCInfoBlock is placement constructed into the m_at storage:

CColouredList::CColouredList(HWND &hWnd)


  : m_hWnd(hWnd)


  , m_block(*new(m_at) _CLCInfoBlock)


{}

Never mind the fact that an array of bytes is not guaranteed to have correct alignment for the in-place construction of a user-defined type, why on earth 208? The whole thing's just so awful. This amounts to malpractice in any reasonable estimation, and I can't conceive of anyone purchasing anything that looks like CColouredList.