If you use lib + dll，you don't need __declspec(dllimport) because all the functions or variables you wan't to import have defined in lib as pointer;but if you use LoadLibary API to import dll, with __declspec(dllimport) you can tell the compiler which function or variable you want to import, it will reduce the import time
In C++, when you use a dynamic link library (DLL), your code doesn’t need to directly include the DLL file to successfully use the functions within it. This is due to several crucial components and steps: 1. Import Library: During compilation, the linker uses an import library ('.lib' file) to resolve references to functions in the DLL. The import library contains all the export function symbols but does not include the actual implementation of these functions. It informs the linker where these functions will be found in the corresponding DLL. You only need to include this import library in your project settings so the linker can resolve function references at compile time. 2. Header File: The header file typically contains the declarations of all the functions you want to import from the DLL. The compiler needs this header file to check the correctness of the function calls. However, the header file does not contain the actual implementation, which is provided by the DLL at runtime. 3. Dynamic Loading: At runtime, the system loads the required DLL based on references to functions from the DLL and resolves these references. When the executable starts running, the Windows operating system handles locating and loading the necessary DLL file and resolving the function addresses, allowing the program to correctly call the functions exported from the DLL. 4. Implicit and Explicit Linking: - Implicit Linking: This method involves linking against an import library ('.lib') during compilation. At runtime, the operating system automatically loads and resolves the DLL. this is the linking method used in the video. You do need to provide the import library during the compile and link stage, such as "cl myprogram.cpp mylib.lib". For example: ''' #include "mylib.h" // Header file containing the DLL function declarations int main() { MyFunction(); // Directly call the function from the DLL return 0; } ''' - Explicit Linking: This method uses Windows API functions like 'LoadLibrary' and 'GetProcAddress' to dynamically load the DLL and manually resolve the function addresses at runtime. In this approach, you don’t need the import library at compile time. Instead, you dynamically load the DLL and resolve function addresses at runtime. omit the example. to answer you question shortly, in this case, you are using Implicit linking and you provided the .lib file accordingly at compile time so that you don't need to specify the .dll in the program body. however, if you dont have the coordinated .lib file at the compile time (or any other reasons), them you have to specify where(in which dll) to find the function at runtime and call the function via the resolved function pointer. kindly tell me if anything above is wrong.
@@NycroLP I like the content of this channel but the guy is not consistent, he has series unfinished, there is no schedule of videos... I mean, he does this because he wants, so ok I guess
@@drisicus Are you serious? How is he not consistent? He got 90 videos on this playlist and still keep doing it. Lots of people learned tons of the information from him. If you think you can do better go for it I'll follow you.
@@bulentgercek bro, this was not meant as an attack towards him and you are being illogical. Cherno said he would pin a comment but he didn't, that's all this is about.
This is because the DLL still has an IAT, Import Address Table. It will still load the functions from the IAT, but as Yuval said if you specify it as import when compiling the compiler will generate imports as imp__func_decl and it will do optimizations to ensure import is efficient. However what hasn't been said yet is this is only optional for function declarations so if you use public data members there is no IAT entry for them, and you need dllimport or else the data will be local to the compilation unit or compiling program depending on what other modifiers are used.
I am sorry but I have no idea what u said. Can u provide any resources that explains this in detail? Also, any resources that explain linking stuff more
Because you already linked the static library that came with the dll with all the declarations of functions within the dll, it knows where to look for them, except it's maybe slightly less efficient.
Header. He linked and included the library header file. Not the library itself (he did dynamically linked the library itself but it doesn't matter for this answer).
Concerning the __declspec(dllimport), if we dont set it the compiler compiles the function call glfwInit(); to something like call glfwInit inside the object file. The linkers job is to resolve this. If we don't add the __declspec(dllimport) then the linker generates something like call 0x4000000 which directs the flow of the program to a function thunk. A thunk is something like a dummyfunction without ret statement at the end which simply jumps to another address. This thunk could look like jmp DWORD PTR __imp_glfwInit and the pointer __imp_glfwInit will then be set when the dll is loaded into memory using the IAT to point to the correct function. On the other hand, if we set __declspec(dllimport) we explicitly tell the compiler at compiletime that we want to use a function inside a dll. Thus we get the asm code call DWORD PTR __imp_glfwInit again __imp_glfwInit beeing set at runtime through the IAT. This saves the thunk memory and the jmp instruction.
My solution of the homework is: because we are using static linking, we don't need to use __declspec(dllimport). But if we are using dynamic linking, we might need to use __declspec(dllimport) to let the compiler know that the function is inside the dll file.
It is actually dynamic linking at the end, not static linking, because you need the dll file anyways. Unless you're specifically talking about the lib file accompanied with the dll file.
i checked the disassembly, if we dont define declespec dllimport by adding glfwdll in preprocessor, disassembly will have one more code "qword ptr [imp_glfwinit]", we are treating our library like a extern function. if we use declspec it will have directly one code "call glfwinit" this generate more efficient code because it have one less instruction
Thanks for the video, most of the videos posted in UA-cam have similar contents. But yours is really interesting and felt I have learnt something new. I am currently try to do something with depth camera, since the technology is something advance its hard to find tutorial online. So, thought of digging deeper into every components of C++ and start doing the project by myself. You saved me!!!! thanks for the help...
I followed the file configuration in your previous video and my .exe file is in the project/bin/Win32/Debug, so I need to paste .dll file into this directory and it worked. Actually many places have the .exe file and only this one work. Thanks!
It is a trick question. It does bot matter if you define it beforehand or not. It is not checking whether it is defined (there is no #ifndef GLFWAPI). It will be redefined in the header file.
hey bro if you find great make tutorials can you send me too? Edit: BTW i watched your target following video. Which company do you work for in turkey if you are working.Just curious.
8:00 It's not clear to me why you would have if else statements for dllexport and dllimport in the same file. If you are using particular code to build a dll (hence using dllexport), how and why would you ever use dllimport here?
afaik Makefiles are not needed when working in Visual Studio, as VS does that work for you. if you are working with the GNU compiler stuff where you compile your stuff from the command line then a makefile saves you the minutes of typing out commands.
If you're using VS with a *nix project you'll have to use a converter that takes the Makefile and generates a VS solution/project file for you but it rarely works since Makefiles can (and usually do) contain some arbitrary logic. This makes sense because if you don't need to automate something you'll end up with a pretty basic Makefile that is often not really needed (it'd help if you were editing your code in Notepad or equivalent but fully fetched IDEs often handle "standard" cases for you on-the-fly as in: generate in-memory Makefiles using a link-tables of known libraries and discard those Makefiles after compilation is done - its possible because to decide whether any given source file should be compiled or not it is enough to compare its last modification date with the creation date of its target/output file).
When you statically link the lib it doesn’t define glfw_dll because it already has all the function declarations for it during compile time. When you define this macro, it still knows where to look for the declarations; inside the dll at run time.
Defining GLFW_DLL is not necessary because when you call one of the functions in your program it links to the function in the glfw3dll.lib which then links to the function in the glfw3.dll.
My error is that myfilename.dll is missing, try reinstalling (same as yours) but when I place my dll file in debug with exe file of the project it gives me errors about VCRUNTIME and MSVC dll files...why is that?
If you are using mingw, so g++ (or gcc if you are compiling c), you need to add your include directories with "-I" and include library directories with "-L" and include the actual libraries with "-l". This is usually done with a makefile/cmake file to automate the process. The same is true if you are compiling with msvc's compiler through the CLI (except the API for specifying directories and libraries is a bit different), or clang (which afaik supports the same argument format as gcc/g++, or provides a binary that supports that argument format)
Hey Cherno! I had a question, I've been trying to figure out. I was curious if you could help c: I've been studying the Vulkan API, I dunno if you've looked into it at all; however, the backbone of the API is called the Loader, which you link against when you link Vulkan. The Loader is responsible for routing things to the right places, and handling system compatibility. The Loader has different functions for different systems. It can handle processing the functions for you; however, it also gives you the ability to retrieve the function pointer for the appropriate function for that instance, and mapping them to a dispatch table. They do this to mitigate using the Loader as a stage of overhead unless necessary I don't expect help with the Vulkan side of things, but I was curious if you could help me fully wrap my head around dispatch tables and function pointers to external libraries. I've done some searching and found that you can map functions to values using the std::map. In a situation like this how would you go about populating the appropriate data though? Does it require micromanagement? I feel it's kind of similar to the content in the video, though with Vulkan they added a layer inbetween the library and the application to handle system dependencies. I feel this might be something useful to understand in general if it helps with cross compatibility. I appreciate any help you can give c:
.h file would have __declspec declaration for the library. Is that the reason. Also would have been nicer if you could include the difference in memory size of executables in static and dynamic link library
Can you make a video about classes (or methods i don't really know) which they use this thing? I don't know what it's purpose is. For example: My_Class_Type *myVar;
In dynamic linking, the g++ preprocessor gets all the information that the Windows dynamic linker needs to link whatever DLL is needed at runtime. At compile->assemble time, the DLL is only referenced in terms of modification information in the binary information generated by the preprocessor, so the assembler is blind to the DLL itself, until runtime, when the linker finally calls the information it needs from the preprocessor. In the static version, the linking step simply happens at the compile time, because the assembler gets all the information it needs from the statically linked file at compile time. This is why the dynamic version only works when you tell the preprocessor that it is working with the dynamic linker. Is this correct?
@@cipsasmiaumiau3773he has a video on it I'm pretty sure. In short cuz many large codebases have large number of namespaces with the same function name and that can really mess up the code. Like we have std::vector but game engines can have a vector function with a different purpose altogether and that may cause issues and confusion
We do not need to use __declspec(dllimport) to link to the GLFW functions in a DLL file because the necessary import/export attributes are already included in the GLFW header files and source code.
@arunabhbhattacharya5314 that's not quite correct. the GLFW header file does not contain all the necessary information to link to the DLL file alone. Although it does define GLFWAPI as __declspec(dllimport), this will only happen if GLFW_DLL has already been defined, else __declspec(dllimport) will not be selected from the #ifdef block! All the function pointers in the header are prefixed with GLFWAPI, which the preprocessor has to interpret based on the #ifdef block conditions If GLFW_DLL is NOT defined, then GLFWAPI is NOT interpreted as __declspec(dllimport)! Or, for example, if GLFW_BUILD_DLL is defined instead, then GLFWAPI becomes __declspec(dllexport) instead! We do not need to put __declspec(dllimport) in front of every function pointer in the header file, because GLFWAPI becomes __declspec(dllimport) when GLFW_DLL is defined! The real question however, is why do we not need to define GLFW_DLL to let the preprocessor know how to interpret GLFWAPI?? In other words, where is #define GLFW_DLL written so that we did not need to define it ourselves? And the answer is, as other people have said, GLFW_DLL is defined in glfw3.dll.lib, the static library which pairs with glfw3.dll, the dynamic library! This is why we do not have to #define GLFW_DLL in the project properties, because it is already in glfw3.dll.lib and therefore when the preprocessor reads the header and gets to the #ifdef for GLFWAPI, then it chooses to interpret any GLFWAPI prefix in the rest of the file as __declspec(dllimport) without us manually defining GLFW_DLL. Hope this helps to understand what is happening here!
@@sephirapple7317love it. Had to scroll so much to get to the correct answer. Cherno didn't frame the question clearly tbh. I got the correct gist but others in the comment section really confused me, cuz most were answering a really different question, misunderstanding it as static linking when it's dynamic. Reading your reply really helped thanks
Hello Cheom Can it possible to package a winform in DLL and export the dll function for third party use? I do it done but error when I use the DLL. It's always happen below: 1.Winform show only when I import dll at the first time. 2.In third party journal, it always show can't find the function name in dll. About a winform in DLL am I right? Thank you very much.
Hey.... Suppose dll returns STL container such as vector. Main gets that vector and assigns to a new vector. Both dll and exe compiled using same runtime library ( Multi Threaded Dll or MT) ,my exe crashes. But then when I compile using debug versions it works fine ....... Any idea how to fix this ? Basically I want to know how to return STL containers from dll to exe.
Answer to the last question raised in the video: Because we statically load that *dll.lib library which does all things that is necessary for dynamic loading for us.
Great tutorials! What if I want to put my dll in some subdirectory of my executable, or if I have several search paths with the same dlls and it does not know where to look. Can I tell the executable to link to a specific dll and not other found? Thank you very much
You can only provide dll name in implicit dll linking, the dll location should be in search path (%PATH% environment variable) beforehand. You can change %PATH% environment variable user/system wide or make a script that sets this path and then executes your program, because you can't change %PATH% before linking stage by an exe itself.
Because you told the linker to explicitly link to the dll.lib library. So I guess the compiler disregards the preprocessor definitions. Just a wild guess.
Hi cherno. Need some help. I have one c++ dll file . I want to use this DLL into c# to create windows form application but when I try to load through add reference I get error. I tried another way by using system.runtime. interopservices in that DLL_import in built function is there but in my DLL I have function which takes one argument as structure member when I call that function it says undefined member ( it is not able to find that structure). So can please provide some solution with example where u have c++ DLL which contains one function and has structure argument
Nice tutorial! I seem to get it, but in the end, something does not work for me. I have a library (namely Armadillo) with library files blas.lib and blas.dll. I supply a path to the library files "-L path/to/libs" and specify I want to use this library file, i.e.: "-lblas". There are two things I have a problem with: 1. When both files are present in the specified directory, how does compiler know which file (.dll or .lib) must be linked? In other words, how does the compiler distinguish that user wants to perform static or dynamic linking? 2. When I supply only .lib file, I expect that static linking has been done, so there should be no need for putting .dll library in the solution folder, however, it is not the case and the executable won't run properly. I will be glad for any feedback, thanks!
Artho Pacini For Linux just get glfw and glew from your package manager. Then check which libs you need via pkgconfig and simply list them for gcc. Then you're done.
You did define GLFW_DLL but you didn't add any reference to it so it really doesn't matter, the pointers from static dll library file are still the ones doing the job and thus nothing changes.
Because the _WIN32 and GFLW_DLL are now both defined, the elif defined(_WIN32) && defined(GLFW_DLL) evaluates to true. Consequently, GLFWAPI evaluates to __declspec(dllimport).
I'd just add a small comment. The second time you compiled your DLL, you didn't copy the new version over to where the .exe file lives. That means the second time you ran it, your exe used the older version of your dll. Moving the DLL should be made part of the build automatically with a custom build step. Someone new to DLL's can get frustrated when they make a change to the DLL code, hit 'Build All', and their change doesn't seem to work. Manually copying the DLL outside of VS means VS doesn't know how to update that copy. (go ahead, ask me how I learned this... lol )
The static library glfw3dll.lib takes care of importing the dll data for you, if you didn't link that static library you would need to define GLFW_DLL, and would be able to use just the dynamic library glfw3.dll
Dario Mylonopoulos, actually if you didn't use the static library you would need to do a lot more. You would need to call LoadLibrary to load the dll and then call GetProcAddress to get pointers to functions from the dll. This is essentially what GLEW does. It loads functions from the driver's dll
How do you do linking without a fancy IDE? I prefer command line and simple text editors. Most other languages have configs files for this kind of thing, what about C++?
You should really get used to using an IDE man, you might be okay on small projects but once you get to working on anything of decent size you won't be able to do it. That being said for MSVC look at the cl.exe command line flags: msdn.microsoft.com/en-us/library/f35ctcxw.aspx
I find that using IDEs leads people to not actually understand how the code all fits together. I do use intelliJ at work sometimes but I really prefer sublime text and the good ol' command line. Plus I use linux generally which has limited support for Microsoft products and IDEs. I've been attempting to use your lessons to build a game that I can compile to web assembly and run in the browser. Keep up the good work man, loving it!
@Kishore G. I've been using Emacs for school, and visual studio for anything I do as personal projects. I feel like emacs is such a pain to use (probably just inexperience), but it is much better than vim IMO. However, some of the most basic features seem to be missing (like going to the definition of a function). How do you enable that at work? Or do you end up just using grep all of the time? I had some luck using gtags and hitting m-., but half of the time it takes me to the wrong definition.
I know it's a bit of a late reply but... Generally the way to go about it if you don't want to use an IDE is to use make/cmake to automate the compilation. FWIW if you are using Visual Studio you can enable a more verbose build output which shows you the exact CLI commands used to build the solution. (Tools -> Options... -> Projects and Solutions -> Build and Run: set "MSBuild project build verbosity:" to "Detailed" or "Diagnostic", or if you prefer the log file - set the "MSBuild project build log file verbosity:" to "Detailed" or "Diagnostic"). If you are using GCC/G++ or clang then the command line arguments format are a bit different from MSVC's, but overall require the same stuff (specifying include directories, specifying library directories, specifying libraries). At that point you are better off making a makefile for any project that is a bit larger, which will allow you to automate the build process (you'd only have to type "make" in the command line to build the project). Basically an IDE makes the process of making a makefile easier (in fact visual studio uses a slightly different form equivalent to makefiles in its project files, but overall it achieves the same goal).
Does anyone knows how to do this using g++. The AI i am consulting to atm does not tell anything about macro definition in the source code. I have three source files: 1. vec2d.cp 2. triangle.cpp 3. zone.cpp triangle.cpp depends on vec2d.cpp and zone.cpp depends on triangle.cpp and vec2d.cpp. My strategy: 1. compile all .cpp files into .o file command: Example: g++ -c vec2d.cpp -o vec2d.o g++ -c triangle.cpp -o triangle.o g++ -c zone.cpp -o zone.o 2. link the object files when there is usage into a single .dll file. g++ vec2d.o triangle.o zone.o -o zone.dll Cannot remember whether this is the command. Objectively, we want zone.dll 3. Write a consumer code that depends on zone.dll by including its respective .h files. for example, #include "zone.h" 4. compile the consumer code into .o file g++ -c consumer.cpp -o consumer.o 5. Link consumer.o to zone.dll g++ consumer.o -L. -l:zone -o program */Unfortunately i got linker error exception at this point because it cannot find zone.dll in the linker's search path.
On which operating system do you use g++? If on linux there's no such thing as dll, it's windows thing. Linux has shared objects files with .so extension.
this is literally the meme about programmers that goes
it's not working, why?
it's working, why?
"The rest is trivial and left as an exercise for the reader."
it's not working?
other programmers: Too Bad!
If you use lib + dll，you don't need __declspec(dllimport) because all the functions or variables you wan't to import have defined in lib as pointer;but if you use LoadLibary API to import dll, with __declspec(dllimport) you can tell the compiler which function or variable you want to import, it will reduce the import time
logically this seems like a legit correct answer to the question
In C++, when you use a dynamic link library (DLL), your code doesn’t need to directly include the DLL file to successfully use the functions within it. This is due to several crucial components and steps:
1. Import Library:
During compilation, the linker uses an import library ('.lib' file) to resolve references to functions in the DLL. The import library contains all the export function symbols but does not include the actual implementation of these functions. It informs the linker where these functions will be found in the corresponding DLL. You only need to include this import library in your project settings so the linker can resolve function references at compile time.
2. Header File:
The header file typically contains the declarations of all the functions you want to import from the DLL. The compiler needs this header file to check the correctness of the function calls. However, the header file does not contain the actual implementation, which is provided by the DLL at runtime.
3. Dynamic Loading:
At runtime, the system loads the required DLL based on references to functions from the DLL and resolves these references. When the executable starts running, the Windows operating system handles locating and loading the necessary DLL file and resolving the function addresses, allowing the program to correctly call the functions exported from the DLL.
4. Implicit and Explicit Linking:
- Implicit Linking: This method involves linking against an import library ('.lib') during compilation. At runtime, the operating system automatically loads and resolves the DLL. this is the linking method used in the video. You do need to provide the import library during the compile and link stage, such as "cl myprogram.cpp mylib.lib". For example:
'''
#include "mylib.h" // Header file containing the DLL function declarations
int main() {
MyFunction(); // Directly call the function from the DLL
return 0;
}
'''
- Explicit Linking: This method uses Windows API functions like 'LoadLibrary' and 'GetProcAddress' to dynamically load the DLL and manually resolve the function addresses at runtime. In this approach, you don’t need the import library at compile time. Instead, you dynamically load the DLL and resolve function addresses at runtime. omit the example.
to answer you question shortly, in this case, you are using Implicit linking and you provided the .lib file accordingly at compile time so that you don't need to specify the .dll in the program body. however, if you dont have the coordinated .lib file at the compile time (or any other reasons), them you have to specify where(in which dll) to find the function at runtime and call the function via the resolved function pointer.
kindly tell me if anything above is wrong.
cherno is a blessing for programmer community. awesome tutorial
damn 3 years now and no one answered the question 😂😂
replying you after 3 years few have answers this but noone got pinned lol
@@Lelouch-vi-Britania replying to you after 8 month and still no one is pinned lol
7 😭
@@Maanjiro_g +3 weeks
None
I see no pinned comments.. no one answered it correctly?
I think people did but he doesnt care I guess.
Am up writing idk perfect English fluently thxs
@@NycroLP I like the content of this channel but the guy is not consistent, he has series unfinished, there is no schedule of videos...
I mean, he does this because he wants, so ok I guess
@@drisicus Are you serious? How is he not consistent? He got 90 videos on this playlist and still keep doing it. Lots of people learned tons of the information from him. If you think you can do better go for it I'll follow you.
@@bulentgercek bro, this was not meant as an attack towards him and you are being illogical.
Cherno said he would pin a comment but he didn't, that's all this is about.
Absolute legend! I kept getting .dll missing errors, and this solved it.
This is because the DLL still has an IAT, Import Address Table. It will still load the functions from the IAT, but as Yuval said if you specify it as import when compiling the compiler will generate imports as imp__func_decl and it will do optimizations to ensure import is efficient.
However what hasn't been said yet is this is only optional for function declarations so if you use public data members there is no IAT entry for them, and you need dllimport or else the data will be local to the compilation unit or compiling program depending on what other modifiers are used.
I am sorry but I have no idea what u said. Can u provide any resources that explains this in detail? Also, any resources that explain linking stuff more
I am currently binge watching this and one thing that amazes me: The hair dude. How did he manage to mess up a hair within 10 days????
lol
8:38 That french throat at "exactly" killed me :D
I'm french and i have no idea how this is french xD Sounds more arabic.
He always pronounces exactly as egzakhtly, like russian Х
Me: It's not working, why?
The Cherno: It works, why?
Todd Howard: It just works!
Because you already linked the static library that came with the dll with all the declarations of functions within the dll, it knows where to look for them, except it's maybe slightly less efficient.
I'm new to this, but I guess this is the right answer.
Header. He linked and included the library header file. Not the library itself (he did dynamically linked the library itself but it doesn't matter for this answer).
You literally saved me. Thank you for your work!
the original Daniel
@@danielkrajnik3817 we found him.
Concerning the __declspec(dllimport), if we dont set it the compiler compiles the function call
glfwInit();
to something like
call glfwInit
inside the object file. The linkers job is to resolve this. If we don't add the __declspec(dllimport) then the linker generates something like
call 0x4000000
which directs the flow of the program to a function thunk. A thunk is something like a dummyfunction without ret statement at the end which simply jumps to another address. This thunk could look like
jmp DWORD PTR __imp_glfwInit
and the pointer __imp_glfwInit will then be set when the dll is loaded into memory using the IAT to point to the correct function.
On the other hand, if we set __declspec(dllimport) we explicitly tell the compiler at compiletime that we want to use a function inside a dll. Thus we get the asm code
call DWORD PTR __imp_glfwInit
again __imp_glfwInit beeing set at runtime through the IAT. This saves the thunk memory and the jmp instruction.
nicely explained, cheers
Can u please recommend resources that explore this in more detail?
@@anonymoussloth6687 search for "importing functions using declspec dllimport" inside the microsoft docs
Thank you for this.
Previous video: new haircut
This video: crazy hair
Me: You are a wizard, Cherno!
With MINGW, you can link the standard library statically or dynamicly essentially.
I was one of those asking for hw/challenges. I'm glad you started doing that!
Hello Friend
My solution of the homework is:
because we are using static linking, we don't need to use __declspec(dllimport). But if we are using dynamic linking, we might need to use __declspec(dllimport) to let the compiler know that the function is inside the dll file.
It is actually dynamic linking at the end, not static linking, because you need the dll file anyways. Unless you're specifically talking about the lib file accompanied with the dll file.
i checked the disassembly, if we dont define declespec dllimport by adding glfwdll in preprocessor, disassembly will have one more code "qword ptr [imp_glfwinit]", we are treating our library like a extern function. if we use declspec it will have directly one code "call glfwinit" this generate more efficient code because it have one less instruction
"Hey, my name's The Cherno and welcome back *CRACK* to my C++ series."
"Hey my name is the chana and welcome back to my estate plus plus series" XD
Thanks for the video, most of the videos posted in UA-cam have similar contents. But yours is really interesting and felt I have learnt something new. I am currently try to do something with depth camera, since the technology is something advance its hard to find tutorial online. So, thought of digging deeper into every components of C++ and start doing the project by myself. You saved me!!!! thanks for the help...
Because you're already linking against a .lib file that has all the pointer definitions defined.
I never flunked any C++ interview.. (technical + theory) since I started learning C++ from you.
Design rounds are some other headache though
Thanks so much, I tried to install a library but I didn't even know how to do it, but with your help I did it and I learn about it :)
I followed the file configuration in your previous video and my .exe file is in the project/bin/Win32/Debug, so I need to paste .dll file into this directory and it worked. Actually many places have the .exe file and only this one work. Thanks!
This has been really helpful, thank you
It is a trick question. It does bot matter if you define it beforehand or not. It is not checking whether it is defined (there is no #ifndef GLFWAPI). It will be redefined in the header file.
my guess is because the functions are still defined in the library even though the actual code is in the dll.
What is GLFW? how can I follow with you if I can recreate the steps you are showing?
Homework answer: GLFW does not provide any of the API headers .They are provided by your development environment
9:00 maybe some how static lib that we link for function declaration define it for us.
Great lesson! I did not find the next video for learning how to build a DLL working at Run Time, which one is it?
Personal Notes:
- Static linking happens at compile time, dynamic linking happens at runtime (better to learn usage for linux and cmake)
hey bro if you find great make tutorials can you send me too?
Edit: BTW i watched your target following video. Which company do you work for in turkey if you are working.Just curious.
8:00 It's not clear to me why you would have if else statements for dllexport and dllimport in the same file. If you are using particular code to build a dll (hence using dllexport), how and why would you ever use dllimport here?
Can you please explain about MakeFiles and their implementations in Visual Studio?
afaik Makefiles are not needed when working in Visual Studio, as VS does that work for you. if you are working with the GNU compiler stuff where you compile your stuff from the command line then a makefile saves you the minutes of typing out commands.
If you're using VS with a *nix project you'll have to use a converter that takes the Makefile and generates a VS solution/project file for you but it rarely works since Makefiles can (and usually do) contain some arbitrary logic. This makes sense because if you don't need to automate something you'll end up with a pretty basic Makefile that is often not really needed (it'd help if you were editing your code in Notepad or equivalent but fully fetched IDEs often handle "standard" cases for you on-the-fly as in: generate in-memory Makefiles using a link-tables of known libraries and discard those Makefiles after compilation is done - its possible because to decide whether any given source file should be compiled or not it is enough to compare its last modification date with the creation date of its target/output file).
use cmake to generate makefiles
When you statically link the lib it doesn’t define glfw_dll because it already has all the function declarations for it during compile time. When you define this macro, it still knows where to look for the declarations; inside the dll at run time.
Homework answer: we know that we have putted the dll in the folder that's why we don't need to define gflws_api
so what about instance of the DLL in main memory? Do we have multiple instances of these library in main memory while 2 programs use them ?
defining the headers is the reason cause dynamic lib way is using precompiled headers
Defining GLFW_DLL is not necessary because when you call one of the functions in your program it links to the function in the glfw3dll.lib which then links to the function in the glfw3.dll.
My error is that myfilename.dll is missing, try reinstalling (same as yours) but when I place my dll file in debug with exe file of the project it gives me errors about VCRUNTIME and MSVC dll files...why is that?
but how do I do that with the GNU Compilers? the way you show is IDE-based but how is it done when you compile on CLI?
If you are using mingw, so g++ (or gcc if you are compiling c), you need to add your include directories with "-I" and include library directories with "-L" and include the actual libraries with "-l".
This is usually done with a makefile/cmake file to automate the process.
The same is true if you are compiling with msvc's compiler through the CLI (except the API for specifying directories and libraries is a bit different), or clang (which afaik supports the same argument format as gcc/g++, or provides a binary that supports that argument format)
Hey Cherno!
I had a question, I've been trying to figure out. I was curious if you could help c:
I've been studying the Vulkan API, I dunno if you've looked into it at all; however, the backbone of the API is called the Loader, which you link against when you link Vulkan.
The Loader is responsible for routing things to the right places, and handling system compatibility. The Loader has different functions for different systems. It can handle processing the functions for you; however, it also gives you the ability to retrieve the function pointer for the appropriate function for that instance, and mapping them to a dispatch table. They do this to mitigate using the Loader as a stage of overhead unless necessary
I don't expect help with the Vulkan side of things, but I was curious if you could help me fully wrap my head around dispatch tables and function pointers to external libraries.
I've done some searching and found that you can map functions to values using the std::map. In a situation like this how would you go about populating the appropriate data though? Does it require micromanagement? I feel it's kind of similar to the content in the video, though with Vulkan they added a layer inbetween the library and the application to handle system dependencies.
I feel this might be something useful to understand in general if it helps with cross compatibility. I appreciate any help you can give c:
.h file would have __declspec declaration for the library. Is that the reason. Also would have been nicer if you could include the difference in memory size of executables in static and dynamic link library
Can you make a video about classes (or methods i don't really know) which they use this thing? I don't know what it's purpose is. For example: My_Class_Type *myVar;
Bro, I think you are referring to template programming. He has a video regarding it. search his series.
In dynamic linking, the g++ preprocessor gets all the information that the Windows dynamic linker needs to link whatever DLL is needed at runtime. At compile->assemble time, the DLL is only referenced in terms of modification information in the binary information generated by the preprocessor, so the assembler is blind to the DLL itself, until runtime, when the linker finally calls the information it needs from the preprocessor.
In the static version, the linking step simply happens at the compile time, because the assembler gets all the information it needs from the statically linked file at compile time.
This is why the dynamic version only works when you tell the preprocessor that it is working with the dynamic linker. Is this correct?
thank you very much this movie was very helpful for me
The question is could i make an application extensible through that mechanism? As i can load arbitrary dlls and runtime.
Yes, that's how VST plugins work in audio software, you have a folder full of .dll files.
It kinda funny that he asked the question before explaning what __declspec(dllimport) actually does lol.😂
hello, I have a question, why are most people not using namespace std? Is this just preference or are there other benefits to it.
It’s bad practice
@@CSDex Yes, I understand that, but what is the reason for it? Why is it bad practice?
@@cipsasmiaumiau3773 He has definitely made a video on it
@@cipsasmiaumiau3773he has a video on it I'm pretty sure. In short cuz many large codebases have large number of namespaces with the same function name and that can really mess up the code. Like we have std::vector but game engines can have a vector function with a different purpose altogether and that may cause issues and confusion
that moment when 5:16
you shouldn't tell people they can't make it.
tell us what could go wrong and what we can do to not make it go wrong
We do not need to use __declspec(dllimport) to link to the GLFW functions in a DLL file because the necessary import/export attributes are already included in the GLFW header files and source code.
@arunabhbhattacharya5314 that's not quite correct. the GLFW header file does not contain all the necessary information to link to the DLL file alone. Although it does define GLFWAPI as __declspec(dllimport), this will only happen if GLFW_DLL has already been defined, else __declspec(dllimport) will not be selected from the #ifdef block!
All the function pointers in the header are prefixed with GLFWAPI, which the preprocessor has to interpret based on the #ifdef block conditions
If GLFW_DLL is NOT defined, then GLFWAPI is NOT interpreted as __declspec(dllimport)! Or, for example, if GLFW_BUILD_DLL is defined instead, then GLFWAPI becomes __declspec(dllexport) instead!
We do not need to put __declspec(dllimport) in front of every function pointer in the header file, because GLFWAPI becomes __declspec(dllimport) when GLFW_DLL is defined!
The real question however, is why do we not need to define GLFW_DLL to let the preprocessor know how to interpret GLFWAPI?? In other words, where is #define GLFW_DLL written so that we did not need to define it ourselves?
And the answer is, as other people have said, GLFW_DLL is defined in glfw3.dll.lib, the static library which pairs with glfw3.dll, the dynamic library!
This is why we do not have to #define GLFW_DLL in the project properties, because it is already in glfw3.dll.lib and therefore when the preprocessor reads the header and gets to the #ifdef for GLFWAPI, then it chooses to interpret any GLFWAPI prefix in the rest of the file as __declspec(dllimport) without us manually defining GLFW_DLL.
Hope this helps to understand what is happening here!
@@sephirapple7317love it. Had to scroll so much to get to the correct answer. Cherno didn't frame the question clearly tbh. I got the correct gist but others in the comment section really confused me, cuz most were answering a really different question, misunderstanding it as static linking when it's dynamic. Reading your reply really helped thanks
wht a grt explaination, now I know how's the static and dynamic dll works, now I can die peacefully. :)
Hello Cheom
Can it possible to package a winform in DLL and export the dll function for third party use? I do it done but error when I use the DLL.
It's always happen below:
1.Winform show only when I import dll at the first time.
2.In third party journal, it always show can't find the function name in dll.
About a winform in DLL am I right?
Thank you very much.
Hey....
Suppose dll returns STL container such as vector.
Main gets that vector and assigns to a new vector.
Both dll and exe compiled using same runtime library ( Multi Threaded Dll or MT) ,my exe crashes.
But then when I compile using debug versions it works fine .......
Any idea how to fix this ?
Basically I want to know how to return STL containers from dll to exe.
all i want to know is if he ever plays the guitars in the background of these videos
Answer to the last question raised in the video: Because we statically load that *dll.lib library which does all things that is necessary for dynamic loading for us.
I've watched the video "Macros in C++" and I spotted that GLFW_DLL has already been defined in the Preprocessor Definition. Is this the reason?
Great tutorials! What if I want to put my dll in some subdirectory of my executable, or if I have several search paths with the same dlls and it does not know where to look. Can I tell the executable to link to a specific dll and not other found? Thank you very much
You can only provide dll name in implicit dll linking, the dll location should be in search path (%PATH% environment variable) beforehand. You can change %PATH% environment variable user/system wide or make a script that sets this path and then executes your program, because you can't change %PATH% before linking stage by an exe itself.
Because you told the linker to explicitly link to the dll.lib library. So I guess the compiler disregards the preprocessor definitions. Just a wild guess.
Is there any way how to make Visual Studio copy dlls to output directory automaticaly?
DEXIT yes
What's the music?
Hi cherno. Need some help. I have one c++ dll file . I want to use this DLL into c# to create windows form application but when I try to load through add reference I get error. I tried another way by using system.runtime. interopservices in that DLL_import in built function is there but in my DLL I have function which takes one argument as structure member when I call that function it says undefined member ( it is not able to find that structure). So can please provide some solution with example where u have c++ DLL which contains one function and has structure argument
Thxs but i can’t understand you without subtitles thxs alot amazing vlog
Please make a video on how to use c# library in a C++ library or C++ application.
Thanks
Nice tutorial! I seem to get it, but in the end, something does not work for me.
I have a library (namely Armadillo) with library files blas.lib and blas.dll. I supply a path to the library files "-L path/to/libs" and specify I want to use this library file, i.e.: "-lblas". There are two things I have a problem with:
1. When both files are present in the specified directory, how does compiler know which file (.dll or .lib) must be linked? In other words, how does the compiler distinguish that user wants to perform static or dynamic linking?
2. When I supply only .lib file, I expect that static linking has been done, so there should be no need for putting .dll library in the solution folder, however, it is not the case and the executable won't run properly.
I will be glad for any feedback, thanks!
Good video!
Review Needed 2:03
challenge answer: With that, it is now static linking
please, make a tutorial about Setting up the glfw in mac and linux, thanks, your videos are Great!
Artho Pacini For Linux just get glfw and glew from your package manager. Then check which libs you need via pkgconfig and simply list them for gcc. Then you're done.
@@TeeDawl do you have a tutorial link or something?
Thank a lot
8:00 captions on
May be that macros are included in that glf header file.😁
You did define GLFW_DLL but you didn't add any reference to it so it really doesn't matter, the pointers from static dll library file are still the ones doing the job and thus nothing changes.
The dll.lib file did that declspec
Because the _WIN32 and GFLW_DLL are now both defined, the elif defined(_WIN32) && defined(GLFW_DLL) evaluates to true. Consequently, GLFWAPI evaluates to __declspec(dllimport).
Michalis Kaseris this is the correct answer!
I have commented out the GLFWAPI's declaration but keep the"#define GLFWAPI",it still prints 1.
Please put the answer Cherno really need it :)
I'd just add a small comment. The second time you compiled your DLL, you didn't copy the new version over to where the .exe file lives. That means the second time you ran it, your exe used the older version of your dll. Moving the DLL should be made part of the build automatically with a custom build step.
Someone new to DLL's can get frustrated when they make a change to the DLL code, hit 'Build All', and their change doesn't seem to work. Manually copying the DLL outside of VS means VS doesn't know how to update that copy. (go ahead, ask me how I learned this... lol )
You are still linking to the glfwdll.lib library of stubs...
The static library glfw3dll.lib takes care of importing the dll data for you, if you didn't link that static library you would need to define GLFW_DLL, and would be able to use just the dynamic library glfw3.dll
Dario Mylonopoulos, actually if you didn't use the static library you would need to do a lot more. You would need to call LoadLibrary to load the dll and then call GetProcAddress to get pointers to functions from the dll. This is essentially what GLEW does. It loads functions from the driver's dll
How do you do linking without a fancy IDE? I prefer command line and simple text editors. Most other languages have configs files for this kind of thing, what about C++?
You should really get used to using an IDE man, you might be okay on small projects but once you get to working on anything of decent size you won't be able to do it. That being said for MSVC look at the cl.exe command line flags: msdn.microsoft.com/en-us/library/f35ctcxw.aspx
I find that using IDEs leads people to not actually understand how the code all fits together. I do use intelliJ at work sometimes but I really prefer sublime text and the good ol' command line. Plus I use linux generally which has limited support for Microsoft products and IDEs.
I've been attempting to use your lessons to build a game that I can compile to web assembly and run in the browser. Keep up the good work man, loving it!
@Kishore G. I've been using Emacs for school, and visual studio for anything I do as personal projects. I feel like emacs is such a pain to use (probably just inexperience), but it is much better than vim IMO. However, some of the most basic features seem to be missing (like going to the definition of a function). How do you enable that at work? Or do you end up just using grep all of the time? I had some luck using gtags and hitting m-., but half of the time it takes me to the wrong definition.
I know it's a bit of a late reply but...
Generally the way to go about it if you don't want to use an IDE is to use make/cmake to automate the compilation. FWIW if you are using Visual Studio you can enable a more verbose build output which shows you the exact CLI commands used to build the solution. (Tools -> Options... -> Projects and Solutions -> Build and Run: set "MSBuild project build verbosity:" to "Detailed" or "Diagnostic", or if you prefer the log file - set the "MSBuild project build log file verbosity:" to "Detailed" or "Diagnostic").
If you are using GCC/G++ or clang then the command line arguments format are a bit different from MSVC's, but overall require the same stuff (specifying include directories, specifying library directories, specifying libraries).
At that point you are better off making a makefile for any project that is a bit larger, which will allow you to automate the build process (you'd only have to type "make" in the command line to build the project).
Basically an IDE makes the process of making a makefile easier (in fact visual studio uses a slightly different form equivalent to makefiles in its project files, but overall it achieves the same goal).
8:45 idk men D: i came here to learn :v
Does anyone knows how to do this using g++.
The AI i am consulting to atm does not tell anything about macro definition in the source code.
I have three source files:
1. vec2d.cp
2. triangle.cpp
3. zone.cpp
triangle.cpp depends on vec2d.cpp and zone.cpp depends on triangle.cpp and vec2d.cpp.
My strategy:
1. compile all .cpp files into .o file
command:
Example:
g++ -c vec2d.cpp -o vec2d.o
g++ -c triangle.cpp -o triangle.o
g++ -c zone.cpp -o zone.o
2. link the object files when there is usage into a single .dll file.
g++ vec2d.o triangle.o zone.o -o zone.dll
Cannot remember whether this is the command. Objectively, we want zone.dll
3. Write a consumer code
that depends on zone.dll by including its respective .h files.
for example,
#include "zone.h"
4. compile the consumer code into .o file
g++ -c consumer.cpp -o consumer.o
5. Link consumer.o to zone.dll
g++ consumer.o -L. -l:zone -o program
*/Unfortunately i got linker error exception at this point because it cannot find zone.dll in the linker's search path.
On which operating system do you use g++? If on linux there's no such thing as dll, it's windows thing. Linux has shared objects files with .so extension.
hey cherno bro -
I think I watched too many Chris Hansen videos because I keep hearing "pedophiles" instead of "header files"
Because we have included "glfw3.h".
damn 6 years now and no one answered the question 🤣🤣
no one answered the question, after 3 years :(.
What's the secret anyway?
I even do not understand the question....
Do I need a PC to do these lessons ?
Thanks.
@Tintin Hello.
Are you the real "Tintin" ?
What is a mobile ? Thanks.
Good video but would have preferred not to have to do homework. I didnt even do it in high school :)
Probably can tell by my bad written English LOL
where is the pinned comment?
We touch item$
Time...
So.. Be course
We r not
Alone. Alien...
I wish I spoke australian.
John Doe î
English is 2nd language for me and i have no problem understanding
He was kidding... At least I hope he was.
Why? Are you going to make some tutorials in English using Australian accent?
The only Australian I know is "Fosters" is Australian for "beer".
Plz make a video on C++ SQL Connector.
static linking uses ..lib + headers and more optimized way | dynamic linking uses ...dll.lib + ... .dll files but not optimized.
Where's the pinned comment!?
coool