• Pages

  • Recent Posts

  • Recent Comments

  • Archives

  • Fri 25 Jan 2008

    Visual Studio 6 vs 2005 allocators

    Published at 17:43   Category C++  

    (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;


    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? =)

    Fri 6 Jul 2007

    EA STL

    Published at 9:28   Category C++, Game development  

    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.

    Fri 13 Apr 2007

    GCC – No newline at end of file

    Published at 15:09   Category C++  

    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 =)

    Wed 2 Nov 2005


    Published at 10:33   Category C++  

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

    Profiling is important, do it!

    Tue 18 Oct 2005

    Linking with .a

    Published at 18:13   Category C++  

    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!!

    Mon 10 Oct 2005

    How to Unmangle Names from the Linker

    Published at 17:13   Category C++  

    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

    Thu 10 Feb 2005

    Template Meta Programming

    Published at 18:20   Category C++  


    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 }; };
    Mon 31 Jan 2005

    An introduction to C++ Traits

    Published at 13:39   Category C++  

    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
    Thu 30 Dec 2004

    What will invalidate your iterators ?

    Published at 20:23   Category C++  

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

    Read more…

    Tue 2 Nov 2004

    Pointer Aliasing

    Published at 17:34   Category C++  

    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].

    Next Page >>>