On Tue, Sep 16, 2008 at 12:26 PM, Niall <[EMAIL PROTECTED]> wrote:

> But, suppose you have the dll, a lib and the required header files.
> You have all the things you need. The functions, their location, how
> they are called. Surely the DLL would worry about itself. It's a
> separate moster altogether to the source code you're trying to
> compile, no? The DLL doesn't have to interface to anything. No
> headers, no nothing. It only worries about itself, right? Just needs
> to know what in the dll to execute, and that's managed by the lib
> file, correct? All you should need are the entry/exit points I'd've
> though. Though my understanding of DLLs is by no means infallible.

If the STL implementations used by the DLL and its client are not
compatible, then passing STL objects between the two will fail.  Microsoft
even says explicitly in their docs that you cannot pass STL objects across
DLL interfaces.  I've ignored this in protocol buffers because adhering to
this rule would require huge changes to the interface (which was originally
designed on Linux which has no such problems), and in practice it works so
long as you compile the DLL with the same STL version as the rest of your
app.  But, this is why we cannot distribute precompiled binaries -- they
won't be compatible between versions of MSVC.

You received this message because you are subscribed to the Google Groups 
"Protocol Buffers" group.
To post to this group, send email to protobuf@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 

Reply via email to