Need to use STL derived classes in DLL interface. Are there any known problems with VC8 regarding that issue?
We are going to migrate a big MFC application (10 executables, 70 dlls) from VC6 to VC8. With that we intend to change from RogueWave to STL, what means that we want to derive our string and container classes from std::string, std::vector, std::map, ... These classes were widely used for data members and in the dll exported class and function interface (here mostly as const reference or by value). So, the following is normal: we create a persistent class object in dll1 and pass a (smart) pointer of that object to dll2. Here the data members (strings, and pointers to other objects or arrays) may be set or modified. It cannot be excluded that some of the pointers were created by 'new' in one dll and deleted in a second dll, but we never use pointers to STL classes but only to our derived classes.
Is there any known problem doing so? My last knowledge was that STL objects should not be transferred between dlls because of static members. Is that statement still valid with VC8 or is it now safe?
Regards, Alex
Is there any known problem doing so? My last knowledge was that STL objects should not be transferred between dlls because of static members. Is that statement still valid with VC8 or is it now safe?
Regards, Alex
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
>>Could you specify a case that definitively fails when passing std::string or std::vector to a dll? All other STL classes we most probably can keep off from the interface.
Sorry, but I don't have the example code anymore, and I can't seem to find my old email that referred to this.
About 5 months ago, my company sent out an email on this issue.
And the problem still persist even if you use STLPort, which was originally thought to be a workaround solution.
My workaround solution was to create DLL functions that are used to modify the STL objects. (similar to what jkr's referring to)
The binary that creates the STL object should be the same binary that modifies it.
The calling binary can safely view the object, but it should not attempt to modify it.
You could get away with modifying the contents of a vector, if the DLL has created enough space for it.
However, this is dangerous to do with an std::string because of it's ability to have multiple std::string objects pointing to the same data.
Sorry, but I don't have the example code anymore, and I can't seem to find my old email that referred to this.
About 5 months ago, my company sent out an email on this issue.
And the problem still persist even if you use STLPort, which was originally thought to be a workaround solution.
My workaround solution was to create DLL functions that are used to modify the STL objects. (similar to what jkr's referring to)
The binary that creates the STL object should be the same binary that modifies it.
The calling binary can safely view the object, but it should not attempt to modify it.
You could get away with modifying the contents of a vector, if the DLL has created enough space for it.
However, this is dangerous to do with an std::string because of it's ability to have multiple std::string objects pointing to the same data.
ASKER
>>>> Unless you set all modules to 'Use Runtime Library: (Debug) (Multithreaded) DLL'
All dlls and executables were built using the same threading model and the same compiler.
>>>> http://support.microsoft.com/kb/q168958
Yes I already read that article and http://support.microsoft.com/kb/172396/en-us as well. These articles apply to VC5 and VC6 and there is no remarks to find whether VC7 or VC8 have the same problem. Moreover, I found an article http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html where the author states that as long as you are using the same compiler and threading model there is no problem beside of unnecessary compiler warnings. He even gives an example where he exports successfully a std::map, a class of which Microsoft states that it couldn't be exported. I wonder, if it would be a real life problem regarding *normal* dlls, shouldn't I get a cillion of help calls in the web?
>>>> I'd rather recommend to pass interfaces between the affected modules that expose the functionality of the STL classes in question
The problem is that nearly any main menu point of the application is solved by a separate dll most of them the loaded dynamically when the menu was invoked. All dlls and exe are sharing some base dlls with thousands of methods and classes. It wouldn't be so hard to change the arguments only. But what is with data members - persistent or not - where the objects are loaded in one dll and used in another. So, I am sure we can find a non-STL solution for std::string what has to be supposed to replace RWString from RoqueWave if that is the problem (though I didn't find any bad news about std::string til now). That would reduce the problem as our derived string type covers more than 50 percent of all interface types. However, we need some container classes as well which need to get exchanged between dlls without problems as there are too many as they could be substituted by a wrapper.
>>>> The calling binary can safely view the object, but it should not attempt to modify it.
Yes, I understand but it can't be made cause it is about 8 millions lines of code to look over ...
In the moment my understanding is the following:
- the compiler gives a warning if using template arguments or template members without explicit instantiation
- there is no hint that this warning leads to a serious error if ignoring it.
- we already used RoqueWave template container without explicitly instantiating them
- In VC6 STL there are reported errors regarding access violation when passing STL objects
that are not instantiated. These errors were caused by static members created seperately in
either module
- However, there is no hint that these problems still occur with VC8 or what must be done to get that error.
Seems as I have to make some serious test cases to find out what will happen.
Regards, Alex
All dlls and executables were built using the same threading model and the same compiler.
>>>> http://support.microsoft.com/kb/q168958
Yes I already read that article and http://support.microsoft.com/kb/172396/en-us as well. These articles apply to VC5 and VC6 and there is no remarks to find whether VC7 or VC8 have the same problem. Moreover, I found an article http://www.unknownroad.com/rtfm/VisualStudio/warningC4251.html where the author states that as long as you are using the same compiler and threading model there is no problem beside of unnecessary compiler warnings. He even gives an example where he exports successfully a std::map, a class of which Microsoft states that it couldn't be exported. I wonder, if it would be a real life problem regarding *normal* dlls, shouldn't I get a cillion of help calls in the web?
>>>> I'd rather recommend to pass interfaces between the affected modules that expose the functionality of the STL classes in question
The problem is that nearly any main menu point of the application is solved by a separate dll most of them the loaded dynamically when the menu was invoked. All dlls and exe are sharing some base dlls with thousands of methods and classes. It wouldn't be so hard to change the arguments only. But what is with data members - persistent or not - where the objects are loaded in one dll and used in another. So, I am sure we can find a non-STL solution for std::string what has to be supposed to replace RWString from RoqueWave if that is the problem (though I didn't find any bad news about std::string til now). That would reduce the problem as our derived string type covers more than 50 percent of all interface types. However, we need some container classes as well which need to get exchanged between dlls without problems as there are too many as they could be substituted by a wrapper.
>>>> The calling binary can safely view the object, but it should not attempt to modify it.
Yes, I understand but it can't be made cause it is about 8 millions lines of code to look over ...
In the moment my understanding is the following:
- the compiler gives a warning if using template arguments or template members without explicit instantiation
- there is no hint that this warning leads to a serious error if ignoring it.
- we already used RoqueWave template container without explicitly instantiating them
- In VC6 STL there are reported errors regarding access violation when passing STL objects
that are not instantiated. These errors were caused by static members created seperately in
either module
- However, there is no hint that these problems still occur with VC8 or what must be done to get that error.
Seems as I have to make some serious test cases to find out what will happen.
Regards, Alex
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
>>>> i tested microsoft STL on vc6 , they have lot of bugs regarding std::char_traits
Yes, that's one of the reasons we don't use STL on VC6. Fortunately, we don't need to consider wide characters cause it's a locally used application only.
>>>> U can check dinkumware website for more info
It seems an interesting alternative to VC8 STL though I couldn't find any hint that the problem from above was solved with their library while it is still an issue with VC8.
>>>> I have to make some serious test cases
First tests didn't show up errors wehen passing STL objects via dll boundaries. There is only the warning that templates were not exported though it doesn't seem to have any negative effect ...
We could get rid of the warning by explicit template instantiation as recommended by MS. However, as we would need to use the same template types in more than one dll, we would get linker errors because of duplicate functions whereever these export libraries were linked together statically. So. it doesn't seem very practical.
Proceeding ...
Regards, Alex
Yes, that's one of the reasons we don't use STL on VC6. Fortunately, we don't need to consider wide characters cause it's a locally used application only.
>>>> U can check dinkumware website for more info
It seems an interesting alternative to VC8 STL though I couldn't find any hint that the problem from above was solved with their library while it is still an issue with VC8.
>>>> I have to make some serious test cases
First tests didn't show up errors wehen passing STL objects via dll boundaries. There is only the warning that templates were not exported though it doesn't seem to have any negative effect ...
We could get rid of the warning by explicit template instantiation as recommended by MS. However, as we would need to use the same template types in more than one dll, we would get linker errors because of duplicate functions whereever these export libraries were linked together statically. So. it doesn't seem very practical.
Proceeding ...
Regards, Alex
ASKER
With tests we couldn't see any problems by simply ignoring the compiler warning that the templates were not exported.
It is important that all executables have the same threading model but beside of that we can't see any problems by passing STL containers to and from dlls.
We will know for sure when the portation is done in some weeks ...
Regards, Alex
It is important that all executables have the same threading model but beside of that we can't see any problems by passing STL containers to and from dlls.
We will know for sure when the portation is done in some weeks ...
Regards, Alex
ASKER
Could you specify a case that definitively fails when passing std::string or std::vector to a dll? All other STL classes we most probably can keep off from the interface.
Regards, Alex