There are at least two problems with using STL and even ordinary code across DLL boundaries with MSVC, both of which can be hard to get round. One is that if you link statically (select the non-DLL version of the run time libraries) the code inside the DLL will use a different storage pool from code outside the DLL, so store allocated on one side of the boundary and freed on the other side of the boundary will break the storage pool that tries to free it. This will also happen if the run time library selected by the code in the DLL is not identical to that selected by the program using it. Another problem is that much of the STL implementation selected by Microsoft does not use 0 as a special pointer value to mark the ends of linked lists and such things. It tends to allocate a little chunk of memory and use that instead. These marker values are not exported across the DLL boundary, so somebody reading an STL structure created on the other side of the DLL boundary will not recognise the end list marker and will fall of the end and start using rubbish pointers.
See http://support.microsoft.com/kb/172396 http://support.microsoft.com/kb/168958 http://www.deez.info/sengelha/2006/03/03/c-stl-dlls-and-buggy-optimizations/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
