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?
A very simple and realistically non-worthwhile implementation is simple. Your malloc calls new with an byte array. Then your free, which you would also implement would use delete to delete the array.
If you want a learning experience however then you should do the following in the specified order.
1. Learn what stack and list are and how to implement them.
2. Specifically learn how to implement them using sequential memory and not just pointers.
3. Learn how malloc is generally implemented. You will need substantial understanding of 1/2 to understand this.
4. Implement your own heap management. (Which you will understand after doing 1/2/3.)
There are no limitations to support different types of databases in one application. The application wizard only prepares the project to support a specific database interface. Support for other interfaces can be added later manually.
Create two new empty projects with support for different database interfaces. Then choose one as your project and add the necessary definitions from the created source files of the other project by comparing the files.
Thanks for reply.
Since wizard can relief my work. I just think is it possible to select both ODBC and OLEDB by using wizard.
If it is not possible, I have to implement the code myself.
That's hell a lot of work
Note that reading even a trivial excel file in an application can be a difficult task.
Once you have read the data the user interface and writing to a database is easier because there are more sources that one can learn from.