Re: Symbols in library.

On 20 Aug 2003 01:20:22 -0400, atandin@free.fr (Torbak) wrote:


> Thanks for thoses answers.
>
> About :
> "2- Even symbols which are not "static" have there decorated name in
> the library. (I use bindump to check that). How can I avoid that for
> the private functions of my lib ?", in fact I make a mistake. I
> should say "Even symbols wich ARE 'static' have there ..."
>
> [later] I use microsoft C compiler.


I thought the MS tool was dumpbin, not bindump. I don't know about MS
object format in particular, but many object formats can record both
symbols which are "visible" to and can be linked from other modules,
usually called "global" or "external", and also symbols which are are
still generated but cannot be linked and do not conflict with other
such symbols having the same namem, "local" or "internal". In
traditional Unix 'nm', the letter for symbol type is uppercase for
global (T=text, D=data, B=bss) and lowercase for local (t,d,b).


> I fact my question should be shortly discribe like this : Libraries
> are files wich contain compiled code. Then to be linked, they contain
> symboles description to discribe to the linker where it can find
> functions which are accesible in the library. When I programme my
> lib, I distingue 2 types of functions : those which will be "public",
> means appear in header file, could be called from other compomnent of
> the prog ... And those wich should not be called by others.
>
Noting that this use of 'public' and 'private' is different from,
though somewhat similar to, the same-named access modifiers for
members of a class (or struct) in C++. (And also Java.)


> ex :
> /* private stuff */
> static char textTab[] = {"Hello", "By" };


That doesn't agree in type. You wanted char * text [].
And the opposite of Hello should be Bye or Good-bye.


> static void DisplayText( int i ) {
> sprintf("I say :%s/n", textTab[i&1] );


The first argument to sprintf must be a buffer (char array) of
sufficient size into which the formatted result is written. You
apparently want printf. And /n is not a newline, \n is.


> }
>
> /* public stuff */
> void Talk( void ) {// my public function
> int i = rand();
> DisplayText(i); // call private function
> }
> in mylib.h
> extern "C" void Talk( void );
>
> When I compile my stupid lib (I don't checked if what I wrote is
> good), in release mode with no debug information etc ... I'll find
> all symbols in the lib using dumpbin ... "textTab", "DisplayText" and
> of course "Talk".
>
> I expected to find only my public "Talk" function and not the other
> symbols like "DisplayText(int)".
>
See above; you need to find the doc or a newsgroup for your particular
compiler/implementation/platform to check that the DisplayText you see
is harmlessly local, and if there is a way to not generate it at all.


> Because for me, the "DisplayText" function should be linked directly
> in the library, and no any information about it should appear in the
> release object. I wounder find the same thing than if the
> "DisplayText" function was not exist like : void Talk( void ) {// my
> is alone. No call to "private" functions.
> sprintf("I say :%s/n", textTab[rand()&1] );
> }
> Of course, this exemple is simple because my private function is
> called one time, and could be inlined.


A function definition earlier in the same (preprocessed) source file
certainly can be inlined, if the compiler implements it; the compiler
may require an option to do inlining (check you doc) and must have
limits where if a called function is too big or contains certain kinds
of complexity it won't be inlined, although I would expect your very
simple example not to exceed any reasonable limits.


> So in general I wounder something like this :
> 0x000xxx afunctionDescriptor // adress of my private func.
> 0XOOOyyy Talk(void)
> ...
> call afunctionDescriptor // call or jmp ...
> ret
>
>
>
> So if I use long description function name and many little functions,
> my lib will be larger than if I use short function name with big
> functions ?
>
If you use lots of little functions, they will almost certainly
generate more code, as well as (much) more object-file structuring
information, and more debugging symbols if you generate those, which
is rarely the default, than the same functionality in fewer functions.


If you use longer names for functions, it won't change the actual
code; it will probably make the object-file structuring information
slightly larger, and debugging symbols if any slightly larger.


Object-file structuring information won't (in any case I know of)
affect the size of the actual runtime code, and on many systems
debugging symbols (if they exist at all) are not actually loaded at
runtime unless you actually use the debugger.


> PS : I tried namespaces but it doen't change anything.


That's surprising; symbols in namespaces (other than the global
namespace) need to be fixed somehow so that e.g. foo::x and bar::x do
not conflict; usually if not always this is done by "mangling" the
name. Possibly the tool you are using automatically demangles the
names before displaying them; check for an option to suppress that.


- David.Thompson1 at worldnet.att.net

Return to the comp.compilers page.
Search the comp.compilers archives again.