COM as a way to implement the use of STL containers across a DLL
So using STL in a class that will be exported by a DLL is a big no-no due to problems with differently compilers packing data in different formats. With that in mind, would COM be a viable option for secretly using STL containers in an interface/class that you wish to share across a DLL? That way, the compiler only needs to know of the methods of the interface and not how the data is packed.
As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem.
I think COM style interface is the best (at least it's best to me) to work cross DLLs.
It has two dominant advantages,
1, Binary compatibility. There is only function pointers in the interface with fixed layout (one pointer after another).
2, Safe memory management. No explicitly free function, all resources are freed by calling "release". The object implementing the "release" function knows how to free itself safely.
It has two dominant advantages,
1, Binary compatibility. There is only function pointers in the interface with fixed layout (one pointer after another).
2, Safe memory management. No explicitly free function, all resources are freed by calling "release". The object implementing the "release" function knows how to free itself safely.
As long as the implementation is completely hidden and the interface contains only legal types, then it shouldn't be a problem.
Would something like std::string be a legal type? Or should I resort to C types only?
EDIT: I should be able to return COM interface pointers, correct?
Would something like std::string be a legal type? Or should I resort to C types only?
EDIT: I should be able to return COM interface pointers, correct?
Don't pass any STL classes across DLLs.
Different DLLs may be compiled with different STL.
Yes, you can return COM interface pointers, and it's the safe way.
How about operator overloading within a COM interface?
EDIT: If a function is going to receive varying number of string arguments, I should be creating something like IArgumentList and passing that to a function instead of using std::vector<const char*> right?
EDIT: If a function is going to receive varying number of string arguments, I should be creating something like IArgumentList and passing that to a function instead of using std::vector<const char*> right?
You are right on the argument list thing.
For operator overloading, in COM, forget any C++ specified features, such as operator overloading, template, etc.
I suggest you read some COM books such as "inside COM", "essential COM" to see how interface works.
For operator overloading, in COM, forget any C++ specified features, such as operator overloading, template, etc.
I suggest you read some COM books such as "inside COM", "essential COM" to see how interface works.
You are right on the argument list thing.
For operator overloading, in COM, forget any C++ specified features, such as operator overloading, template, etc.
I suggest you read some COM books such as "inside COM", "essential COM" to see how interface works.
I would if I could. My dad just recently got me a few dx11 books, and he won't be too happy seeing me requesting other books when I haven't finished the dx11 ones yet. Oh the joys of high school. So what kind of free resource would be the best at instructing one the ways of COM?
As a final question for this post, when I return references to an interface via a get function, the get method should call AddRef right?
I would if I could. My dad just recently got me a few dx11 books, and he won't be too happy seeing me requesting other books when I haven't finished the dx11 ones yet. Oh the joys of high school. So what kind of free resource would be the best at instructing one the ways of COM?
As a final question for this post, when I return references to an interface via a get function, the get method should call AddRef right?
http://en.wikipedia.org/wiki/Component_Object_Model
Also google "c++ Component Object Model", without quote marks.
Since you are only using the COM idea than COM itself, you don't need to go too deep in COM.
Just learn about the interface, object life management, that's enough.
I'm not sure if COM is still as popular as before .Net was born.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement