Solved

Need to use STL derived classes in DLL interface. Are there any known problems with VC8 regarding that issue?

Posted on 2006-07-18
10
1,653 Views
Last Modified: 2013-12-14
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
0
Comment
Question by:itsmeandnobodyelse
10 Comments
 
LVL 30

Assisted Solution

by:Axter
Axter earned 125 total points
Comment Utility
>>Is that statement still valid with VC8 or is it now safe?

I know it's still vaild for VC++ 7.1, and I'm pretty sure they haven't change the STL much (if any) between 7.1 and 8.0.
0
 
LVL 7

Assisted Solution

by:nafis_devlpr
nafis_devlpr earned 125 total points
Comment Utility
>>My last knowledge was that STL objects should not be transferred between dlls because of static members

well my friend it still has the same problem as stl hasn't change that much
0
 
LVL 39

Author Comment

by:itsmeandnobodyelse
Comment Utility
>>>> I know it's still vaild for VC++ 7.1

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


0
 
LVL 86

Accepted Solution

by:
jkr earned 125 total points
Comment Utility
>>Is there any known problem doing so?

Heaps. Unless you set all modules to 'Use Runtime Library: (Debug) (Multithreaded) DLL' so msvcrt.lib is used and not libc*.ib, each module has it's own heap and you'll get ASSERTs in Debug and memory leaks in Release builds. Using the CRT in a DLL remedies that problem, yet there are others. http://support.microsoft.com/kb/q168958/ ("How to export an instantiation of a Standard Template Library (STL) class and a class that contains a data member that is an STL object") addresses that and still applies. I'd rather recommend to pass interfaces between the affected modules that expose the functionality of the STL classes in question, so you can explicitly control memory management in the module where the object was created and resides.
0
How to run any project with ease

Manage projects of all sizes how you want. Great for personal to-do lists, project milestones, team priorities and launch plans.
- Combine task lists, docs, spreadsheets, and chat in one
- View and edit from mobile/offline
- Cut down on emails

 
LVL 30

Expert Comment

by:Axter
Comment Utility
>>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.
0
 
LVL 39

Author Comment

by:itsmeandnobodyelse
Comment Utility
>>>> 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
0
 
LVL 4

Assisted Solution

by:havman56
havman56 earned 125 total points
Comment Utility

Info :
when i  tested microsoft STL on vc6 , they have lot of bugs regarding std::char_traits .
whenevr  wchar_t encountered lot of probs .

1. inserting a wchar_t more than 0xfd  considered to eb sapce char etc. etc...
2. same way nested templates in STL caused problem in vc6 .

so please check it whether some of the bugs are fixed in vc8 . U can check dinkumware website for more info.


0
 
LVL 39

Author Comment

by:itsmeandnobodyelse
Comment Utility
>>>> 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





 
0
 
LVL 39

Author Comment

by:itsmeandnobodyelse
Comment Utility
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
0

Featured Post

Top 6 Sources for Identifying Threat Actor TTPs

Understanding your enemy is essential. These six sources will help you identify the most popular threat actor tactics, techniques, and procedures (TTPs).

Join & Write a Comment

Templates For Beginners Or How To Encourage The Compiler To Work For You Introduction This tutorial is targeted at the reader who is, perhaps, familiar with the basics of C++ but would prefer a little slower introduction to the more ad…
This article shows you how to optimize memory allocations in C++ using placement new. Applicable especially to usecases dealing with creation of large number of objects. A brief on problem: Lets take example problem for simplicity: - I have a G…
The viewer will learn how to use and create new code templates in NetBeans IDE 8.0 for Windows.
The goal of the tutorial is to teach the user how to use functions in C++. The video will cover how to define functions, how to call functions and how to create functions prototypes. Microsoft Visual C++ 2010 Express will be used as a text editor an…

772 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question

Need Help in Real-Time?

Connect with top rated Experts

12 Experts available now in Live!

Get 1:1 Help Now