On Tuesday 25 March 2003 06:46 pm, Jerry Feldman wrote:
On Tue, 25 Mar 2003 10:45:05 -0500
"Steven T. Hatton" <hattons@globalsymmetry.com> wrote:
How would one typically (correctly) include such a library in his code? If I follow K&R 2nd. Ed., they put the #includes for libraries in any .c file that relies on them. Is that technically necessarily? From my experimentation, id doesn't /seem/ to be necessary. All that is required to get the code to run is that the one of the header files referenced in the .c includes the particular library.
I think you are mixing C and C++. K&R 2nd Ed. is ANSI 89 C, not c++.
I thought Bjarne Stroustrup did that. ;-)
Generally, header files include function prototypes, structure definitions, class definitions, et. al. If you have a c or c++ module, you only need to include those header files needed by that module.
I guess that is part of what I'm not clear on. From my perspective, the only code in a program outside of main() should, if at all possible, be contained in classes. If I accept that class definitions are properly placed in the header files, then I would only have main.cpp and a bunch of header files.
Libraries are different. Those are referenced at link time by the -l (lower case L) option.
I believe that merely tells the linker where to find the precompiled bits for the programming units referenced in your header files and your extern statements. I have to confess, I don't understand the whole process, especially regarding the extern specifier. If you do nm /opt/kde3-cvs/lib/libmcop.so You'll see a bunch of stuff like this: 000f405d t .L101 000f4070 t .L103 000f4083 t .L107 000f4096 t .L109 000f40a0 t .L113 000f40a7 t .L114 000f40ad t .L116 000f40b2 t .L117 000f40b8 t .L119 000f4117 t .L127 ... U time@@GLIBC_2.0 000f9fe0 t trim 000f97b0 t tryall_dlopen U uname@@GLIBC_2.0 U unlink@@GLIBC_2.0 000f9f70 t unload_deplibs 00115d40 d user_error_strings 00115d54 d user_search_path U vsprintf@@GLIBC_2.0 U write@@GLIBC_2.0 My understanding is this is a list of symbols mapping to address offsets within the compiled libraries. You may notice some of these are named with somewhat human sounding names. I /believe/ that is what maps the symbols you use in your code to the compiled form of the library code. If this is correct, the source code that was compiled to produce the library should have these names in it. There's often a corresponding .la file which seems to tell linkers to take the next fork in the road: # libmcop.la - a libtool library file # Generated by ltmain.sh - GNU libtool 1.4e (1.1090 2002/02/07 19:54:36) # # Please DO NOT delete this file! # It is necessary for linking the library. # The name that we can dlopen(3). dlname='libmcop.so.1' # Names of this library. library_names='libmcop.so.1.0.0 libmcop.so.1 libmcop.so' # The name of the static archive. old_library='' # Libraries that this one depends upon. dependency_libs=' -L/usr/X11R6/lib -L/usr/local/qt/lib -L/opt/kde3-cvs/lib / usr/lib/libgmodule-2.0.la /usr/lib/libgthread-2.0.la -lpthread /usr/lib/libg lib-2.0.la -ldl -L. -L/usr/lib/gcc-lib/i486-suse-linux/3.2 -L/usr/lib/gcc-li b/i486-suse-linux/3.2/../../../../i486-suse-linux/lib -L/usr/lib/gcc-lib/i48 6-suse-linux/3.2/../../.. /usr/lib/libstdc++.la -lm -lc -lgcc_s' # Version information for libmcop. current=1 age=0 revision=0 # Is this an already installed library? installed=yes # Files to dlopen/dlpreopen dlopen='' dlpreopen='' # Directory that this library needs to be installed in: libdir='/opt/kde3-cvs/lib'
It is not a requirement in C that you prototype a function before it is used. But, C++ does require that.
This is where things are sure to get confusing for me. Prototyping means something different in ECMAScript. Or at leas I believe it does. I wasn't able to find the actual term 'prototype' in E&S, but I do know it's used in other texts on C++. IIRC, what your statement means is that the symbol must be declared prior to its being referenced. I don't recall the rules for this, I will take your word for it. I simply assume that to be the case in any situation where I don't know what's going on. I learned that the hard way with JavaScript.
My rule of thumb is to include only what my module requires. But, others like to include everything that other modules in the project require.
I believe your approach is appropreate. Now all I need to do is figure out what _doesn't_ belong in a header file. ;-)
Gerald Feldman <gfeldman@attbi.com>
STH