In talking with a friend I was reminded of one of my favorite WTF moments – correcting the answers on an interviewer’s tech questions. Once, while taking an interview for a position, the interviewer was going over my answers for the tech questions and happened to mention that one (or two?) of them were incorrect.

When I asked about them it turns out to have been questions regarding the size of C++ objects that have no data members. For example:

class CEmpty { };

class CEmpty2 { public:  void MyFunc( void ) { return; } }; 

class CEmpty3 { public: virtual void MyFunc( void ) { return; } };

So what is the size of CEmpty, CEmpty2 and CEmpty3? My answer was that it was basically implementation defined. The interviewer’s answers said that CEmpty and CEmpty2 had a size of zero, and that CEmpty3 had a non-zero size.

I had answered that CEmpty and CEmpty2 will have a implementation-specific/defined size (IME, a size of 1) and that CEmpty3 will have a size due to the vtbl that will be added to the class, and added that the size of the vtbl will not be added to the implementation-specific/defined size given to otherwise empty objects. (In other words, if the size of the vtbl pointer is 4 bytes, the object size will be 4, not 5.)

The interviewer, being a/the senior developer that I would have been working with or for, did not agree and we ended up with some code snippets being compiled and executed in the VC++ 6.0 IDE. Wanna take a guess who was correct?

It turns out that the company’s CTO decided not to accept me for the position. I was never told why (I otherwise aced the interview, of course), but I was told that the CTO created the interview questions (and answers). Go figure…!

Here is another example of code that demonstrates a complete misunderstanding of how things work, or at least of MFC and/or the RTL…

char value[256];
::GetPrivateProfileString("section","ValueName", "OFF", value, 256, INI_PATH);
CString temp(value);
temp.MakeUpper();
if (temp != "OFF")
{ ... }

Now, I can understand the need to do a case-insensitive compare of an INI file value.  But we have functions designed to do that!  Never heard of stricmp(…) and its variants?  OK – even if you do not know about the available RTL functions and all you know is CString, never heard of CString::CompareNoCase(…)?

Code like this just demonstrates ignorance, plain and simple.  Oh, and how goes that exception handling for situations where CString fails to allocate memory?  Oh, yeah…  THERE IS NONE!

Yet another real-world example of useless allocation.