If you are worried about the memory needed to store several values twice, you could define a class or struct, create an object of it in your view class and pass the reference to this object to the dialog objects in their constructors. This way you only have 4 byte overhead per dialog.
The good thing about pessimism is, that you are always either right or pleasently surprised.
RedrawWindow(hwnd,&d,nullptr,RDW_UPDATENOW | RDW_INVALIDATE | RDW_ERASENOW);
but when, with animation\timer, the next image is drawed above the older one, instead clean all control and then redraw it.
(i need avoid the flicker and draw the control correctly and not 1 image above other)
can anyone advice me?
Does anyone know if the Visual Studio C++ compiler optimizes to eliminate calls to functions with empty definitions (nothing between the curly braces denoting the function's body)?
I am particularly interested in the 2010 and 2012 versions of the Visual Studio compiler.
It depends on whether the method is virtual. It would theoretically be possible to eliminate all calls to empty non-virtual methods. A virtual method may be overridden by a derived class, so the compiler must perform the virtual call.
(There may be some cases where the compiler can prove that the virtual call refers to the base class. In this case, the compiler could optimize the call away.)
As Richard suggests, the best way to check this is to write a short test program.
If you have an important point to make, don't try to be subtle or clever. Use a pile driver. Hit the point once. Then come back and hit it again. Then hit it a third time - a tremendous whack.
I have an application which captures Lock, Unlock, Logoff and Logon events of Windows OS. I am able to get the notifications for Lock, Unlock and Logoff, but not getting any notification when user Logs on to the machine. I am using WTS_SESSION_LOGON event to capture the Log on event.
How to capture the event when user log on to the machine.
The following code is a basic algorithm for hamming distance calculation, but due to the design of my application, it requires many times to use this algorithm, in order to improve application efficiency, I want to improve the efficiency of this algorithm, is there any appropriate methods? Assembly language possible?
I don't see much optimisation options.
You are already using a lookup table and the code should not consume much time when dim is small. Rewriting it in assembler will be probably not faster because modern compilers will generate effective code (you may tell your compiler to generate an assembly output to check this).
When using the popcnt instruction and your data are always a multiple of 2 or 4 (or 8 with 64-bit builds), you can reduce the number of loop executions by performing the operation with 16/32/64 bits.
I wouldn't recommend assembly, unless platform portability is not a concern. A relatively easier option would be to apply a Duff's device to this loop. Unrolling the loop can provide performance boost. However, unless this is, say DSP code that has to run over and over again its probably not worthwhile and the effects wont be noticable.
I don't see much optimization potential in your function that a decent compiler won't apply already.
That said, the first question you should ask: is there an actual performance bottleneck? Have you measured the time your application takes, and is it really too slow for your purposes?
Second question: if there is a performance issue, which function is causing it? Maybe there are others called alongside this function that take more time and have more optimization potential? Typically, I/O is the slowest part of any application, so reducing I/O to the absolute minimum could already help.
You say it is called often, so the next question would be: can you reduce the number of calls? You said the number of calls is high due to your application design, this implies a different design would require less calls?
GOTOs are a bit like wire coat hangers: they tend to breed in the darkness, such that where there once were few, eventually there are many, and the program's architecture collapses beneath them. (Fran Poretto)
If you are linking for 64bits the entry point for dll should be _DllMainCRTStartup (undecorated entry point). If you get this error probably there is a error in linker switches because it seems that you are trying to use 64 bits objects in a 32bits link.
It is not very clear in which part of your project you're getting the error: compiling the console exe or one of the DLL?