CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 2 of 3 FirstFirst 123 LastLast
Results 16 to 30 of 37
  1. #16
    Join Date
    Aug 2002
    Location
    Madrid
    Posts
    4,588
    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.

  2. #17
    Join Date
    Sep 2002
    Location
    DC Metro Area, USA
    Posts
    1,509
    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--

  3. #18
    Join Date
    Aug 2000
    Posts
    1,471
    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.

  4. #19
    Join Date
    Aug 2000
    Posts
    1,471
    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.

  5. #20
    Join Date
    Sep 2002
    Location
    DC Metro Area, USA
    Posts
    1,509
    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--

  6. #21
    Join Date
    Aug 2000
    Posts
    1,471
    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.

  7. #22
    Join Date
    Sep 2002
    Location
    DC Metro Area, USA
    Posts
    1,509
    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--

  8. #23
    Join Date
    Aug 2000
    Posts
    1,471
    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.)

  9. #24
    Join Date
    Sep 2002
    Location
    Maryland - Fear The Turtle!
    Posts
    7,537
    Maybe this has been said already....but static vs dynamic???

    Find a bug, patch it (ohh you where gonna download that?), call me later...

  10. #25
    Join Date
    Aug 2001
    Location
    Texas
    Posts
    645
    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.

  11. #26
    Join Date
    Aug 2000
    Posts
    1,471
    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.

  12. #27
    Join Date
    Sep 2002
    Location
    Maryland - Fear The Turtle!
    Posts
    7,537
    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.

  13. #28
    Join Date
    Sep 2002
    Location
    DC Metro Area, USA
    Posts
    1,509
    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--

  14. #29
    Join Date
    Aug 2000
    Posts
    1,471
    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?

  15. #30
    Join Date
    Sep 2002
    Location
    DC Metro Area, USA
    Posts
    1,509
    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--

Page 2 of 3 FirstFirst 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  





Click Here to Expand Forum to Full Width

Featured