Junichi Uekawa <dancer@netfort.gr.jp> [2002-09-22 20:54:19 +0900]: > What would be the point of restricting the shared libraries to > within the software ? The traditional argument is usually that shared libraries save disk space. If your have a large amount of code that is completely shared between N programs then you have N copies of that code on disk. By using a shared library private to your application you can reduce your disk space consumption needs to only one copy of that shared library code shared between the various executables of your project. But making a public shared library creates a public API which you are now responsible for maintaining _forever_. Anyone else that you do not know about might be depending upon your shared library in their program. This restricts the things you can do. If you are developing and wishing to change even a minor thing such as a parameter type to a function then you will need to make a major revision to your shared library API otherwise you will break those other programs which are using your shared library. Public shared libraries are therefore a public contract that you always have to think about when doing changes to the library. Entering into those contracts should not be made lightly. Keeping them private avoids the contract and you now can develop and change your library as you see fit and as long as your program is internally consistent you are good to go and still save the N copies of disk space. Or so the theory goes. But is your program so large that disk space for your executables is really a concern? Has anyone filed any bugs against your project that you are using an unreasonable amount of disk space? If no bugs have been filed because of that then I would reject the use of shared libs to save disk space. Bob
Attachment:
pgpG5MEbE4h3J.pgp
Description: PGP signature