Question

I’ve been writing a DLL in C++, now I must call this DLL from a VB6 application.

Here’s a code sample from this DLL :

#include <vector>
#include <string>

using namespace std;    

void __stdcall DLLFunction (vector<Object>*)
{
 // performs a few operations on the Objects contained in the vector.
}

struct Object
{
    long CoordX;
    long CoordY;
    long Width;
    long Height;
    LPSTR Id;
};

I also defined the “Object struct” in VB6

Private Type Object
    CoordX As Integer 
    CoordY As Integer 
    Width As Integer
    Height As Integer
    Id As String 
End Type

The issue is I don’t know what vb6 type could stand for std::vector in order to call the DLL’s function.

Notes :
– I use a vector for the DLL to be able to add objects.
– I use a pointer in order to use as less memory as possible.
– Sorry for my english, it ain’t my home language at all.
– Thank you for reading and trying to help me.

Edit :
– I fixed the typing issues (Ids are definitely ended by NullChar, so LPSTR should do the trick).
– I read your answers, and I’d like to thank both of you, your answers are close to one another and a major issue remains. My DLL definitely needs to add elements to the container. Thus, I’m wondering how I could do the trick. Maybe I could add a return type to my function and then make that the function is able to return the items it created (instead of putting it directly into the container) so that the vb6 application gets these items and is able to process them, but I can’t figure out how to do this

Edit bis :

@Rook : I feel like I could achieve this by using a new struct.
struct ObjectArrayPointer
{
Object* Pointer;
size_t Counter;
}

And then call my function this way :

void __stdcall DLLFunction (ObjectArrayPointer*);

I would then be able to add objects and edit the size parameter for my VB6 application to find these new objects. Was that what you meant?

Answer 1

You should not be trying to export template containers from a DLL anyway. They’re likely to break when faced with newer compilers and libraries (eg. a library built under C++03 will not play well with code built using C++11).

The least painful thing to do is to accept a pointer to a buffer and a length parameter,

void __stdcall DLLFunction (Object* buffer, size_t nObjects);

if the size of the container will not change during execution. This interface is about as simple as it gets, and is easily accessible by any language that understand C calling conventions (eg. almost every single one.)

You’ve already thrown away most of the use of a std::vector because you’ve already specialised it to Object; you could consider going all the way and creating your own ObjectCollection class which uses a std::vector internally but presents a non-templated interface. Here’s a simple example :

// In your public API header file:
typedef struct object_collection_t *object_collection;

object_collection CreateObjectCollection();
void DestroyObjectCollect(object_collection collection);
void AddObjectToCollection(object_collection collection, Object* object);
// etc

No template types are exposed in any form in the header. This is good.

// And the corresponding code file:

struct object_collection_t
{
    std::vector<Object*> objects;
};

object_collection CreateObjectCollection() { return new object_collection_t; }
void DestroyObjectCollect(object_collection collection) { delete collection; }
void AddObjectToCollection(object_collection collection, Object* object)
{
    collection->objects.push_back(object);
}
// etc

All of templating code is hidden away, leaving you with a fairly clean and simple interface which present an opaque pointer type that can be passed around by external code but only queried and modified by your own, etc.

EDIT: Incidentally, I’ve used Object* throughout the above code. It may well be safer and impler to use just plain old Object and avoid all of the issues associated with memory management and pointer manipulation by client code. If Object is sufficiently small and simple, passing by value may be a better approach.

(NB: not checked for compilability or functionality. E&OE. Caveat Implementor!)