Early Binding and Late Binding
Friday June 30, 2006
You see the phrases, "early binding" and "late binding" quite frequently in Microsoft documentation and web pages (like this one) but they often simply assume that you understand why these concepts are important. This article fills in the gaps!
(Note ... this article was written for, and tested with VB.NET 2005 Express Edition but the concepts apply to any version.)
Comments
Well, it is entirely possible that I’ve lost track after half a century of programming … or things may have changed … but my memory of the definition is a bit different.
“Early” binding was when the assignment of memory locations to variables was done by the compiler or, perhaps, by the linking loader that cleaned up some problems with forward references that the compilers of the era were unable to resolve.
“Late” binding was when the memory location associated with a variable was not determined until the execution time of the program. It was, therefore, frequently less efficient, and many compilers (and programmers) did strange things to attempt to avoid it.
Perhaps the ultimate in “late” binding was the consequence of the ALGOL 60 “call by name” concept, which had it that at the time of execution of a block of code with parameters, the code was to behave as though the formal parameters (the ones appearing in the definition of the block of code) were physically replaced by the actual parameters (the ones appearing in the call on the block of code). Hence, even the type of a formal parameter might not be known until the time of execution.
The mechanism for dealing with this was called a “Thunk” (see Ingerman, PZ, “Thunks.” Communications of the ACM 4 (Jan. 1961), or search Google for “Ingerman Thunk” [without the quotes]), and Microsoft is reported to continue to use the concept.
But yes, it is indeed inefficient compared with “early” binding, and I agree with Dan that early binding is almost always preferable when it can be achieved.
PZI
Thanks again to Peter for his valuable insight. I “thunk” that my claim that the concepts in the article apply to all versions was perhaps just a tad optomistic. Peter knows about more versions of more languages than I do.
As “Webopedia” states in their article about thunking, “The meaning of the term has changed considerably in recent years.” Microsoft, in particular, uses “thunking” to describe the way they were able to let 16 bit operating systems call 32 bit addresses and vice versa. It was a bit of a kludge and I believe that’s all behind us now.
And so meanings have changed a bit with early and late binding too. In the world of VB 6 OLE programming, “late binding” was often used to allow the exact DLL (object library) used by the code to be specified at runtime. Since different versions of Office applications (Word, Excel, etc.) might be in use in a real world situation, this made it possible to distribute Visual Basic programs that wouldn’t crash when used with these different versions of Office. (Not necessarily a good idea, but possible.)
If OLE is left out of the picture, “late binding” now only refers to the use of .NET’s universal data type “Object” so that no data type is specified in a way that is almost identical with VB 6 variant data types from the point of view of the programmer. And that’s the definition of “late binding” used in my article.