Jump to content

Leaderboard

Popular Content

Showing content with the highest reputation on 01/01/2015 in all areas

  1. Actually the C compilers I have worked with work a little bit different. Normally each .c (or .cpp, .cxx or whatever) source file results in an .obj file. These object files CAN be combined (really linked) into a .lib library file. When you use a single function from an object file, the entire object unit is linked into the resulting executable image, even if it contains about 500 other unused functions. These unused functions can reference other functions from other object units and cause them to be included as well even-though they are never actively called in the resulting executable. Only when you link with a library file, will the compiler pick out the embedded object units that contain at least a function that is used by any other included object file or the actual executable. It's likely that with careful linker scripts and all that you can nowadays hand optimize this step with some modern compilers but it's not what is normally done, since linker scripts are a rather badly documented feature. With all this said a lvlib (and lvclass) much more resembles a C object file than anything else, in terms of what gets linked into the final executable file. As such the term library is somewhat misleading especially when you compare it to the C .lib library file which is more of a real collection of units.
    1 point
  2. Can we get rid of LVLIB “libraries†then? Or at least rename them as they don’t match the English meaning of library? Libraries are not "collections of books that cannot be read except all at onceâ€. And can we have an actual library construct that does collect related VIs with namespacing and scoping? Why don’t we have proper libraries in LabVIEW?!?
    1 point
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.