Undefined reference to class constructor

We've all seen it, but not all that often so in case you have forgotten the fix... as I did... here is the deal:

 undefined reference to `vtable for Namespace::Namespace::ClassName line # (end of constructor)

And you look and it all seems fine... but maybe you did some refactoring and left a method declaration that happens to be virtual, but is no longer implemented... (oops, I did)

Very helpful SO post on the topic and at the bottom the best info

The GCC FAQ has an entry on it:

The solution is to ensure that all virtual methods that are not pure are defined. Note that a destructor must be defined even if it is declared pure-virtual [class.dtor]/7.


Identify the extra method declaration and say goodbye to your linker error :-)

Extra namespace in compilation error

So one day you find yourself coding along, maybe even doing some refactoring... and you get a typical C++ compiler error, "line 37: ;Foo::Foo::Bar' has not been declared"

And you think to yourself, "self, I have a class Foo::Bar, but not Foo::Foo::Bar"...

Well, you probably don't, but you might have a missing "}" that is really changing the scope of your declaration and giving you this wonderful, but not so helpful error...

It's an error so easy a caveman could fix it!

How to avoid error "LNK2001 unresolved external" by using DEFINE_GUID

The GUID should be defined using the DEFINE_GUID macro in the guiddef.h header file.
Now the linker error can be removed by including INITGUID.H in the precompiled header file.

error C2011: '_DDPIXELFORMAT'

c:\program files\microsoft sdks\windows\v6.0\include\ddraw.h(703) : error C2011: '_DDPIXELFORMAT' : 'struct' type redefinition

This is a nice SDK integration error that I have face several times now and figured it is time to chronicle the solution... googling the issues does not net much that is helpful...

so I know this is a PCH issue, initially stdafx.h was this

// stdafx.h : include file for standard system include files,

// or project specific include files that are used frequently, but

// are changed infrequently

//

#pragma once

#ifndef _WIN32_WINNT // Allow use of features specific to Windows XP or later.

#define _WIN32_WINNT 0x0502 // Change this to the appropriate value to target other versions of Windows.

#endif

#include

#include

// TODO: reference additional headers your program requires here

//#include

#include

#include

and then I added:

#include

#if (MSC_VER <>

#include

#endif

and the error goes away....

Finding Memory Leaks using Divide and conquer

I just created/used this technique to find an elusive 8 byte memory leak in < 1 hr...

Let's take a look at the evolution of the technique:

The debugger is reporting a memory dump of {1510} normal block at 0x0B0774E0, 8 bytes long.

I began by looking at a suspected class and its members
Note: I set Watches to record memory locations to record addresses of the actual objects to be compared against the leak after application exit

Round 1 --
In object suspected to contain the leak:
+ this 0x0b080148 { ...}
leak @ 0xB0804E8 (okay looks like the leak is after this object)
+ m_AmpHandle 0x0b080280

+ m_CaptureDeviceName 0x0b080650
+ m_VolumeController 0x0b080640

Round 2 --
I tried to narrow down to member objects in the suspected class
+ m_OSVersion 0x0b0785fc
{1510} normal block at 0x0B0774E0, 8 bytes long.

Round 3 --
In object suspected to contain the leak:
+ this 0x0b077638
+ m_RenderDeviceName 0x0b0776c8
+ m_CaptureDeviceName 0x0b077648
{1498} normal block at 0x0B0774E0, 8 bytes long. (hmmm, maybe the leak is not in this object at all...)

Round 4 --
+ m_OSVersion 0x0b0785fc
+ m_AmpHandle 0x0b077690
{1498} normal block at 0x0B077998, 8 bytes long. (hmmm, the leak is after this handle... where does that handle come from?)

Round 5 -- moved investigation up a level
+ m_AdaptableVolumeController 0x0b0775c8 }
+ m_RenderFilter 0x0b080288
{1558} normal block at 0x0B083568, 8 bytes long. (hey, look at that... the leak is right in between these two, which probably means its in the renderfilter object)
+ m_CaptureFilter 0x0b0835b0
+ m_OSVersion 0x0b0785fc
+ m_AmpHandle 0x0b0776d8


Round 6 -- focusing investigation in the renderfilter
+ m_RenderFilter 0x0b0801b8
+ m_DolbyModel 0x0b080e70
+ m_GainModel 0x0b080228
+ m_ChannelAttenuationModel 0x0b080280
+ m_EAdvEqModel 0x0b0774e0
+ m_SimpleEqModel 0x0b0775f8
+ m_AdvEqModel 0x0b077698
+ m_AttMeasModel 0x0b0802d8
{1498} normal block at 0x0B0802D8, 8 bytes long. (HEY HEY! we have a match!)
+ m_CaptureFilter 0x0b077738


And it turned out that this pointer was not being deleted.

So with just standard tools, VisualStudio and Notepad you can quickly narrow down a memory leak.
Yes, one could just look for new/delete matches, but with a code base of a certain size this visual verification can be difficult to conduct.



















Divide and conquer algorithm - Wikipedia, the free encyclopedia: "divide and conquer (D&C)"

Can't link your library...?

Do you have new class and for forgot to fully implement it...?

e.g.
you have an error like this

MyLib.lib(MyClass.obj) : error LNK2001: unresolved external symbol "public: virtual long __stdcall MyNamespace::MyClass::SomeMethod(...)

MyClass.h declares
void SomeMethod();

and in
MyClass.cpp

you only put
void SomeMethod()
{
}

Looks okay, doesn't it?

it is close, but needs the class name for scope resolution
i.e.
void MyClass::SomeMethod()
{}

DeviceTopology.h include error

DeviceTopology.h include error: "DeviceTopology.h include error"
just nice to chronicle this very annoying error that only requires the NT version be 0x6000 to fix.