Visual C++ Team Blog

Alan,

I am going to assume something. Are you new to C++? I'm sorry to sound offensive, but this article is a mish-mash of badly formulated ideas.

A program doesn't 'access' functions. It is part of the compiler/linker to generate this information.

I'm struggling to understand what it is you've talked about here. You've rolled compiler/linker issues in with PE/import tables, which are completely different things. I would love to see a series of articles which introduce and discuss (at length) these things. I seriously hope no new/intermediate developer comes across this link.

Also, I've never called the DLL load process 'Binding'. Sure, you guys in MS might. The rest of the world doesn't.

Please don't always be an ANTI-MS guy.  I think this post is simple and clear.

p.s. i'm not ms guy :).

cmroanirgo -

Alan is definitely not "new to C++" and while maybe he's no Shakespeare, and his post isn't very expansive, this is a good summary of the ways user code (by user I mean you guys ;)) gets at our library code when you call a function ("access" if you will).  It's a very library-centric view in that it looks at what we normally think about in our team (Visual C++ libraries) when looking at how our users access our functionality, but it's a simple, short and easy to understand explanation.  I guess the other topic this post could have covered would be virtual vs non-virtual vs inline within a single binary - v-tables and the like - but I think that's the sort of thing you probably learn in your 200 level classes in college.  

Anyway, just wanted to pipe in to confirm what others like Fried, Hooyoo and Steven Yong are saying and confirm that Alan's no n00b :).

Ben Anderson

Visual C++ Libraries Team

I also liked it.  I think this post provides a good high-level overview of the C++ library functions.

I'm sorry all. After re-reading my comments I find that they are particularly harsh.

I humbly apologize.

Hooyoo. I have been using VC since the early 90's. I'm not anti MS.

Dave. I agree....but I would love to see these articles re-written in multiple stages, simply to clarify what the compiler/linker is doing vs what is going on with DLL (and Delay-load) DLLs.

Alan, again humble apologies. I think a nerve was hit when you described a function as being "accessed". My (incredible) bad.

ikk:

There is a difference in the way Linux shared libraries work from Windows DLLs. If you look at a Windows build of GCC, like mingw, you will notice that it actually requires import libraries to link to a DLL.

Delphi, Visual Basic, C# and other programming languages like this don't require import libraries because their runtime libraries or your program deal with this. One of the first things you have to do is declare the function and where it is externally. You don't need to do this with the main Win32 api in Delphi since Borland gives you a module which handles this, but when accessing a function from a dll in Delphi without this you use something like

procedure DllProc; external 'mydll.dll'

this does the decleration and then the libraries do the rest.

In C/C++ import libraries are not needed but they help automate the process of calling the functions from a DLL. Since C/C++ doesn't have a runtime library system the way that other languages do then things like this makes it easier. Accessing DLLs in Windows is done through a combination of LoadLibrary and GetProcAddress, so instead of requiring a large amount of these calls, just linking with an import library can reduce things by a lot and make your code a lot easier to read.

Using the import library does one thing for C/C++ that you would possibly take for granted, and it enables you to call a function in the DLL just as the function name without doing anything else. Otherwise you will have to get into the fun of function pointers and more.

But to answer your question. You use them in C/C++ when you want to access DLLs. There are some cases where you can't, but those are advanced programming techniques so it is best not to think about that.