while(!_kbhit())
{
do_something()
}
The problem here is that do_something was the method I needed to test, but _kbhit was adding a lot of extra time to each call and I was not meeting my timing. Spent a few hours trying to improve the do_something code just to find out all I had to do was call _kbhit less often.
Another gotcha is .LIB files. .LIB are like DLLs except they are compiled into the EXE file. That way you don't need to have lots of dlls with the program. The problem with lib files is they need to be build the exact same way your program is built. DLLs run in their own little memory space, while LIB share the memory space with your EXE. If you program uses Foo-v2.dll while the LIB file was compiled to use Foo-v1.dll you'll have a conflict. This shows up when the LIB file is compiled for RELEASE, and your EXE is compiled for debug. If the lib tries to allocate memory, it will use the release version of the C-library and allocate on its heap. You're program will use the debug version of the C-library and allocate on its heap. Now you have memory allocated on two different heaps. When the program closes, C will check all the memory to ensure their wasn't any memory leaks or what not. This is a great feature if you are in debug mode. When its checking the memory, it is expecting everything to be on the 'debug heap'. It will find memory allocated from the LIB file on the 'release heap' and throw a big warning about a possible memory leak because it found memory outside of where it should have been. Moral of the story is build your LIB files with the same memory model and linked libraries as you will build your EXE. If you are giving the LIB to someone else give them a debug and release version and make sure all the other linked libraries are the same.
No comments:
Post a Comment