Jump to content

  • Log In with Google      Sign In   
  • Create Account


#Actualmhagain

Posted 20 November 2012 - 10:19 AM

OK, this is a big topic, so I'm going to outline a few things in fairly general terms.

There are 2 main ways you can use a library - you can link to it statically or link to it dynamically.

When you link to it statically, only the code in the library that you use is pulled into your program. It doesn't matter if the library is 400mb in size and contains 5 billion different routines for doing different things; if you only need a few kb in one routine, that's all that your program gets.

When you link to it dynamically, no code from the library gets pulled into your program. The code runs directly from the library.

Dynamic linking also enables something else to happen. If multiple programs need the same piece of functionality, they can share it. So, as an example, if you have two programs on your machine that need to do printing, by using a dynamic library for printing, both of them get to share the same printing functionality.

That offers a mixture of advantages and disadvantages. The major advantage is that printing functionality is now consistent between both programs. End-users will thank you for that. Also, if printing functionality needs to be upgraded, you just need to upgrade the shared library and programs using it will automatically get the upgraded functionality. However, it also opens the possibility of a breaking change affecting all programs, and of versioning conflicts.

There's no absolute right or wrong answer to that one; it's a balancing act. Moving on.

Libraries may generally be seen to have already been tested. To have been debugged. You may assume that the code in them is fairly solid (provided you use it correctly). By contrast, if you write a whole chunk of (say) printing code yourself, you're going to be spending a lot of time testing and fixing bugs that have already been fixed in a library. Is that a productive use of your time? Only you can answer that.

"Bloat", as you seem to define it in your OP, is a myth. If code is being used for a purpose it is - by definition - not "bloat". A DLL or a JAR is not "bloat"; if it's never used, if it's never loaded, it won't be loaded into memory and it won't consume any resources, aside from disk storage. And disk storage is cheap and plentiful; programmer time, on the other hand, isn't.

There are many reasons why people engage in wheel reinvention, some practical, some psychological. Maybe they believe in myths? Maybe they have a bad infestation of the "not invented here"s? Maybe they can't find a suitable library for what they want to do? Maybe their needs are so specialized that no such library really exists?

#1mhagain

Posted 20 November 2012 - 10:19 AM

OK, this is a big topic, so I'm going to outline a few things in fairly general terms.

There are 2 main ways to can use a library - you can link to it statically or link to it dynamically.

When you link to it statically, only the code in the library that you use is pulled into your program. It doesn't matter if the library is 400mb in size and contains 5 billion different routines for doing different things; if you only need a few kb in one routine, that's all that your program gets.

When you link to it dynamically, no code from the library gets pulled into your program. The code runs directly from the library.

Dynamic linking also enables something else to happen. If multiple programs need the same piece of functionality, they can share it. So, as an example, if you have two programs on your machine that need to do printing, by using a dynamic library for printing, both of them get to share the same printing functionality.

That offers a mixture of advantages and disadvantages. The major advantage is that printing functionality is now consistent between both programs. End-users will thank you for that. Also, if printing functionality needs to be upgraded, you just need to upgrade the shared library and programs using it will automatically get the upgraded functionality. However, it also opens the possibility of a breaking change affecting all programs, and of versioning conflicts.

There's no absolute right or wrong answer to that one; it's a balancing act. Moving on.

Libraries may generally be seen to have already been tested. To have been debugged. You may assume that the code in them is fairly solid (provided you use it correctly). By contrast, if you write a whole chunk of (say) printing code yourself, you're going to be spending a lot of time testing and fixing bugs that have already been fixed in a library. Is that a productive use of your time? Only you can answer that.

"Bloat", as you seem to define it in your OP, is a myth. If code is being used for a purpose it is - by definition - not "bloat". A DLL or a JAR is not "bloat"; if it's never used, if it's never loaded, it won't be loaded into memory and it won't consume any resources, aside from disk storage. And disk storage is cheap and plentiful; programmer time, on the other hand, isn't.

There are many reasons why people engage in wheel reinvention, some practical, some psychological. Maybe they believe in myths? Maybe they have a bad infestation of the "not invented here"s? Maybe they can't find a suitable library for what they want to do? Maybe their needs are so specialized that no such library really exists?

PARTNERS