GrossHandler
asked on
Exporting STL-symbols across multiple DLL's
In an application I am currently involved in developing (using MS Visual C++ 6) we have had som mysterious crash situations that we cannot in any way reproduce inhouse.
One possible error that we encountered while doing an overhaul of the application is that our DLL's may not export STL-classes the proper way. I.e. may not export them as explicitly as MSDN and Visual Studio wants them to be (see e.g. http://support.microsoft.com/default.aspx?scid=kb;EN-US;168958 ).
When reviewing our code with the MS link library export guidelines in mind I realized that every stl-class used as a base class, member variable or function or function parameter in an exported class would have to be explicitly instantiated outside its definition or totally rewritten (according to the MSDN-online help some STL classes cannot be exported at all). In the long run this strange policy could quite possibly force us to totally abandon using the STL-classes.
I guess my question is; does anyone know if I really need to be this meticulous about the instantiation or if there is some more convenient solution or work-around to solve this issue(that does not include explicit extra definitions for each used variable class)?
One possible error that we encountered while doing an overhaul of the application is that our DLL's may not export STL-classes the proper way. I.e. may not export them as explicitly as MSDN and Visual Studio wants them to be (see e.g. http://support.microsoft.com/default.aspx?scid=kb;EN-US;168958 ).
When reviewing our code with the MS link library export guidelines in mind I realized that every stl-class used as a base class, member variable or function or function parameter in an exported class would have to be explicitly instantiated outside its definition or totally rewritten (according to the MSDN-online help some STL classes cannot be exported at all). In the long run this strange policy could quite possibly force us to totally abandon using the STL-classes.
I guess my question is; does anyone know if I really need to be this meticulous about the instantiation or if there is some more convenient solution or work-around to solve this issue(that does not include explicit extra definitions for each used variable class)?
>>(Axter may be able to help there).
Nope.
This is one of bad side effects of using STL code.
There is no work around, that I'm aware of, other then the "explicit extra definitions in *.cpp", which you're excluding.
Nope.
This is one of bad side effects of using STL code.
There is no work around, that I'm aware of, other then the "explicit extra definitions in *.cpp", which you're excluding.
ASKER
Hm, thanks for your answers.
My problem isn't really that I need to export stl-derived classes themselves, but rather that I would like to be able to use stl-classes as members. Guess we'll have to exclude stl from any exported classes.
You wouldn't happen to know whether this is handled in a different way in a more recent C++ compiler (VC++ v 7.0, the one that comes with .NET?) from MS?
My problem isn't really that I need to export stl-derived classes themselves, but rather that I would like to be able to use stl-classes as members. Guess we'll have to exclude stl from any exported classes.
You wouldn't happen to know whether this is handled in a different way in a more recent C++ compiler (VC++ v 7.0, the one that comes with .NET?) from MS?
>>C++ compiler (VC++ v 7.0, the one that comes
>>with .NET?) from MS?
There is only one compiler that properly handles export keyword, and VC++ 7.0 is not it.
The export keyword is something that should not have been included in the C++ standard. At the time the standard was created, no one had yet deterimine a method for getting the export to work.
Only recently (within the last 6 months) has a compiler developer been able to actually get a working implementation for export.
I would not count on working export implementation added to VC++ any time soon. It will be many years, if ever.
>>with .NET?) from MS?
There is only one compiler that properly handles export keyword, and VC++ 7.0 is not it.
The export keyword is something that should not have been included in the C++ standard. At the time the standard was created, no one had yet deterimine a method for getting the export to work.
Only recently (within the last 6 months) has a compiler developer been able to actually get a working implementation for export.
I would not count on working export implementation added to VC++ any time soon. It will be many years, if ever.
I think that, in theory at least, you could package up all of the data and pass it around from DLL to DLL and that way each DLL could access its own copy of the data -- which would work with STL. That would only work for read-only datasets (though possibly a complicated synchronization logic could overcome that).
I recommend recoding the structures to use non-STL members. Although many programmers would disagree, I like the MFC 'pseudo-STL' classes like CStringArray and CObArray-derived classes such as CPtrArray. But it is surprising how often you can get by with simple (non-STL) arrays --many programmers just use STL becasue that is what is taught in school. For instance, if the array size is not dynamic, and no special memory allocation logic is needed, then most of the STL complexity is not needed.
-- Dan
I recommend recoding the structures to use non-STL members. Although many programmers would disagree, I like the MFC 'pseudo-STL' classes like CStringArray and CObArray-derived classes such as CPtrArray. But it is surprising how often you can get by with simple (non-STL) arrays --many programmers just use STL becasue that is what is taught in school. For instance, if the array size is not dynamic, and no special memory allocation logic is needed, then most of the STL complexity is not needed.
-- Dan
I actually learned MFC before fully learning STL, and I like STL much better then MFC.
Furthermore, STL has the added benifit of being portable and non propriatary.
So I don't really think that programmer use STL just because that's what they learn first.
Furthermore, STL has the added benifit of being portable and non propriatary.
So I don't really think that programmer use STL just because that's what they learn first.
ASKER
I totally agree with Axter on this one. The stl is more than just a propriatary library, I would even consider it to be a part of C++ itself.
To not be able to use stl-classes or, what I find a lot more important, template declarations as a C++ programmer would be like working with a "stumped" C++, a subset of the full programming language. I mean, what would java be if it lacked some of the standard java class packages?
Still looks like wrapping up any stl-classes and hide them from external view will be the only solution.
Another option would of course be to use a different implementation of stl, e.g. stl port, although I fear the export issue would then still be unsolved. Any comments on that?
To not be able to use stl-classes or, what I find a lot more important, template declarations as a C++ programmer would be like working with a "stumped" C++, a subset of the full programming language. I mean, what would java be if it lacked some of the standard java class packages?
Still looks like wrapping up any stl-classes and hide them from external view will be the only solution.
Another option would of course be to use a different implementation of stl, e.g. stl port, although I fear the export issue would then still be unsolved. Any comments on that?
This question didn't show any activity for more than 21 days. I will ask Community Support to close it unless you finalize it yourself within 7 days.
You can always request to keep this question open. But remember, experts can only help if you provide feedback to their comments.
Unless there is objection or further activity, I will suggest to
"refund the points and PAQ at zero points"
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
========
Werner
You can always request to keep this question open. But remember, experts can only help if you provide feedback to their comments.
Unless there is objection or further activity, I will suggest to
"refund the points and PAQ at zero points"
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!
========
Werner
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
But the bottom line is that STL is really just a bunch of complcated #define statements (pre-processor macros) and one of the normal, expected side-effects is that the data must be in the same module as the code that is generated to access that data. I think you are quite a bit better off to create and export one or more 'actual' class objects rather than trying to export a STL pseudo-class.
-- Dan