(If you didn’t sleep enough, don’t try to understand the following)

If one day you’re in Visual Studio 2005, creating an object that comes from a DLL compiled with Visual Studio 6, you might run into some allocators issues. Normally things go smoothly because your object is allocated and deallocated with the VC2005 allocator if you create it yourself, or by the VC6 allocator if you’re using specific creation functions that come with your DLL.

What can become very tricky is when this object has a virtual destructor, which means that your object was allocated with the 2005 allocator, but is deallocated with the VC6 allocator. This is not good, and will probably result in a crash nearly impossible to solve unless the above-mentionned DLL is re-built for 2005. Which may not always be possible if you the owner of the DLL doesn’t want to do it himself or give his source code.

Here’s a solution (I’m really happy we have code gurus here..) : allocate the memory for this object using the VC6 allocator. How do you do that? Easy (aha)! Simply load the VC6 runtime dll (msvcrt), find the pointer to the allocator function, and call it !

vc6handle = LoadLibrary(TEXT(“msvcrt”));

typedef void* (*vc6_malloc) (size_t _Size);
vc6_malloc vc6funcptr = (vc6_malloc) GetProcAddress(vc6handle,”malloc”);
TheClass* toto = (TheClass*) vc6funcptr(sizeof(*TheClass));
toto = new (toto) TheClass;

FreeLibrary(vc6handle);

You’ll notice that the new function takes the buffer that was allocated as a parameter. This is not the regular C++ allocator, but a custom one that can take a previously allocated buffer.

I won’t even explained how they did understand the problem …

Any question? =)

Electronic Arts has been writing their own set of C++ STL because the standard STL doesn’t fit gamedev constraints :

Gaming platforms and game designs place requirements on game software which differ from requirements of other platforms. Most significantly, game software requires large amounts of memory but has a limited amount to work with. Gaming software is also faced with other limitations such as weaker processor caches, weaker CPUs, and non-default memory alignment requirements. A result of this is that game software needs to be careful with its use of memory and the CPU. The C++ standard library’s containers, iterators, and algorithms are potentially useful for a variety of game programming needs. However, weaknesses and omissions of the standard library prevent it from being ideal for high performance game software. Foremost among these weaknesses is the allocator model. An extended and partially redesigned replacement (EASTL) for the C++ standard library was implemented at Electronic Arts in order to resolve these weaknesses in a portable and consistent way. This paper describes game software development issues, perceived weaknesses of the current C++ standard, and the design of EASTL as a partial solution for these weaknesses.

Just a small post to understand why GCC complains that there is “No newline at end of file” :

> What is the rationale for this warning ? What can break or is it a
> standards thing ?

Imagine foo.h:

blah blah blah

Now bar.c:

#include "foo.h"
#include "grill.h"

Now imagine a preprocessor that isn't smart enough to put
the newline in for you...

blah blah blah#include "grill.h"

It may not include grill.h.

That’s obvious but I never thought about it =)

This is the homepage of the profiling tool Callgrind (previously called Calltree) and the profile data visualization KCachegrind.

Profiling is important, do it!

So, another lesson learned from Sam…
Linking with .so and .a isn’t the same (appart from the static/dynamic part).
The order of the .a inclusion is important :

g++ -o bla bla.cpp x.a y.a z.a 

g++ will look at bla.cpp, look what symbols it needs and remember them. When loading x.a, it will only keep the symbols it has tagged before hands.
So if y.a needs an element in x.a which isn’t needed by bla.cpp, you won’t have it !!
So you should include y.a before x.a. If there are cyclic dependencies, it doesn’t matter if you include the same object twice.
Next headache please!!

Clark Dorman wrote:

"Comming with g+ +, there`s a tool called "c++filt". Give it a mangled name and it will demangle it for you." 

Example :

$> c++filt _ZN14daeSTLDatabaseC1Ev
daeSTLDatabase::daeSTLDatabase()

http://osl.iu.edu/~tveldhui/papers/Template-Metaprograms/meta-art.html

The introduction of templates to C+ + added a facility whereby the compiler can act as an interpreter. This makes it possible to write programs in a subset of C+ + which are interpreted at compile time. Language features such as for loops and if statements can be replaced by template specialization and recursion. The first examples of these techniques were written by Erwin Unruh and circulated among members of the ANSI/ISO C++ standardization committee 1. These programs didn’t have to be executed — they generated their output at compile time as warning messages. For example, one program generated warning messages containing prime numbers when compiled.

Here’s a simple example which generates factorials at compile time:

template<int N> class Factorial { public:    enum { value = N * Factorial<N-1>::value }; };

An introduction to C++ Traits, By Thaddaeus Frogley

 "Think of a trait as a small object whose main purpose is to carry information used by
   another object or algorithm to determine "policy" or "implementation details".
   - Bjarne Stroustrup

Things you need to know when you add/delete/swap elements from STL containers.. Read below for more.

Read more…

Pointer aliasing can have a severe impact on program performance. Understanding its implications is critical to writing high-performance code. [This document] provides a brief introduction to the problem, and suggests several approaches to solving it through source-code restructuring, compiler options, and C or C++ language extensions.

see also [this page] and [this pdf].