proxy70

                                    Library

   [1]Software library (often shortened to just lib) is program code that's
   not meant to run on its own but rather to be used by other programs, i.e.
   it is a helpful collection of preprogrammed code that's meant to be
   [2]reused. A library provides resources such as [3]functions, [4]macros,
   [5]classes or [6]constants that are normally related to solving some
   specific class of problems, so e.g. there are [7]GUI libraries, [8]audio
   libraries, [9]mathematical libraries etc. Libraries exist mostly to
   prevent [10]reinventing wheels by only ever implementing the code once so
   that next time we can simply reuse it (respecting the [11]DRY principle),
   but they also e.g. help assure others are using an already well tested
   code, they help to implement [12]modularity etc. Examples of libraries are
   the [13]standard C library, [14]SDL or [15]JQuery. Libraries are not to be
   confused with [16]frameworks which are larger, more [17]bloated
   environments.

   In [18]Unix environments there is a convention for library [19]packages to
   start with the lib prefix, so e.g. SDL library is named libsdl etc.

   Standard library (stdlib) is a term that stands for the set of libraries
   that officially come with given [20]programming language -- these
   libraries usually offer very basic functionality (such as [21]I/O and
   basic [22]math) and are required to always be present on every system.

   If a programmer wants to use a specific library, he usually has to first
   somehow [23]install it (if it's not installed already, usually a library
   is some kind of software [24]package) and then include it in his program
   with a specific command (words like include, using or import are commonly
   used). Then he is able to use the resources of the library. Depending on
   the type of the library he may also need to [25]link the library code
   after [26]compilation and possibly distribute the library files along with
   his program. A more [27]KISS approach is for a library to simply be a code
   that's somehow copy-paste included in the main program (see single header
   libraries etc.).

   As a programmer you will encounter the term library [28]API -- this is the
   interface of the library consisting of the elements via which programmer
   uses the library, mostly the [29]functions the library offers. API is what
   the programmer interacts with; the rest is library internals (its
   [30]implementation) that's usually supposed to not be touched and stay a
   bit hidden (see [31]encapsulation). If a programmer wants to know the
   library API, he wants to know the names of the functions, what
   [32]parameters they take etc. Sometimes there may be multiple libraries
   with the same API but different internal implementations, this is nice
   because these libraries can be easily [33]drop-in-replaced. The library
   API is usually part of its documentation -- when learning a new library X,
   you want to search the internet for something like X library API reference
   to see what functions it offers.

   In a specific [34]programming language it IS generally possible to use a
   library written in a different language, though it may be more difficult
   to achieve -- see language [35]bindings and [36]wrappers.

   We generally divide libraries to two types:

     * [37]static: The library code is embedded into the executable of the
       final program so that the library files have to be distributed along
       with the program. This is more convenient and also makes sure the
       program uses exactly the correct version of the library. But of course
       this results in bigger executable, and if we have multiple programs
       that use the same library which is statically linked, each program
       will have a [38]redundant copy of the library code, wasting memory
       (both storage and [39]RAM).
     * [40]dynamic (also shared): The compiled library code resides in a
       separate file ([41]DLL on [42]Windows, [43].so in [44]GNU/[45]Linux)
       which may need to be distributed along with the program, but this one
       file can be shared among all programs that use the library so the
       compiled programs can be smaller. It may also be easier to update the
       library to a new version by simply replacing the compiled library
       file. RAM may also be saved as the dynamic library may be loaded just
       once for multiple simultaneously running programs.

   Many times a library can have both static and dynamic version available,
   or the compiler may allow to automatically link the library as static or
   dynamic. Then it's up to the programmer which way he wants to go.

C Libraries

   TODO: example

   Header only or single header library is a kind of [46]keep-it-simple
   library that's wholly implemented in a single header (.h) file -- this is
   kind of a [47]hack going against "official recommendations" as header
   files aren't supposed to contain implementation code, just declarations,
   however single header libraries are [48]suckless/[49]LRS, convenient and
   very easy to use, as they don't have to be [50]linked and are nicely
   self-contained, distributed in one nice file. A traditional library would
   consist of one or more header (.h) files and one or more implementation
   (.c) files; such library has to be compiled on its own and then linked to
   the program that uses it -- the idea behind this was to compile the
   library only once and so save time on recompiling it again and again;
   however this justification is invalid if our library is simple enough and
   compiles very quickly (which it always should, otherwise we are dealing
   with badly designed [51]bloat). A single header library can therefore just
   be included and [52]just works, without any extra hassle -- yes, its code
   recompiles every time the program is compiled, but as stated, it doesn't
   hurt if our library is well designed and therefore simple. Single header
   libraries often include the option (via some #define macro) to include
   just the declaration or both declarations and implementation code -- this
   is useful if our main program is composed of multiple source files and
   needs to be linked. [53]LRS libraries, such as [54]small3dlib or
   [55]raycastlib, are of course single header libraries.

LRS Libraries

   TODO

Links:
1. software.md
2. reusability.md
3. function.md
4. macro.md
5. class.md
6. constant.md
7. gui.md
8. audio.md
9. math.md
10. reinventing_wheel.md
11. dry.md
12. modularity.md
13. clib.md
14. sdl.md
15. jquery.md
16. framework.md
17. bloat.md
18. unix.md
19. package.md
20. programming_language.md
21. io.md
22. math.md
23. install.md
24. package.md
25. linking.md
26. compiler.md
27. kiss.md
28. api.md
29. function.md
30. implementation.md
31. encapsulation.md
32. parameter.md
33. drop_in.md
34. programming_language.md
35. binding.md
36. wrapper.md
37. static.md
38. redundancy.md
39. ram.md
40. dynamic.md
41. dll.md
42. windows.md
43. so.md
44. gnu.md
45. linux.md
46. kiss.md
47. hacking.md
48. suckless.md
49. lrs.md
50. linking.md
51. bloat.md
52. just_werks.md
53. lrs.md
54. small3dlib.md
55. raycastlib.md