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.

Array as a function parameter...

This can be kinda tricky at first, but really it is just a matter of leveraging the convergence of the zero element of an array and a pointer of the same type.

so you have
int myInts[] = {1,2,3,4,5}
that needs to be passed into a function

so you just prototype the function:
foo(int* input);
and to use it just pass in the array:
foo(myInts);

Linker Tools Warning(s)

LNK4221:
You get this warning when you add resources to a static library. Okay, but what does that really mean?

LNK2001: unresolved external symbol, "symbol"
We have all seen this one, first thing I always check is the vcproj to ensure I told the linker to use someLib.lib; seems obvious, but it is easy to forget. In fact, I just did this very thing. And that simple mistake is captured here in this blog entry in hopes you will not have to make the mistake as often; don't fool yourself - we'll all still forget it sometimes....

LNK2005: symbol already defined in object
Just ran into this again... and #6 of MSDN's fixes is to add /FORCE:MULTIPLE to the linker comand line options, and make sure that uuid.lib is the first library referenced. but it did not help so my issue was something else.

Packaging libraries

So you have some code that is/was/should be a packaged as a library to isolate and encapsulate it... now it may have been directly compiled in a previous project, but now you need to isolate it.
First off, take careful examination of the code that was compiled in the previous project as it will most likely be benchmark for features. And if the new lib is not compiling the same set of files it will not be equivalent to the directly compiled code.

Chipset reviews

AnandTech does some very nice reviews

Intel Core i7

AMD Phenom II X4 945/955

Warning suppression

Maybe you are leveraging an older library (in compiler terms) that is using deprecated APIs and is causing warnings and the warnings suggest suppression using _CRT_SERCURE_NO_WARNINGS and instructs you to see online for info...

Well if you want to use this simply go into the vcproj C/C++ settings Pre-processor and add _CRT_SECRE_NO_WARNINGS to the list. Caveat, this is a broad stroke and should only be used if that code is segregated in its own vcproj and will not be actively developed. Code under active development should just adapt to remove the warnings.

Warning by warning suppression:
directly in the code it is possible to suppress individual or blocks of warnings like this,
#pragma warning (disable: )
code generating the warning
#pragma warning (default: )
the "warning#" would be the same number in both statements.
There is more than one way to do this, but that exploration is left as an exercise to the reader...

GLOSSARY OF TERMS, ACRONYMS, AND ABBREVIATIONS

VS = VisualStudio, may be followed by a version/year, i.e. VS2008
vcproj = VisualStudio project file
UM = user mode
KM = kernel mode

Precompiled Headers (PCH)

Having trouble with PCHs?


A couple common areas are:


"fatal error c1083: cannot open precompiled header file:

In your vcproj Configuration Settings>C/C++>PrecompiledHeaders you are using the option "Use Precompiled Header (/Yu)" your PCH may have never been created and you should change the option to "Create Precompiled Header (/Yc)"

Now at this point the PCH is being created with each build.

And doing this in a release build configuration may lead to

C4727 warnings, which occur when multiple files are generating PCHs (/Yc)

so you have to go through each file noted by the compiler and switch back to (/Yu)

UPDATE****

in the default configuration you will have stdafx.h & stdafx.cpp (this file is the only one that should have the /Yc option)