|
An alternative is, if you have control over the video renderer (you have access to each frame
of video before it gets blted to the window) then you can draw stored shapes offscreen on the
video frame and then blt it. This makes it nicely flicker-free as well.
|
|
|
|
|
Does anyone know why the syntax for exporting constants in a DLL is different from exporting variables or functions?
Take the following code snippet for instance:
extern "C"
{
extern const IID IID_IX =
{0x32bb8320, 0xb41b, 0x11cf, {0xa6, 0xbb, 0x00, 0x80, 0xc7, 0xb2, 0xd6, 0x82}};
}
Why do the extern statements need to be nested?
|
|
|
|
|
extern "C" is not exporting it is a compiler directive that eliminates name decoration.
led mike
|
|
|
|
|
Hi all,
I want to input joystick to my code,which is very simple smile.gif.I searched the net but find out that people use DirectInput , etc... but i want a very simple application, for example like when you pull right, a variable in the code changes from 0 to 10,whne you pull left another variable changes from 2 to 8, etc... I use VC++ v6.0, no .NET,no C# please. here i send a sample code I wrote in which i wanna input joystick for sometry. thank you everyone.
[code]
#include <time.h>
#include <iostream>
using namespace std;
void wait ( double seconds )
{
clock_t endwait;
endwait = clock () + seconds * CLK_TCK ;
while (clock() < endwait) {}
}
int main()
{
double t;
double delt;
double delf;
double function;
cout<< "Derivative of the function : "<<endl;
cin>>delf ;
cout<< "Time deviation : "<<endl;
cin>>delt;
t=0.0;
function=0.0;
do {
function = function+ delf*delt ;
// here i want to add joystick reading here
// joy1= ....???
//joy2= .....???
// like : when i move left,it reads 5 for joy1, and when i move right it reads 3 for joy2, etc...
// moreover,it eould be superb if also i can read the value as how much i move joystick,
//for example, when i move it from center to left end,joy1 value increases from 0 to 8.
// PLEASE HELP //
wait (delt);
t=t+delt;
cout<<" Function is "<
|
|
|
|
|
I am also looking for infomation on how to involve a joystick with my VC++/MFC application.. Using VS2005
I think we need to use the DirectX SDK with VC++ for joystick.. is this correct?
|
|
|
|
|
Check out DirectInput in the DirectX SDK 
|
|
|
|
|
|
Hello,
I came across a strange problem. I have a dll which creates an instance of a class. This class inherits from a template singleton.
The singleton template:
template <class T>
class CSingleton
{
public:
static T* GetInstance()
{
if (!m_pInstance)
m_pInstance = new T;
return m_pInstance;
}
void Destroy()
{
if (m_pInstance)
delete m_pInstance;
m_pInstance = NULL;
}
protected:
CSingleton() { }
virtual ~CSingleton() { }
private:
static T* m_pInstance;
};
template <class T> T* CSingleton<T>::m_pInstance = NULL;
The class is a simple empty class:
class CMyClass : public CSingleton<CMyClass>
{
friend CSingleton<CMyClass>;
protected:
CMyClass();
~CMyClass();
};
And then I have an exported function that creates and return the instance of this class:
#ifdef DLL_EXPORTS
#define DLL_API __declspec(dllexport)
#else
#define DLL_API __declspec(dllimport)
#endif // DLL_EXPORT
DLL_API CMyClass* CreateClass();
(the function simply call GetInstance of CMyClass and returns the pointer)
When I call this function from the code of my executable, it returns well a pointer to the instance but the strange thing is that the static m_pInstance member of CSingleton is NULL.
I used the debugger and this member is correct inside the CreateClass function but as soon as I come back in the code of the executable, then this member is NULL.
It means that if I try to call Destroy, the memory won't be released. Worse, if I call GetInstance, I will certainly have an unexpected behavior (the instance will be created a second time)
It has probably something to do with the fact that this member is static. But I don't understand clearly what's happening there. Is there a workaround ?
Thank you.
|
|
|
|
|
This is very odd. I am using VS03 and this seems to work as expected.
I added a trace statement to GetInstance :
static T* GetInstance()
{
if( ! m_pInstance )
{
m_pInstance = new T;
}
TRACE( "CSingleton::GetInstance() returning %p\n", m_pInstance );
return m_pInstance;
}
and test it like this :
CMyClass * p = NULL;
p = CreateMyClass();
if( p )
{
TRACE( "CMyClass instance 1 is %p\n", p );
}
p = CreateMyClass();
if( p )
{
TRACE( "CMyClass instance 2 is %p\n", p );
}
this is the output :
CSingleton::GetInstance() returning 01242848
CMyClass instance 1 is 01242848
CSingleton::GetInstance() returning 01242848
CMyClass instance 2 is 01242848
|
|
|
|
|
Hello Rick, thanks for your answer.
Yes, I tested this and it works also: I only have one instance (the pointer returned the second time is the same). I was wrong when I discussed about the second instance in my previous mail.
But what doesn't work is the Destroy method: if I call this method (which isn't static), then the m_pInstance in the singleton is NULL (when GetInstance was called previously). Thus, the memory is not released.
EDIT: also when I check this value with my debugger, the m_pInstance is valid during the CreateClass function but as soon as I come back in the code of my executable, this value is NULL.
EDIT2: so it seems that this pointer is only "visible" from inside the dll. If I call a static function (from the singleton class), then the pointer will be visible from within this function. If I call a non-static function (also from the singleton class), then the pointer is NULL. In the code of the executable, this pointer is always NULL.
I'm a little bit lost here 
-- modified at 14:19 Friday 1st December, 2006
|
|
|
|
|
|
Hello,
Thanks for your answer. Yes, I think it has something to do with that but the problem is that it is a template, so I don't have a cpp file 
Don't know how I will solve this issue...
|
|
|
|
|
Destroy() should be static as it is the antithesis of getInstance().
led mike
|
|
|
|
|
Hello !
Sorry for the late answer but it was the week-end  .
I also thought that having a static Destroy method could solve the problem but unfortunately not. If I specify Destroy as static and if I call this function from my executable:
CMyClass::Destroy();
it won't work neither  If I set a breakpoint inside the Destroy function, the m_pInstance member is NULL (resulting in a memory leak).
The only way that works is to have a global exported function in the dll that calls Destroy (the same way as the creating function):
#ifdef DLL_EXPORTS
#define DLL_API __declspec(dllexport)
#else
#define DLL_API __declspec(dllimport)
#endif // DLL_EXPORT
DLL_API CMyClass* CreateClass();
DLL_API void DestroyClass();
The DestroyClass function only calls CMyClass::Destroy(). If I do that, it works. But this not really what I would like.
Any idea of what's happening here and how to solve the problem ?
Thank you.
|
|
|
|
|
Cedric Moonen wrote: Any idea of what's happening here and how to solve the problem ?
Not really. I may work up a duplicate project structure so I can see this occur. I do have a question though. My question is based on the assumption that the singleton design does NOT produce this problem when contained in a single executable project correct?
Why do you need this design? Why do you need a singleton class to reside in a DLL? DLL's are supposed to be libraries. The requirement for the Singleton should be at the application level rather than at the library level so I am not seeing the benefit in this layout.
led mike
|
|
|
|
|
Hello, thanks for your answer.
led mike wrote: My question is based on the assumption that the singleton design does NOT produce this problem when contained in a single executable project correct?
I didn't test it but I'm almost sure that it works. Anyway, it works from within the dll without problems.
led mike wrote: Why do you need this design? Why do you need a singleton class to reside in a DLL? DLL's are supposed to be libraries. The requirement for the Singleton should be at the application level rather than at the library level so I am not seeing the benefit in this layout.
The thing is that I'm developping a 2D render engine (for games more particularly). There is a main class, the Engine class that holds several managers (for example a texture manager). It is much more convenient to have this class as a singleton so that I don't need to pass its instance to every class in the engine that requires the texture manager for example.
I would like also to have a "scene manager" that holds all the nodes that will be drawn at the screen. This class for example shouldn't be a singleton because you could have two scene managers (in games where you split the screen and have two slightly different scenes). So, the purpose here is to select the scene manager on which we working currently through the engine class (and have a method like GetCurrentSceneManager).
Does that make sense ?
|
|
|
|
|
Cedric Moonen wrote: Does that make sense ?
Maybe. You are designing a render engine into a DLL library to be used by different applications?
If so you need to keep the "singleton" design out of your library as I stated earlier. That type of "convenience" design should be in the application layer. This would simplify the engine design as well as provide a more flexible use model. The application layer code might or might not use a singleton wrapper for it's engine object depending on the application layer needs.
Perhaps the engine should be able to be built up, using it's interface, with it's constituent parts like the "texture manager(s)" and "scene manager(s)". Thus the engine can still have access to the managers it requires without being a Singleton. Then the application is responsible for these assignments. Responsibility == Flexibility.
led mike
|
|
|
|
|
led mike wrote: You are designing a render engine into a DLL library to be used by different applications?
The purpose will be to distribute the code afterwards. So I want it to be the most easier to use.
led mike wrote: This would simplify the engine design as well as provide a more flexible use model.
I don't think that will simplify the design: if I want some managers to be unique, then they will need to be singletons themselves (and I will have problems with the scene manager). The best case would be to have the engine as a singleton so that specific nodes can access the texture manager (for example).
led mike wrote: Then the application is responsible for these assignments. Responsibility == Flexibility.
That's not the way I would like to go. My plan is to have something very easy to use and still flexible (but the it should be first easy to use).
|
|
|
|
|
I am unable to reproduce the problem.
Here is the header file that is built into the DLL and distributed with the .lib file
<class t=""><class t=""><T>template <class T> class singleton{
protected:
static T* _pinstance;
singleton(){}
virtual ~singleton(){}
public:
static T& getInstance(){
if( !_pinstance)
_pinstance = new T();
return *_pinstance;
}
static void release(){
delete _pinstance;
_pinstance = NULL;
}
};
template<class T> T* singleton<T>::_pinstance = NULL;
class LOGLIBSINGLETON_API Logger : public singleton< Logger>
{
public:
Logger(void);
bool log( LPTSTR eventSource, DWORD dwEventID, WORD wCategory, LPCTSTR message);
public:
~Logger(void);
};
</T></class></class>
Then the application code uses it so
Logger::getInstance().log( msg, 0, 1, msg);
Logger::release();
with a breakpoint on the release call I step into the template source and the pointer is NOT NULL.
VS 2005 XP Pro SP2
led mike
|
|
|
|
|
The difference is in the fact that I have a global exported function in the DLL that creates the engine instance:
DLL_API CEngine* CreateEngine(....)
{
CEngine* pEngine = CEngine::GetInstance();
pEngine->....;
return pEngine;
}
The purpose will be that the end user will only work with an abstract Engine class (this function will in fact return the interface only). The user will be need to pass parameters to this function so that the Engine can be initialized with some specific parameters (that's the missing lines in the previous code snippet).
So, the instance is in fact allocated inside the dll, that's the main difference. The _pinstance member is only visible from within the DLL (it is NULL in the executable code). So, if in the executable code I call release, I will have a memory leak.
This works only if I had a global exported function in the DLL that calls release:
DLL_API void ReleaseEngine()
{
CEngine::release();
}
If I try to call CEngine::release directly from the executable code, the _pinstance member is NULL (I used the debugger to check) and I'll have a memory leak.
|
|
|
|
|
Well I added that new twist of the exported function but I still cannot reproduce your problem.
LOGLIBSINGLETON_API Logger& GetLogger();
LOGLIBSINGLETON_API Logger& GetLogger()
{
return Logger::getInstance();
}
Logger& logger = GetLogger();
logger.log( msg, 0, 1, msg);
Logger::release();
I don't understand why you need an exported function that just returns a pointer to an instance but that's just me. Ultimately it does not change the fundamental structure of what you are doing which is why it still behaves exactly the same for me.
IMHO if you need parameters to set up the engine instance you are back to what I orginally suggested anyway. Let the user create an engine and setup the engine using it's interface. If the user must supply these parameters what difference does it make how (what functions/methods) they use to supply them?
Or even add the parameters to the static getInstance(....) method. The global exported functions are zero added vaule as far as I can tell (however they do not seem to be the cause of your error since it works for me).
led mike
|
|
|
|
|
led mike wrote: Well I added that new twist of the exported function but I still cannot reproduce your problem
That's strange... What IDE are you using ? I'm working with VC2005 Express.
led mike wrote: I don't understand why you need an exported function that just returns a pointer to an instance but that's just me.
The reasons are multiple:
- First, I want to force the user to specify some parameters (like the screen size, and several other configurations). If I use several public function to do that it is not clean: some parameters are mandatory and I don't want the user to call 3 or 4 functions to initialize the engine. You said that I could add parameters to the static getInstance: that's quite bad. What happen if in my code, I want to access the unique instance ? I'll need to pass some parameters again ? That's not clean at all.
Remember that I want it the easiest to use for the end user.
- Second, I would like the user to work with interfaces only (so, pure abstract classes only) so, the Create function will in fact instanciate a CEngine class and returns an interface.
- I would like to have this code compile for several platforms (at least for windows and Linux), so having a DLL binary for windows and a 'dynamic library' (I don't remember the extension) for Linux based on exactly the same code. I know for sure that gcc can export functions, but I don't know if it can export classes.
- It could be interesting to have this dll to be explicitely linkable (so, using LoadLibrary and GetProcAddress). If you export classes, you can only use implicit linking (that is, using the lib file provided with the dll).
- I would like in the future that the dll can be used in other languages (for example in .NET). I don't know exactly how I will do that but I know more or less how COM components work: they have a global exported function that creates an instance of a class and returns an interface to this class. So, being able to use this dll in other language will require only to rewrite the interfaces.
So, there are several reasons why I want to keep this design.
Anyway, thanks for your help. I hope I'll find a solution to that problem.
|
|
|
|
|
Cedric Moonen wrote: What IDE are you using ? I'm working with VC2005 Express.
2005 Professional so I doubt that is the problem
Cedric Moonen wrote: If I use several public function to do that it is not clean:
I don't agree with that. The word "clean" is frequently abused in context of software design. If a user is going to use a "rendering engine" they can be assumed to be somewhat technical and should be capable of reading the documentation and sample code that details how to intiialize something as complex as a rendering engine. Have you ever worked with a 3D library?
Cedric Moonen wrote: but I don't know if it can export classes.
That is confusing since the "interfaces" you mention must be exported from your library correct? Therefore it is a requirement for you.
Cedric Moonen wrote: So, being able to use this dll in other language will require only to rewrite the interfaces.
Not sure if I agree with that. Native code is just "wrapped" by managed classes. You would use C++/CLI to create an assembly that implemented managed classes that wrapped all the native classes that you wanted to expose.
led mike
|
|
|
|
|
I think that I don't explain very well 
In fact, I would like to have something more or less similar to COM (except that it is much simpler: you just have one exported function that returns the interface of the engine).
led mike wrote: That is confusing since the "interfaces" you mention must be exported from your library correct?
No. They are interfaces and contains only pure virtual functions so in that case I don't need to export anything. By exporting I mean using __declspec(dllexport). Of course, header files of the dll still needs to be distributed but these headers contains only pure interfaces. It is the way COM components are working.
And thanks for your patience . I'll try to find what is causing the problem. Even if you are right, I still want to understand what is going on here (I don't like when I don't understand what's happening).
|
|
|
|
|
I had a cpp file for the library's DllMain implementation and I put the initializer in that.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
