I know it's kind of weird to have GLOW's principal developer asking a question, but I don't have a lot of Windows experience and I thought someone else might have a better understanding of these issues...
As I understand it, it currently is not possible to make a Win32 DLL of GLOW using MSVC because the class declarations aren't specifying the appropriate dllimport and dllexport notices. I spent some time looking at this issue today and ran into a snag.
Several of the classes in GLOW have members that are STL containers: some vectors, a bunch of maps, and a deque or two. When I tried to dllexport those classes, MSVC complained that the STL members were not exported. After reading up on STL/DLL issues, I came upon the unfortunate factoid that the only STL container that can be exported in a DLL is vector (due to the way instantiations work in MS's STL implementation.) As far as I can tell, this leaves several GLOW classes unexportable due to their containing maps or deques.
Now for the question. In the cases in which a member is a nonexportable STL container (e.g. a map or a deque), the member is always private. In fact, I think the only STL objects that are part of the public API (though I have to double-check this...) are the axisConstraints in the GlowViewManipulator system, and those are vectors. Therefore, is it possible (and is it okay) to dllexport classes that contain unexported STL members (sometimes static and sometimes not) that are private and therefore (I think) don't really need to be exported? For example, how could I dllexport this class:
class Foo {
public:
Foo();
private:
std::map<int, int> a; // can't export this member
static std::deque<int> b; // or this one
};
Or is there another workaround that will allow a DLL to be made of GLOW?
Is there anyone monitoring this forum who understands these issues reasonably well?
Thanks,
Daniel Azuma
Principal developer, The GLOW Toolkit
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2000-07-24
Hi,
Have you looked at STLport? It's cross-platform STL implementation that should be usable on all the platforms you're targetting. It's pretty easy to drop into MSVC. I've used it in a couple of projects with no problems and it's implementation is supposed to be superior to the MSVC STL implementation. It's at http://www.stlport.org
I haven't built any DLLs with it myself so I'm not sure if it'll solve your problem, but it may be worth a try.
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I know it's kind of weird to have GLOW's principal developer asking a question, but I don't have a lot of Windows experience and I thought someone else might have a better understanding of these issues...
As I understand it, it currently is not possible to make a Win32 DLL of GLOW using MSVC because the class declarations aren't specifying the appropriate dllimport and dllexport notices. I spent some time looking at this issue today and ran into a snag.
Several of the classes in GLOW have members that are STL containers: some vectors, a bunch of maps, and a deque or two. When I tried to dllexport those classes, MSVC complained that the STL members were not exported. After reading up on STL/DLL issues, I came upon the unfortunate factoid that the only STL container that can be exported in a DLL is vector (due to the way instantiations work in MS's STL implementation.) As far as I can tell, this leaves several GLOW classes unexportable due to their containing maps or deques.
Now for the question. In the cases in which a member is a nonexportable STL container (e.g. a map or a deque), the member is always private. In fact, I think the only STL objects that are part of the public API (though I have to double-check this...) are the axisConstraints in the GlowViewManipulator system, and those are vectors. Therefore, is it possible (and is it okay) to dllexport classes that contain unexported STL members (sometimes static and sometimes not) that are private and therefore (I think) don't really need to be exported? For example, how could I dllexport this class:
class Foo {
public:
Foo();
private:
std::map<int, int> a; // can't export this member
static std::deque<int> b; // or this one
};
Or is there another workaround that will allow a DLL to be made of GLOW?
Is there anyone monitoring this forum who understands these issues reasonably well?
Thanks,
Daniel Azuma
Principal developer, The GLOW Toolkit
Hi,
Have you looked at STLport? It's cross-platform STL implementation that should be usable on all the platforms you're targetting. It's pretty easy to drop into MSVC. I've used it in a couple of projects with no problems and it's implementation is supposed to be superior to the MSVC STL implementation. It's at http://www.stlport.org
I haven't built any DLLs with it myself so I'm not sure if it'll solve your problem, but it may be worth a try.
Martin
I actually got a dll to compile just by switching the project type on MSVC.NET. What I didn't get was a lib file to go with it.