|
Ryan is correct. OpenGL has no memory of the previous frame, you redraw it each time. Though there are shortcuts for repeated structures to shorten and speed up operations, you are drawing each frame one at a time, so blinking, you basically don't draw it (or draw it with a very dim grey, or don't alternate shining a light on it and away). This provides the blinking.
_________________________
Asu no koto o ieba, tenjo de nezumi ga warau.
Talk about things of tomorrow and the mice in the ceiling laugh. (Japanese Proverb)
|
|
|
|
|
I need to do something like this
// somefile.h
namespace MyNamespace {
void* operator new ( unsigned int nAllocBytes )
{
return ::operator new( nAllocBytes );
}
};
// mainfile.cpp
int main( void )
{
int *p;
p = ( int* )MyNamespace::operator new( 2 );
delete p;
return 0;
}
But I would like to stick to new's sintaxe, so that I could do:
int main( void )
{
{
using namespace MyNamespace;
p = new int;
delete p;
}
return 0;
}
Anybody knows how?
regards [[]]
hint_54
|
|
|
|
|
Interesting.
One possible approach is typedef.
Kuphryn
|
|
|
|
|
Welcome back, Kuphryn - been a while since you were seen here
Regards,
Nish
|
|
|
|
|
Nice! you remember me!
Kuphryn
|
|
|
|
|
How?
thx
hint_54
|
|
|
|
|
Good point.
This can be done if new became something else. The syntax new cannot be replaced, or at least I have not been able to get the compiler to.
Kuphryn
|
|
|
|
|
I don't know exactly how you want to use your own new operator, but I was thinking about the DEBUG_NEW macro in MFC that is used for tracking memory leaks.
At the beginning of every .cpp file the new operator is #define'd as DEBUG_NEW in order to have a debug version of the new operator, like this:
#ifdef _DEBUG<br />
#define new DEBUG_NEW<br />
#endif
Perhaps this would be a way for your problem as well.
--
Roger
It's supposed to be hard, otherwise anybody could do it!
|
|
|
|
|
No. It's not that. I need to add a few bytes to each object "inside" a namespace for pointer reference counting and garbage colecting.
regards [[]]
hint_54
|
|
|
|
|
Do you need to be able to call the old version? If not, just implement your version in the global namespace, and every call to new will go to your new new (!!) method. You can implement new like this:
void *operator new(unsigned int nAllocBytes)
{
return malloc(nAllocBytes);
} Just make sure you overload delete as well, to call free()
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Just a question,
Will this work with class objects. I guess new calls the constructor of classes so that they can be properly initialized. But if you call malloc from new how will that work.
Nibu thomas
Software Developer
|
|
|
|
|
Nibu thomas wrote: Will this work with class objects.
Yes it will. Basically, new is responsible for allocating memory, and the compiler is responsible for calling the constructor. Same with delete - the compiler ensures the destructor is called before delete is.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
yes, it will work, but very badly... in fact it wont always work because malloc() and other C-style memory allocation functions are non-reentrant. so, this can come to some memory leaks...
i just don't understand why you advise him to use malloc() inside his overloaded new.
why not simply using ::new which refers to the global new (the one defined bu the compiler).
|
|
|
|
|
v2.0 wrote: why not simply using ::new which refers to the global new (the one defined bu the compiler).
Yes, I think that to.
regards
hint_54
|
|
|
|
|
Ryan Binns wrote: Do you need to be able to call the old version?
Yes, I do. The overloaded version of the operator should be inside a namespace. So I could do:
CSomething *p;<br />
p = new CSomething;
p = nMyNamespace::new CSomething;
<br />
{
using namespace nMyNamespace;<br />
p = ::new CSomething;
p = new CSomething;
}
Ryan Binns wrote: Just make sure you overload delete as well, to call free()
I've read somewhere that operator new expands to a call of malloc() and that delete expands to free(). But I'm not shure where that was or if it was a reliable source. So, for now i'll stick to calling the global version of the operator from inside the overloaded version.
regards [[]]
hint_54
|
|
|
|
|
hint_54 wrote: I've read somewhere that operator new expands to a call of malloc() and that delete expands to free()
Yep. It does in the implementations that I've investigated. That's why I suggested it.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I have a problem. In MFC, on a Dialog box, if a combo box shows dropdown list and user hits the Cancel button Dialog does not close immediately. It closes the Dropdown list ignoring the cancel button.
User has to push cancel button one more time to close the Dlg.
How can I make it close the dialog immediately?
Tahir Helvaci
|
|
|
|
|
Intercept the WM_KEYDOWN message in PreTranslateMessage() of your application class and check for ESC (i.e. 27) as parameter value. Then post a WM_CLOSE or a WM_QUIT to your main dialog window.
if (pMsg->message == WM_KEYDOWN)
{
switch (pMsg->wParam)
{
case 27:
PostQuitMessage(0);
return FALSE;
}
}
SkyWalker
|
|
|
|
|
Thanx for the reply but I wanna use mouse to click cancel button on the dialog box, not the keyboard.
THelvaci
|
|
|
|
|
Oh, sorry for understanding you wrongly.
Intercept then the mouse click.
SkyWalker
|
|
|
|
|
thelvaci wrote: if a combo box shows dropdown list and user hits the Cancel button Dialog does not close immediately. It closes the Dropdown list ignoring the cancel button.
User has to push cancel button one more time to close the Dlg.
How can I make it close the dialog immediately?
Yeah it happens. I guess it's so because when the combo list box comes up it captures the mouse(Using SetCapture ).
And now events that occur related to mouse will be relayed to the list box.
This is done so that the list box can be properly closed if the user clicks anywhere outside the list box. Now when the listbox closes it calls ReleaseCapture .
This is the reason why the cancel button doesn't get the mouse event when the list box is visible. But second time it does get.
Nibu thomas
Software Developer
|
|
|
|
|
Thanx for the reply.
I can give you an example: MS Word program File->Open->
In the File Open Dialog box you hit the combobox on top to open the directory tree. Dropdown list opens. Now when one hits the cancel button the drop down list closes immediately and this closes the file dialog.
How is this done?
Rgds
Tahir Helvaci
|
|
|
|
|
I wouldn't recommend trying to do this. It will make your application behave differently to every other Windows application in existance. Combo boxes work this way by design.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
Thanx for the reply.
I can give you an example: MS Word program File->Open->
In the File Open Dialog box you hit the combobox on top to open the directory tree. Dropdown list opens. Now when one hits the cancel button the drop down list closes immediately and this closes the file dialog.
How is this done?
Rgds
Tahir Helvaci
Thelvaci
|
|
|
|
|
Yes, I'd forgotten about MS Office. So Office and your program would be the only ones like it in the world. Almost all applications use the standard Windows File open common dialog box, which does not do this.
Personally, I still think it's a bad idea. I'm not sure what the best way to do it would be. There would be a few complications in getting it right.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|