admin管理员组文章数量:1320591
I'm learning how to work with DLLs in Windows using C++, specifically with the LoadLibrary
and GetProcAddress
functions.
For practice, I've chosen libcurl as an example to experiment with dynamic linking. I managed to use libcurl as a DLL, but I had to define several constants in my own .cpp
file, such as:
#define CURLOPT_URL 10002
#define CURLOPT_POST 47
#define CURLOPT_POSTFIELDS 10015
#define CURLOPT_WRITEFUNCTION 20011
#define CURLOPT_WRITEDATA 10001
#define CURLE_OK 0
These are used in my code like this:
curlFunctions->easy_setopt(curl, CURLOPT_URL, request.url.c_str());
curlFunctions->easy_setopt(curl, CURLOPT_WRITEFUNCTION, writeCallback);
curlFunctions->easy_setopt(curl, CURLOPT_WRITEDATA, response);
My question is:
Since I'm dynamically linking to libcurl.dll
and not statically linking to libcurl.lib
, do I still need to include curl.h
in my project? Or, can I just use LoadLibrary
and GetProcAddress
to load and call functions from the DLL without the need for including the header?
I apologize if this is a basic question - I'm still learning the WinAPI and C++, and am trying to build a deeper understanding of these concepts.
EDIT
For clarification:
I added manually the #define
s in my project so I could test the LoadLibrary
and GetProcAddress
functions. It worked, and I could make HTTP requests.
Then, I tried to add curl.h
(so I don't have to declare manually the #define
s needed to perform the curl operations), but I get a bunch of warnings, because the compiler looks inside curl.h
and sees a lot of definitions, but of course I didn't implement them. I am importing the functions from the DLL using GetProcAddress
.
Warnings example (posting just 4, but there are 35 in total, all the same "function definition xxxxx not found"):
Function definition for 'curl_strequal' not found.
Function definition for 'curl_strnequal' not found.
Function definition for 'curl_mime_init' not found.
Function definition for 'curl_mime_free' not found.*
(...)
Example of how I am importing from libcurl.dll
(I cleaned it up a litlt bit just to show the "main" functions usage):
hModuleLibCurl = LoadLibrary(TEXT("libcurl-x64.dll"));
if (!hModuleLibCurl) {
return;
}
// Load function pointers
easy_init = (CurlEasyInit)GetProcAddress(hModuleLibCurl, "curl_easy_init");
easy_cleanup = (CurlEasyCleanup)GetProcAddress(hModuleLibCurl, "curl_easy_cleanup");
easy_setopt = (CurlEasySetopt)GetProcAddress(hModuleLibCurl, "curl_easy_setopt");
easy_perform = (CurlEasyPerform)GetProcAddress(hModuleLibCurl, "curl_easy_perform");
easy_getinfo = (CurlEasyGetinfo)GetProcAddress(hModuleLibCurl, "curl_easy_getinfo");
slist_append = (CurlSlistAppend)GetProcAddress(hModuleLibCurl, "curl_slist_append");
// Check if any of the function pointers failed to load
if (!easy_init || !easy_cleanup || !easy_setopt || !easy_perform || !easy_getinfo || !slist_append) {
FreeLibrary(hModuleLibCurl);
}
That's how I am using functions from inside the DLL. But, in order the perform operations, I need the CURLOPT_...
values (the ones that, initially I defined manually to test the code). So, after adding curl.h
, I get the warnings.
I think the main question is:
When dynamically loading a .dll
and using its functions, how to deal with the values that have been DEFINED (with #define
) inside the library? Should I statically link the header file, even though I'm trying to only load it dynamically? If so, how to deal with the warnings? A .h
contains way more functions than needs to be defined, but I don't need them all in my project.
I'm learning how to work with DLLs in Windows using C++, specifically with the LoadLibrary
and GetProcAddress
functions.
For practice, I've chosen libcurl as an example to experiment with dynamic linking. I managed to use libcurl as a DLL, but I had to define several constants in my own .cpp
file, such as:
#define CURLOPT_URL 10002
#define CURLOPT_POST 47
#define CURLOPT_POSTFIELDS 10015
#define CURLOPT_WRITEFUNCTION 20011
#define CURLOPT_WRITEDATA 10001
#define CURLE_OK 0
These are used in my code like this:
curlFunctions->easy_setopt(curl, CURLOPT_URL, request.url.c_str());
curlFunctions->easy_setopt(curl, CURLOPT_WRITEFUNCTION, writeCallback);
curlFunctions->easy_setopt(curl, CURLOPT_WRITEDATA, response);
My question is:
Since I'm dynamically linking to libcurl.dll
and not statically linking to libcurl.lib
, do I still need to include curl.h
in my project? Or, can I just use LoadLibrary
and GetProcAddress
to load and call functions from the DLL without the need for including the header?
I apologize if this is a basic question - I'm still learning the WinAPI and C++, and am trying to build a deeper understanding of these concepts.
EDIT
For clarification:
I added manually the #define
s in my project so I could test the LoadLibrary
and GetProcAddress
functions. It worked, and I could make HTTP requests.
Then, I tried to add curl.h
(so I don't have to declare manually the #define
s needed to perform the curl operations), but I get a bunch of warnings, because the compiler looks inside curl.h
and sees a lot of definitions, but of course I didn't implement them. I am importing the functions from the DLL using GetProcAddress
.
Warnings example (posting just 4, but there are 35 in total, all the same "function definition xxxxx not found"):
Function definition for 'curl_strequal' not found.
Function definition for 'curl_strnequal' not found.
Function definition for 'curl_mime_init' not found.
Function definition for 'curl_mime_free' not found.*
(...)
Example of how I am importing from libcurl.dll
(I cleaned it up a litlt bit just to show the "main" functions usage):
hModuleLibCurl = LoadLibrary(TEXT("libcurl-x64.dll"));
if (!hModuleLibCurl) {
return;
}
// Load function pointers
easy_init = (CurlEasyInit)GetProcAddress(hModuleLibCurl, "curl_easy_init");
easy_cleanup = (CurlEasyCleanup)GetProcAddress(hModuleLibCurl, "curl_easy_cleanup");
easy_setopt = (CurlEasySetopt)GetProcAddress(hModuleLibCurl, "curl_easy_setopt");
easy_perform = (CurlEasyPerform)GetProcAddress(hModuleLibCurl, "curl_easy_perform");
easy_getinfo = (CurlEasyGetinfo)GetProcAddress(hModuleLibCurl, "curl_easy_getinfo");
slist_append = (CurlSlistAppend)GetProcAddress(hModuleLibCurl, "curl_slist_append");
// Check if any of the function pointers failed to load
if (!easy_init || !easy_cleanup || !easy_setopt || !easy_perform || !easy_getinfo || !slist_append) {
FreeLibrary(hModuleLibCurl);
}
That's how I am using functions from inside the DLL. But, in order the perform operations, I need the CURLOPT_...
values (the ones that, initially I defined manually to test the code). So, after adding curl.h
, I get the warnings.
I think the main question is:
When dynamically loading a .dll
and using its functions, how to deal with the values that have been DEFINED (with #define
) inside the library? Should I statically link the header file, even though I'm trying to only load it dynamically? If so, how to deal with the warnings? A .h
contains way more functions than needs to be defined, but I don't need them all in my project.
1 Answer
Reset to default 2You should #include <curl.h>
if you want to use facilities provided by libcurl, regardless of the way you want to use them: static linking, dynamic linking, or via LoadLibrary
and GetProcAddress
.
You should not manually copy any #define
directives or anything else from curl.h
to your own code. There are many reasons why such manual copying is a bad idea. #include <curl.h>
literally copies the content of curl.h
to your source file each time you compile it. That's the way header files are meant to be used.
If you have a problem with building your program when having #include <curl.h>
in your code, you should ask a question about that problem.
本文标签:
版权声明:本文标题:c++ - When using dynamic linking (dll), how should i handle values that are #define inside the dll? - Stack Overflow 内容由网友自发贡献,该文观点仅代表作者本人, 转载请联系作者并注明出处:http://www.betaflare.com/web/1742085619a2419958.html, 本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容,一经查实,本站将立刻删除。
libcurl.h
define theCURLOPT_*
macros for you? Does it declareeasy_setopt()
? Did you try compiling without including the header? – JaMiT Commented Jan 18 at 1:05