I would advise you to avoid standard library in any exported method because even with the same compiler, the debug and release version of a std::vector can be different.
I have write a complex interface for a project inside my company, it must be compatible with Borland C++ 2009 and VS2010.
To manage this project using the following tips :
- I create my own template vector to have :
- same allocate memory method (new/delete/malloc/free are not compiler compatible)
- same data structure (std::vector do not have same data members in Borland and VS)
- calling convention forced to __stdcall (by default VS uses __thiscall which put the this pointer in the ecx register and not in the stack)
- to allow DLL evolution without recompiling the all project, I fixed interface (abstract class without any data members)
- avoid structure in return type (Borland and VS filled the returned structure differently)
To your class :
- keep any private data private : do not put them in .h file use class inheritance
- use basic type to transfert data : to fill (std::vector<t>&) use (T* data, size_t maxItem)
CMsg.h
#include "T_Msg.h"
#ifdef MSG_EXPORTS
#define MSG_API __declspec(dllexport)
#else
#define MSG_API __declspec(dllimport)
#endif
MSG_API IMsg* CreateMsg(unsigned char* data, int nLen);
MSG_API void DeleteMsg(IMsg* msg);
class IMsg
{
protected:
virtual ~IMsg() { }; public:
virtual int __stdcall ExtractListMsg(T_Msg* data, size_t nbMaxItem) = 0;
virtual int __stdcall ExtractBuffer(unsigned char* data, size_t nbMaxLen) = 0;
virtual void __stdcall Decode(unsigned char *data, int nLen) = 0;
virtual void __stdcall Encode(T_Msg& Msg) = 0;
};
CMsg.cpp
...
class CMsg : public IMsg
{
public:
private:
std::vector<T_Msg> m_ListMsg;
CWriteBit m_WriteBit;
};
...
I will not write all here, you will have to complete by yourself...