-
August 27th, 2003, 01:44 PM
#16
Originally posted by dullboy
...I going to be benefited a lot in my professional career if I look more senior.
Grow a beard and get bald, that does wonders to make you look older
Get this small utility to do basic syntax highlighting in vBulletin forums (like Codeguru) easily.
Supports C++ and VB out of the box, but can be configured for other languages.
-
August 27th, 2003, 01:45 PM
#17
Sorry, I was out at a meeting for a while... (*^*&^*& work interfering with fun again!!)
I think that we've established that:
1 Headers are for the compiler, you need them to use the function, and to avoid compile errors.
2. Libraries are for the linker and are the functions that the header referred to.
3. Libraries have two flavors: normal and DLL.
4. When you link to a normal library it's static linking; when you link to a DLL it's dynamic.
5. DLL's don't need to be linked; they can be loaded at runtime.
Why would you use a normal lib or a DLL? I'd try to answer, but perhaps it's best to start another thread as I think that would almost start a "holy war".
Last edited by bytz; August 27th, 2003 at 01:51 PM.
bytz
--This signature left intentionally blank--
-
August 27th, 2003, 02:04 PM
#18
Originally posted by Yves M
Grow a beard and get bald, that does wonders to make you look older
Thanks... but I will pass because my girl friend doesn't like that.
-
August 27th, 2003, 02:11 PM
#19
Originally posted by bytz
Sorry, I was out at a meeting for a while... (*^*&^*& work interfering with fun again!!)
I think that we've established that:
1 Headers are for the compiler, you need them to use the function, and to avoid compile errors.
2. Libraries are for the linker and are the functions that the header referred to.
3. Libraries have two flavors: normal and DLL.
4. When you link to a normal library it's static linking; when you link to a DLL it's dynamic.
5. DLL's don't need to be linked; they can be loaded at runtime.
Why would you use a normal lib or a DLL? I'd try to answer, but perhaps it's best to start another thread as I think that would almost start a "holy war".
Are you sure you want to start another thread? Okey, I will start a new thread soon per your request. But I will keep the five points you have made above as a first post in the new thread because I don't want to go back to the old-stone age.
-
August 27th, 2003, 10:05 PM
#20
Well, I had intended to separate the thread into Why use a dll instead of static (normal) linking as there are good technical reasons for both, and alot of fluff, as the old saying goes if you have 4 programmers, you have 0x0101 opinions.
I don't object to continue discussing what libraries are for in this thread, but the aforementioned issue is a way more specialized case.
It may help you to search/read intro stuff about compiling and linking, maybe figure out what an assembler is & why it's different from a compiler -- this knowledge may not really be of use in solving day to day programming problems, but sometimes it helps to know what's going on under the covers. I was mulling over this during my hour long commute, and realized that VS tends to isolate/insulate programmers from the nity-grity process of building code... Why when I was a young, snotty nosed Comp Sci student < > we had to roll our own make files, and what a pain that was! But at least you understood what was going on through out the entire buld process.
Enough digression, remember that a compiler uses .h and .cpp (or .c) files to produce object code (.obj)? Essentially these .obj files are the machine language equivelent of the code written in the .cpp files (also remember that the compiler only looks at one file at a time). The linker acts just like it's name implies, it links one or more object files together into a .exe, lib or other sort of file. This linking process is concerned, among many other things, with finding out what function calls are being made from one module (the .obj produced by one .cpp file/module) to another. So, the linker essentially builds a big dictionary of what's where and then starts checking if every function call can be resolved somewhere in that list... if not it emits an "Unresolved External" error, which means that it can't find a function or variable in any of the modules in the project. The compiler, OTOH, emits Syntax errors (mostly, there are other types) which generally mean "you typed the statement wrong, Bozo". Why say this - 'cuz if you get a compile error, you generally fix it by correcting the mistake in your code and link errors are generally fixed by making sure that your project includes everything that it needs to. WARNING the previous was a very simplistic explination of a complex set of error conditions... It's late, so I'll try to wind it up...
As you start to write a great deal of code, you'll notice that there is a great deal of common funtionality, i.e. you often need to copy a string from one place to another, find out the string length, get the absolute value of a number, etc, etc... So you could re-write these functions for every application that needed it or you could write it once and reuse it when ever needed. Enter the "Library", these file are collections of commonly used routines that can be used by simply including a header file (for the compiler) and adding the .lib to the project (for the linker). All this was to say that a library file is nothing more than a collection of linked .obj files... linked in the sense that the library has no unresovled externals etc...
Enough for now. Good luck and keep thinking & questioning.
bytz
--This signature left intentionally blank--
-
August 28th, 2003, 05:41 PM
#21
Originally posted by bytz
Well, I had intended to separate the thread into Why use a dll instead of static (normal) linking as there are good technical reasons for both, and alot of fluff, as the old saying goes if you have 4 programmers, you have 0x0101 opinions.
I don't object to continue discussing what libraries are for in this thread, but the aforementioned issue is a way more specialized case.
It may help you to search/read intro stuff about compiling and linking, maybe figure out what an assembler is & why it's different from a compiler -- this knowledge may not really be of use in solving day to day programming problems, but sometimes it helps to know what's going on under the covers. I was mulling over this during my hour long commute, and realized that VS tends to isolate/insulate programmers from the nity-grity process of building code... Why when I was a young, snotty nosed Comp Sci student < > we had to roll our own make files, and what a pain that was! But at least you understood what was going on through out the entire buld process.
Enough digression, remember that a compiler uses .h and .cpp (or .c) files to produce object code (.obj)? Essentially these .obj files are the machine language equivelent of the code written in the .cpp files (also remember that the compiler only looks at one file at a time). The linker acts just like it's name implies, it links one or more object files together into a .exe, lib or other sort of file. This linking process is concerned, among many other things, with finding out what function calls are being made from one module (the .obj produced by one .cpp file/module) to another. So, the linker essentially builds a big dictionary of what's where and then starts checking if every function call can be resolved somewhere in that list... if not it emits an "Unresolved External" error, which means that it can't find a function or variable in any of the modules in the project. The compiler, OTOH, emits Syntax errors (mostly, there are other types) which generally mean "you typed the statement wrong, Bozo". Why say this - 'cuz if you get a compile error, you generally fix it by correcting the mistake in your code and link errors are generally fixed by making sure that your project includes everything that it needs to. WARNING the previous was a very simplistic explination of a complex set of error conditions... It's late, so I'll try to wind it up...
As you start to write a great deal of code, you'll notice that there is a great deal of common funtionality, i.e. you often need to copy a string from one place to another, find out the string length, get the absolute value of a number, etc, etc... So you could re-write these functions for every application that needed it or you could write it once and reuse it when ever needed. Enter the "Library", these file are collections of commonly used routines that can be used by simply including a header file (for the compiler) and adding the .lib to the project (for the linker). All this was to say that a library file is nothing more than a collection of linked .obj files... linked in the sense that the library has no unresovled externals etc...
Enough for now. Good luck and keep thinking & questioning.
Thanks for your explaination. However, my question is NOT about which one is better, dynamically linking or statically linking. My question is what in the world is the difference in USING dynamically linked library and statically linked library.
For me, it seems the same thing.
For example, by dynamically linking, you have to include header files( to make the compiler happy), link the .lib files(to make the linker happy). However, if you take a look at statically linking, you would do the SAME thing as dynamically linking, wouldn't you?Correct me if I am wrong.
-
August 29th, 2003, 07:13 AM
#22
You're basically right, there are a few differences in how the linker handles references between Static and Dynamic linking, and there are a few differences at runtime. When you link to a static library, the linker opens the lib and copies it's contents to the exe, when you link dynamically, the linker inserts a reference to the DLL (name, location of the fucntion, etc). This leads to situations; One, the static linking can cause a (much) larger exe size but is able to run without any additional files. The second is that the DLL version exe is smaller, although total code size is about the same (exe + dll), but the dll must be present in order for the application to startup. It's this difference that leads to the question "Why/when would I use either one". This has been alluded to, and semi-explained earlier in the thread...
bytz
--This signature left intentionally blank--
-
August 29th, 2003, 12:19 PM
#23
Originally posted by bytz
You're basically right, there are a few differences in how the linker handles references between Static and Dynamic linking, and there are a few differences at runtime. When you link to a static library, the linker opens the lib and copies it's contents to the exe, when you link dynamically, the linker inserts a reference to the DLL (name, location of the fucntion, etc). This leads to situations; One, the static linking can cause a (much) larger exe size but is able to run without any additional files. The second is that the DLL version exe is smaller, although total code size is about the same (exe + dll), but the dll must be present in order for the application to startup. It's this difference that leads to the question "Why/when would I use either one". This has been alluded to, and semi-explained earlier in the thread...
I still have a question. How does the linker know a developer/programmer's choice in either dynamically linking or statically linking? Or in the other words, what special things a developer/programmer has to do to choose between dynamically linking and statically linking?( I remember you used to point out it but I got the impression that basically a developer/programmer does the same thing for both. Now I am looking for the difference.)
-
August 29th, 2003, 01:16 PM
#24
Maybe this has been said already....but static vs dynamic???
Find a bug, patch it (ohh you where gonna download that?), call me later...
-
August 29th, 2003, 01:18 PM
#25
When you use a standard LIB file during you link, the code is
added to your EXE file.
When you link with a DLL LIB file, the only thing added to your
EXE file is a reference to the DLL. The code is not added to your
EXE. However, you will need to include the DLL file when you
distribute you program to others. If you don't include the DLL, your program won't run - you will get an error like "Can't find
xxx.dll."
When you use a DLL, then your EXE is smaller. But you have
additional files to distribute.
-
August 29th, 2003, 01:55 PM
#26
Originally posted by cvogt61457
When you use a standard LIB file during you link, the code is
added to your EXE file.
When you link with a DLL LIB file, the only thing added to your
EXE file is a reference to the DLL. The code is not added to your
EXE. However, you will need to include the DLL file when you
distribute you program to others. If you don't include the DLL, your program won't run - you will get an error like "Can't find
xxx.dll."
When you use a DLL, then your EXE is smaller. But you have
additional files to distribute.
You are absolutely right, but you didn't answer my question. Let me express my question this way.
Use dynamically linking and statically linking alternately in your application. I am NOT concerned with what is going on under the hook, but I am just concerned with how you, as a developer, do that DIFFERENTLY. I assume you do not always stick to DLL. Sometimes, you want to switch to statical link for some reasons.
-
August 29th, 2003, 02:29 PM
#27
Originally posted by dullboy
You are absolutely right, but you didn't answer my question. Let me express my question this way.
Use dynamically linking and statically linking alternately in your application. I am NOT concerned with what is going on under the hook, but I am just concerned with how you, as a developer, do that DIFFERENTLY. I assume you do not always stick to DLL. Sometimes, you want to switch to statical link for some reasons.
Yes and I think as paul stated it, there are two questions here...I'll deal with yours...you don't static link if you ever have worked on any code that deals with millions of lines...and have to provide quick updates...thus...dlls....
PS: static linking is for people who haven't thought ahead or maybe they have??? I can see for miles and miles...
Last edited by Mick; August 29th, 2003 at 02:32 PM.
-
August 29th, 2003, 05:00 PM
#28
Originally posted by dullboy
Use dynamically linking and statically linking alternately in your application. I am NOT concerned with what is going on under the hook, but I am just concerned with how you, as a developer, do that DIFFERENTLY. I assume you do not always stick to DLL. Sometimes, you want to switch to statical link for some reasons.
This is a really complex answer so follow along closely
If you specify a normal lib, it gets linked statically. If you specify a dll, it gets linked dynamically. Generally you, the programmer, only creates one or the other or the vendor only sells one kind (not always the case, and generally it's a dll vs ActiveX), so this desicion is made for you. The only time it comes into play is when you create a project and you make the decision for MFC, or when you create a library of code that you want to include in other projects....
bytz
--This signature left intentionally blank--
-
August 29th, 2003, 06:06 PM
#29
Originally posted by bytz
This is a really complex answer so follow along closely
If you specify a normal lib, it gets linked statically. If you specify a dll, it gets linked dynamically. Generally you, the programmer, only creates one or the other or the vendor only sells one kind (not always the case, and generally it's a dll vs ActiveX), so this desicion is made for you. The only time it comes into play is when you create a project and you make the decision for MFC, or when you create a library of code that you want to include in other projects....
If you are using MFC library, there is somewhere in Visual studio for you to specify whether linking dynamically or linking statically. It is very clear, period. However, for the library I , as a programmer, create, it seems there is no place to specify whether linking dynamically or linking statically. That is exactly my question---how could I, as a programmer, use the library I create through statically linking in my application?
-
August 29th, 2003, 06:20 PM
#30
Originally posted by dullboy
how could I, as a programmer, use the library I create through statically linking in my application?
Re-read the following sentence:
If you specify a normal lib, it gets linked statically. If you specify a dll, it gets linked dynamically.
Further explaination:
It depends on the type of library you create!!!!! If you create a normal lib; from then you will link it statically, no choice, no decision, it just the way it works. If on the other hand you created a DLL, when you used it in a application it would linked using dynamic linking, once again no choice, no decision. Once a library has been created there is no choice how to link it -- well, almost none; you can choose not to link a dll, but to load it programmatically at runtime.
The only choice you could have with one of you libraries is too create both a static version and a dynamic version. Then you could choose one or the other and the linking would occur as determined by the lib type .
bytz
--This signature left intentionally blank--
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|