I'm not sure this is actually an issue at all. Each DLL should not have its own heap. If that were the case, DLLs in windows would be pretty much useless.
As long as every DLL being used together links against the same runtime DLL they will share the same heap. Problems arise when one or more DLLs use different runtime linkage. Do not mix static and dynamic runtimes, debug and release, or runtimes from different VS versions and everything should be fine. I recently downloaded protocol buffers to evaluate. I switched the project settings back to DLL, added x64 target, and everything worked great on all platforms. I had one implosion initially when I switched between debug/release in my test app and forgot to switch the libprotobuf dll in my bin folder to the correct version. A recommended fix for avoiding that problem is appending a 'd' to the output target name for the debug builds so that such accidents are less likely to occur. On Sep 29, 4:45 pm, "Kenton Varda" <[EMAIL PROTECTED]> wrote: > Hi all, > Just before building the 2.0.2 release candidate, I submitted a change to > make static linking the default for the protobuf libraries under MSVC. This > seems necessary to avoid some of the problems inherent in DLLs which have > been discussed here, such as the fact that each DLL has a separate heap. > You can still build DLLs by simply changing the libprotobuf and libprotoc > projects to be DLL projects -- instructions are included in > vsprojects/readme.txt. > > Let me know if anyone objects to this. I don't use MSVC much so it's hard > for me to know what is best for MSVC users. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Protocol Buffers" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
