Is there a better way to load a dll in C++?

After building your .dll get the .lib file nearby and link your test application with it. Use functions as they are declared in .h

There's a minor change you need to do in your header file:

#ifdef EXPORTS_API
  #define MY_API_EXPORT __declspec (dllexport)
#else
  #define MY_API_EXPORT __declspec (dllimport)
#endif

extern "C" {
    int MY_API_EXPORT Factorial(int n);

    // do the same for other functions
}

This way, when building your dll you define EXPORTS_API in your project settings and functions get exported, in the client application, no need to define anything.

In the Windows world, there are (at least) 4 ways to use DLLs:

1. Run-Time Dynamic Linking (What you're doing now)
2. Load-Time Dynamic Linking (the "typical" way of using DLLs)
3. Delay-Load Dynamic Linking
4. DLL Forwarding

I don't have to explain Run-Time Dynamic Linking since you're already doing it. I choose not to explain Delay-Load Dynamic Linking now beyond just describing what it is in general terms. Delay Load is essentially the same as Load-Time Dynamic Linking except it's done Just-In-Time instead of at application load. This is not as useful or as beneficial as you might think, it is difficult to work with and tricky to code for. So let's not go there, at least for now. DLL Forwarding is even more exotic than Delay-Loading -- so exotic, I'd never even heard of it until @mox mentioned it in the comments. I'll let you read the link above to learn about it, but suffice it to say that DLL Forwarding is when you call an exported function in one DLL but that request is actually forwarded to another function in a different DLL.

Load-Time Dynamic Linking

This is what I would consider to be Vanilla DLL Linking.

This is what most people are referring to when they refer to using DLLs in their applications. You just #include the DLL's header file and link to the LIB file. No need to GetProcAddress() or create function pointer typedefs. Here's how it works in a nutshell:

1. You typically get 3 files: a DLL with the runtime code, a LIB file and a header file. The header file is just a header file -- it describes all the facilities in the DLL you can use.

2. You write your application, #include'ing the header file from the DLL and making calls to those functions just like you would use any function in any header file. The compiler knows the names of functions and objects you use because they are in the DLL's header file. But it doesn't know where they are in memory yet. That is where the LIB file comes in...

3. You go to the linker settings for your project and add an "additional library dependency," specifying the LIB file. The LIB file tells the linker where the functions and objects you use from the H file reside in memory (in relative terms, not absolute terms, obviously).

4. Compile your app. If you have set everything up correctly it should compile, link and run. When you get "unresolved external reference" linker errors commonly this is due to things not being set up right. You may either have not specified the correct path to the LIB file or you need to include more LIB files.