How library classes are instantiated

Question

I'm going to ask how it's done in c++, but this idea can apply to multiple languages. If you know how to do it in objective-c as well, please provide any similarities between the two

Lets say I want to create an instance of an ofstream like

ofstream myfile;

I'm assuming all I have on my computer is the *.o file (in a library archive) and the *.h file for iostream class. If this part isn't true let me know. I am assuming this when all I have installed is the runtime and the devel packages, not the source files.

How does it connect the header file to the object file, is there a naming scheme. And where does it look and in what order.?

Why this is confusing me is normally when I want to create a class I link my implementation of the class with the program, so where does it now and how does it now to link the files?

One more, does it matter if it loaded statically or dynamically?

Thank you in advance, and sry if this is a silly question.

http://stackoverflow.com/questions/6528071/how-does-linkage-and-name-mangling-work — Ben Voigt, Jan 20 '12 at 20:37
http://stackoverflow.com/questions/2937273/questions-about-name-mangling-in-c — Ben Voigt, Jan 20 '12 at 20:37
http://en.wikipedia.org/wiki/Name_binding http://caml.inria.fr/pub/docs/oreilly-book/html/book-ora065.html — , Jan 20 '12 at 20:38
http://stackoverflow.com/search?q=%5Bc%2B%2B%5D+name+mangling — Ben Voigt, Jan 20 '12 at 20:39
maybe it's how I worded it, I meant how does it know where to look — rubixibuc, Jan 20 '12 at 20:41

score 2 · Answer 1 · answered Jan 20 '12 at 20:41

This is not standardized and it's up to the implementation. I don't know about *unix, but I assume it's fairly similar to Windows.

You can assume that .o files are similar to library files .lib.

The header does define the class definition, so that the linker knows what to look for in the library.

Say you have a header:

class A
{
public:
    A();
    void foo();
};

and a lib file A.lib.

You include that header and call:

A a;
a.foo();

The compiler finds the declarations for bot A() and A::foo(). Now it knows it has to search the library for these functions. Names in the library are decorated, and contain modifiers, but its specific to the compiler so the linker finds the functions if they are exported in the library. It then binds the functions to the specific entry point from the dll.

If by dynamic loading you mean using LoadModule() and GetProcAddress() instead of linking, than the concept is pretty similar.

For *nix: *.o files are similar to DOS/Windows *.obj; *.a files are similar to *.lib, and *.so files are similar to *.dll's. — paulsm4, Jan 20 '12 at 21:22

score 2 · Accepted Answer · answered Jan 20 '12 at 20:43

2

Computer Science 101:

Broadly speaking (VERY broadly!), there are two kinds of "programs":

a) Interpreted: you read the program source line-by-line every time you execute it <= *nix shell scripts and DOS .bat files are "interpeted"

b) Compiled: you read the source once (to convert it into a "binary machine code"). You link the machine code "object files" to build an "executable program".
You're talking about "compiled programs"
The "ofstream" part is irrelevant once the program is "compiled"

The binary implementation for "ofstream" can be compiled directly into the executable, or it can be dynamically loaded from a shared library (.dll) at runtime.
A "compiler" users ".h" headers to process the source file.

A "linker" uses ".lib" libraries to match symbols and link static code at link type.

The "Operating System" recognizes dynamic links and loads the needed shared libraries (.dll's) at runtime.

Three different things, all independent of each other: Compiler/source code, Linker/machine object code, OS/executable programs

'Hope that helps .. a bit...

answered Jan 20 '12 at 20:43

paulsm4

114,292
17
138
190

1

PS: If your question is really about "how does the OS figure out what shared libraries a running program needs, and where does it find them?" - look here: http://en.wikipedia.org/wiki/Library_%28computing%29 – paulsm4 Jan 20 '12 at 20:49
That link was very helpful, I just have one more side question, when an object from a share library is statically linked, does the entire library code get included or just what is needed to make the code run? Is it the same for dynamically linked? – rubixibuc Jan 20 '12 at 21:04
"static linking" means "include it in the .exe". "dynamic linking" means *don't* put it in the .exe - grab it at runtime. The advantages of dynamic linking include 1) smaller .exe's, 2) the ability to update/change modules *without* needing a new .exe. So yes: when you statically link, it gets included. When you dynamically link, it *isn't* included. The .exe just makes a "reference", and it isn't actually included until runtime. And even then, it's "included" only if it's actually needed. – paulsm4 Jan 20 '12 at 21:21
What if I only reference one function out of ten from a library, how much of that library is included when using static linking or dynamic linking? – rubixibuc Jan 20 '12 at 23:41

score 0 · Answer 3 · answered Jan 20 '12 at 20:41

0

If you do static linking all symbols with linkage are available in the .obj file. The linker binds the calls of the functions to the entry points of the functions. There is a name mangeling involved in this process so that the symbols can be resolved correctly.

Dynamic linking is a platform dependent issue and not part of the C or C++ standard as far as I know.

answered Jan 20 '12 at 20:41

frast

2,700
1
25
34

Sorry I do not know how it works in objective-c but I would bet it is very similar. – frast Jan 20 '12 at 20:47
All static AND dynamic external symbols are specified in the object file by the compiler. All external symbols are specified (in both executable programs and share libraries!) by the linker. These symbols are needed by the OS (to load the proper .dll's) and by external debuggers. – paulsm4 Jan 20 '12 at 20:53

How library classes are instantiated

3 Answers3