How to export the drived class from one abstract class? And also STL container is used as private members. [modified]
-
In order to use the CInterfaceClass in another DLL, as a base class, you need to export this class first.
Really? I've make the interface class as one interface class with all functions of pure virtual property. It says it is an abstract class only. It seems not required to export it with the DLL's derived class. Right?
Nisamudheen wrote:
In order to use the CInterfaceClass in another DLL, as a base class, you need to export this class first.
-
SAMZCN wrote:
But many errors come out with STL members.
Well we will have to guess what they are. It may be that you are not adding a
usingstatement in your client project before the inclusion of the class containing the STL members. Alternatively you could add the full definitions in your headers like this:CMyDLLClass1 : public CInterfaceClass
{
public:
CMyDLLClass1 (){};
virtual ~ CMyDLLClass1 (){};
virtual int Func1();
virtual int Func2();
virtual int Func3();
private:
std::vector<...> ....
std::map<...> ....
}Did you notice how I also used <pre></pre> tags to make the code snippet more readable?
Just say 'NO' to evaluated arguments for diadic functions! Ash
Hello Richard, Thanks for your input. I've include the headers in the DLL project
#include #include #include #include using namespace std;
Is ther any error on my implementation on the DLL exporting? Is it a right way to make DLL proj to export derived class like what I do ? It is the first time that I do it like this.
Richard MacCutchan wrote:
Well we will have to guess what they are. It may be that you are not adding a using statement in your client project before the inclusion of the class containing the STL members. Alternatively you could add the full definitions in your headers like this: CMyDLLClass1 : public CInterfaceClass { public: CMyDLLClass1 (){}; virtual ~ CMyDLLClass1 (){}; virtual int Func1(); virtual int Func2(); virtual int Func3(); private: std::vector<...> .... std::map<...> .... } Did you notice how I also used
tags to make the code snippet more readable?
-
It looks like you have problems with the
STLlibrary, notDLLissues. You should post the errors and (as Richard pointed out) the relevant code for getting better help. :)If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles]Hi, Cpallini I am trying to find out some clue here... I am confused now... What's wrong with my code or proj? And the STL support headers are all included and employeed its namespace too.
CPallini wrote:
It looks like you have problems with the STL library, not DLL issues. You should post the errors and (as Richard pointed out) the relevant code for getting better help
-
Hi, Cpallini I am trying to find out some clue here... I am confused now... What's wrong with my code or proj? And the STL support headers are all included and employeed its namespace too.
CPallini wrote:
It looks like you have problems with the STL library, not DLL issues. You should post the errors and (as Richard pointed out) the relevant code for getting better help
We can't just guess based on your description, we need facts code and error messages, Watson! :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Hello Richard, Thanks for your input. I've include the headers in the DLL project
#include #include #include #include using namespace std;
Is ther any error on my implementation on the DLL exporting? Is it a right way to make DLL proj to export derived class like what I do ? It is the first time that I do it like this.
Richard MacCutchan wrote:
Well we will have to guess what they are. It may be that you are not adding a using statement in your client project before the inclusion of the class containing the STL members. Alternatively you could add the full definitions in your headers like this: CMyDLLClass1 : public CInterfaceClass { public: CMyDLLClass1 (){}; virtual ~ CMyDLLClass1 (){}; virtual int Func1(); virtual int Func2(); virtual int Func3(); private: std::vector<...> .... std::map<...> .... } Did you notice how I also used
tags to make the code snippet more readable?
This is fine but have you include all the correct headers (and reference to std namespace) in the class that is linking to the DLL, i.e the code that will be using the DLL. Remember that classes and methods exported from a DLL are visible to the linker not the compiler.
Just say 'NO' to evaluated arguments for diadic functions! Ash
-
We can't just guess based on your description, we need facts code and error messages, Watson! :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
Oh... I am trying to catch the error. But I found it is uncertain and not repeatable.. :( Try to find more and report later ...
What about the code & error message? :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
This is fine but have you include all the correct headers (and reference to std namespace) in the class that is linking to the DLL, i.e the code that will be using the DLL. Remember that classes and methods exported from a DLL are visible to the linker not the compiler.
Just say 'NO' to evaluated arguments for diadic functions! Ash
Thanks. Yes. In the client project linking to the DLL, the client project include the DLL interface head file like this.
#include "MyExprotDllHead.h"
Now the issue is still pending. And so many new failure report and reported in STL allocation procedure. I'm trying my best to find out the root cause. :(
Richard MacCutchan wrote:
This is fine but have you include all the correct headers (and reference to std namespace) in the class that is linking to the DLL, i.e the code that will be using the DLL. Remember that classes and methods exported from a DLL are visible to the linker not the compiler.
-
Thanks. Yes. In the client project linking to the DLL, the client project include the DLL interface head file like this.
#include "MyExprotDllHead.h"
Now the issue is still pending. And so many new failure report and reported in STL allocation procedure. I'm trying my best to find out the root cause. :(
Richard MacCutchan wrote:
This is fine but have you include all the correct headers (and reference to std namespace) in the class that is linking to the DLL, i.e the code that will be using the DLL. Remember that classes and methods exported from a DLL are visible to the linker not the compiler.
-
Fantastic! And what does that include file contain?
Just say 'NO' to evaluated arguments for diadic functions! Ash
