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 http://groups.google.com/group/protobuf?hl=en -~----------~----~----~----~------~----~------~--~---
