Re: Symbols in library.

"Torbak" <atandin@free.fr> wrote...
> I got some question about symbols in libraries ...
>
> In libraries, there is public symbols and "not public" symbols
> (private, static)... In C when we use the "static" keyword on the
> declaration of a function, the function is not public in the library.


Actually, the term used in C++ is "external linkage" versus "internal
linkage". "Public" has a different meaning in C++.


> 1- When I use a class, all is symbols are put in the public section of
> the library.


Are they? The C++ language specification says nothing about that.


> How can I change that.


You need to ask in a newsgroup that deals with your particular
compiler because creation of libraries is not defined by C++ as a
language.


> The keyword "private" in a class is only for the langage or does it
> change (like "static") something in libs ? Even in object file ?


That is not defined by the language specification.


> 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 ?


That is not defined either, however, some compilers will not decorate
functions that are specified 'extern "C"' or decorate them differently
if they are specified as 'extern "Pascal"' or something. Again, this
is not defined by the C++ language itself.


> What COFF is use for then ?


There is no "COFF" in C++. Perhaps you need to ask your question in
a newsgroup where "COFF" is on topic.


> 3- The keyword "static" is used to keep the use of something in the
> file scope.


Actually, for symbols declared 'static' in a namespace scope, it makes
them have internal linkage (those names are not visible from other
translation units).


> If my lib is composed from many object file, how can I
> "hide" private functions ?


C++ doesn't specify that, but the solution I've seen is to only expose
some base class with all public interface virtual and pure, and then
implement the functionality in derived classes. Access to the actual
functionality should be given through a pointer to the base class,
returned from some library function (factory function), and behind the
pointer to base should actually be an object of the derived class.


> Does somebody know how I can get a good documentation about library
> files ?


You should ask your compiler developer/manufacturer/vendor.


Victor

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