David Wilkinson wrote:
This question comes up quite frequently in the newsgroups, and over
the years I have absorbed the answer (and learned to repeat it). Also,
if you read about how COM works, you will see why pure interfaces are
compiler-independent.
Nuts. The COM part is clear to me (I consider myself a Senior COM
Programmer ;-), but unfortunately the Dll in question does not use COM.
However, the classes that are used inside this Dll are pretty much
COM-like, which means that all calls are made via virtual methods. I
guess I have two alternatives:
A) Convince the third party to make his objects proper COM objects, or
B) just try to call the Dll functions and hope for the best. As far as I
can see, the class inside the Dll contains some implementation members
taken from the VS7.1 STL, so I cannot simply create objects of this
class: though the constructor of the class is available in the Dll,
VC6.0 doesn't know the exact size of those objects.
Maybe I can ask the third party for the right size of the object, and
use placement new with a memory block large enough. Besides, the used
STL classes won't have increased in size for more than let's say factor
two, so it should be safe enough to allocate a memory block twice the
size of what VS6.0 would use.
Would you consider alternative B) reasonable?
party DLL which exposes a COM or other "pure interface' interface.