Take the 2-minute tour ×

At first some introductions: I am currently working on a C++ compatibility thing which means being able to run projects with different compiler options with each other. Therefore I test with a Release DLL and a Debug application linking to that other project. Most of the problems come up when using STL so I have to assure that both projects only use their own version of the STL. Thatswhy I have a wrapper class that can be build out of std::vectors, std::lists and so on but contains only an array which is completely compatible. Now I can wrap values in an array and unpack them on the other side into a valid STL object.

Now to get a bit closer to the question: There are some classes that contain STL but also need to be wrapped into an array. So I have to wrap the inner STL object, too, which means adding a tag and saving it right next to the associated array element.

Building up this wrapper class is no problem at all but unpacking it crashes with an access violation in the vector class right here:

   const_reference operator[](size_type _Pos) const
        {   // subscript nonmutable sequence

        if (size() <= _Pos)
            _DEBUG_ERROR("vector subscript out of range");
        _SCL_SECURE_VALIDATE_RANGE(_Pos < size());

        return (*(_Myfirst + _Pos));  <---- HERE

The executing code at that moment is this:

template<class T>
struct mwContainerItem
    T m_element;
    void * m_tag;

template<class T>
class mwContainer
    STLList ToList()
        STLList l;
        for(size_t i=0; i<m_size; ++i) <---- It crashes when accessing m_size
            l.push_back(m_elements[i].m_element); <---- It also crashes when accessing m_elements
        return l;

    mwContainerItem<T>* m_elements;
    size_t m_size;

The curious thing about it is I'm unpacking a std::list but it crashes in std::vector. Viewing at the whone thing I have a class contained by a std::vector and this very class contains a std::list of some basic class without STL. So unpacking means copying the outer array into a std::vector and every inner array into a std::list.

This error only occurs when I use the different compiler options, packing und unpacking in the very same project works just fine.

I really hope that anyone can help me cause I don't have any idea.


share|improve this question
Unfortunately, I believe there's no way to get around this without compiling with the same options. See: stackoverflow.com/questions/4446620/… –  Maxpm Jul 5 '11 at 9:39
There are some things you have to know about but after doing some changes to my code I was able to get it compile with this method. But it justs starts to crash on a simple 'recursion wrapping' where I don't see a problem at all if the concept works for an example without an inner STL object. –  Marcel Bonzelet Jul 5 '11 at 9:44
@Marcel why do you consider arrays compatible with different packing options? Usually they arn't –  user396672 Jul 5 '11 at 9:55
@user396672 They aren't? In my belief arrays are saved at the position of the pointer + i * the size of the object. I don't know why this should be different whether you use Release or Debug. But I'll check it right away. –  Marcel Bonzelet Jul 5 '11 at 9:59
@Marcel because the size of the object may differ. Compiler adds some padding according to structure packing –  user396672 Jul 5 '11 at 10:01
show 3 more comments

1 Answer

Do you really need two versions of STL? I mean, are you building the two projects with two different compilers, and two different STL implementations? When mixing debug and release versions, the problem usually comes from having two different heaps. Then, trying to release memory allocated in one module in the other, will cause an error. If this is the case you're facing, you could try another approach - have both use the same heap.

If you have control over both projects, you can export an allocator (and matching deallocator) from the DLL, and use it in the EXE. This way, memory management will be done on a single heap, and build type won't matter. You can use it in operator new, in a vector/list allocator etc.

This will probably not solve packing issues (who changes packing settings anyway?...), but it is something you want when using more than one heap.

share|improve this answer
Yes, I really need two versions of STL. Don't worry about the fact that I use two heaps because I found a way to handle memory allocation. What exactly do you mean by packing settings? I spoke of compiler setting differences such as in Debug and Release which make it hard to compile together. –  Marcel Bonzelet Jul 5 '11 at 10:49
@Marcel Bonzelet I'm referring to data alignment, either by using pragma pack, or the /Zp switch. Make sure they are the same - if you don't know what they do, there's really no reason for them not to have the (same) default. –  eran Jul 5 '11 at 11:24
I use the default in both projects. –  Marcel Bonzelet Jul 5 '11 at 12:13
add comment

Your Answer


