Libs, DLL, APIs, etc?

[hellohellomoon]

So, I was trying to create a console game, and an experienced programmer referred to me a link that talked about how it's better to get into game programming right away. I really want to do this, but I have many questions.

I was trying to research more about that yesterday but the subject seems very confusing.

It's like, you have to "download third party libraries" and supposedly there are many third party libraries?
How would we even know which one is reliable or not? How do we know if they are professionally made or not?
Also, the most important question is, after we "download" the lib file, how do we even integrate it in our IDE's? I hear we have to link it or something.

If only there was a tutorial for this. I can't find anywhere online that talks about "How To" download and install libs, APIs, and etc. I don't even know what an API is. I searched online and it said it was an "Application Programming Interface". I don't even know what that exactly is but I do know it's supposed to help you applications. I don't know how to install it nor do I know any files of it or if its even a file at all, or a lib. And what is a DLL?

DLL, Libs, APIs, and anything similar to that is like outer space for a beginner like me. How can I learn more about these things? I really want to add sounds, graphics, etc to my programs, but where do I start?

QUESTIONS IN A LIST (Please explain in a simple, noob-friendly way if you can):

1. What is an API? How do I use APIs?

2. What's the difference between APIs, DLLs, LIBs,and CLIBs?

2. What is a DLL?

3. What is a third party Lib? Is each different for different purposes? Why not get all?

4. Are there anything else than APIs, DLLs, and Libs that's critical to C++?

5. So, how fast could a beginner like me who studied C++ for one month be able to get all of this?

6. If you can explain anymore about these subjects in a beginner-friendly way, I would be grateful.

[Disch]

Oh man I just replied to this PM not knowing there was a thread here.

Oh well here's my reply again:


> where do I start?

Start with a lib. Definitely. Learning how to use libs is important and is something you'll have to learn eventually. So you might as well get it out of the way now.

Here's a crash course:

A "library" is basically a bunch of code that someone else wrote that you can use.

The simplest libraries are "header only" which mean you just download the header files, #include them, and you can use all the stuff they provide. Some libraries in boost are like this.

More complicated libraries need to be compiled separately and then linked to your program. This process is more involved.

To help explain it... think of a library as a collection of header files and .lib files. header files define a bunch of functions that you can use, and the .lib files contain the bodies for those functions (much like .cpp files). The difference between .lib files and .cpp files is that .lib files are binary code that has already been compiled, whereas .cpp files are text that still need to be compiled.

You need to "link" to the libraries so that your program is able to find the function bodies.


There are two ways to link: statically and dynamically.

To link "statically" means you effectively build the library into your program as if it were part of your program. This results in a bigger exe (because it now includes all that code that was in the library).

To link "dynamically" means that the library code exists in a separate dll file. This results in a smaller exe since you don't have to have any lib code built into your program... but now your program then needs to have the dll in order to run.

Personally I prefer static linking whenever possible. Missing DLL errors are annoying and there are other complications involved with dynamic linking that I would rather not bother with.

>It's like, you have to "download third party libraries" and supposedly there
> are many third party libraries?

Tons. Anybody who writes code is able to put a library up on the web.

> How would we even know which one is reliable or not? How do we know if they
> are professionally made or not?

By reputation. If they're open source (which most of the good free ones are) you can just look at the source and decide for yourself if it's what you want. I wouldn't really worry about using a "malicious" library. They are extremely rare (I've never seen one) and I'm sure they'd be easy to spot.

>Also, the most important question is, after we "download" the lib file, how do
> we even integrate it in our IDE's?

This depends on the IDE. Assuming you're using Visual Studio, the process goes something like this:

1) Download the library source code
2) Open the project files in your IDE
3) Compile/Build the library
4) Add the library's source directory to your IDEs path list so that when you #include <libheader.h> it knows what directory to look in for that header file
5) Do the same thing as #4, but for the lib / library files
6) Make a new project that wants to use that library
7) #include the header you want
8) Go to your project settings, in the linker settings, under "additional libs", put "whateverlib.lib"
9) Build your project


>If only there was a tutorial for this. I can't find anywhere online that talks
> about "How To" download and install libs,

Very often, there are tutorials on the lib site. I know SFML (the game lib I recommend) does have tutorials on how to get it set up for some common IDEs.

http://www.sfml-dev.org/

One thing I definitely recommend, though, is always compile the source, even if there are premade DLL files available. It's often harder to get the premade DLLs working than it is to just compile from scratch. Plus if you want static linking (like I do) the DLLs are useless anyway.

> I don't even know what an API is.

An API is a fancy term for a group of functions/classes/types/etc that let you do something.

for example, iostream could be considered an API because it offers cout, cin, and a bunch of functions to make them work.

There's a subtle difference between "API" and "library". It's not worth splitting hairs about... at least not yet. But very basically, the API is just the 'user interface' of the library (ie: how you interact with it), whereas the library is the entire library. (The API is just part of the library)


So yeah, I recommend picking up SFML. SFML 2.0 is better, but is still in development so it might be harder for a newbie to set up. So if you want to take it easy for a first attempt, get SFML 1.6. There are tutorials on the site, and if you have problems/questions about getting it set up, I'm happy to help.

[shacktar]

0. What is a library?

A library is code that is meant for integration into another program. Say you're making a game and you're tired of having your rendering, physics, and main game logic code all in one place. You could extract your rendering and physics code into libraries. You would then be compiling code in three separate places (rendering library, physics library, and your game logic which would be compiled into the actual exe). If you hardly change the rendering or physics code then you can concentrate on your game logic. You could then use your rendering and physics libraries in other games.

The library will typically consist of two parts: (1) header files that you will need to include to use the library and (2) the compiled portion of the library which you will need to link with. The compiled portion contains object code that the linker will use to find the symbols alluded to in the .h files. A header-only library would contain only part (1) above.

3. What is a third party [library]? Is each different for different purposes? Why not get all?

A "third-party" library is one written by someone else. If you download and use SFML for example, then you are using a third-party library. A matrix library that you code up and use yourself is not a third-party library.

No, each library is not for different purposes. There are many libraries out there and a bunch do the same thing but in different ways. You need to gauge which one is best for your particular purpose. You can do this by asking others, seeing the content others created with those libraries, and by actually inspecting the libraries websites/documentation.

1. What is an API? How do I use APIs?

An API is the functionality exposed to other code.

For instance, this is a Stack class:

//Stack.h

template <class T>
class Stack
{
    public:
        void Push(const T& );
        T Pop();
        T Peek();

    private:
        T* data;

        //other private members
};

//implementation goes here 

The API of this Stack class would be the public methods (Push, Pop, and Peek). If someone else coded this and you're using it in your code then it could be considered that you're using a header-only library. If the class works, then all you need to be concerned about is using its API.

From the context of a libary, the API is all the code that you can use directly. All the public data in the .h files which you need to use the library will be its API. If you're using a matrix math library, then you will just be concerned about using the main API calls such as Rotate, Scale, Translate, ... All the nitty gritty details (all the code not in the API) will be hidden from your code.

2. What's the difference between APIs, DLLs, LIBs,and CLIBs?

2. What is a DLL?

There are two types of libraries: static libraries and shared libraries. When linked into another program, a static library is completely consumed into that executalble. Thus, all its symbols are readily available to the program. A shared library contains its symbols in a separate place with respect to the executable. This allows one shared library to be used across multiple executables.

Using a static library leads to an exe with more code in it (i.e. the application + the static lib). Using a shared library leads to an exe with less code in it (i.e. the application + info for using the shared lib) but there's now the headache of hoping that the symbols you use at runtime are the ones you intended to use. Static libraries are more convenient. Shared libraries can lead to saved space. Sometimes you might even have to use a shared library because that's all that's available and apparently the LGPL (a software license) requires shared linking. Each have their advantages and disadvantages that should be weighed before choosing one option (if applicable). Some people are under the assertion that using shared libraries is "more correct" or "more professional" because everyone and their little brothers use them. This is wrong.

Static libraries are implemented as .a files on Unix-like systems and .lib files on Windows systems. Shared libraries are implemented as .so files on Unix-like systems and .dll files on Windows systems. If you're using a shared library (.dll/.so), you will notice that it will come with a "static libary" (.lib/.a). This is not a full static library but rather a stripped down version needed by your linker to use the shared library.

I don't know what a CLIB is.

4. Are there anything else than APIs, DLLs, and Libs that's critical to C++?

The core language, for one. If you're using other people's code, then understanding APIs, DLLs (shared libraries), and Libs (static libraries) is absolutely critical.

5. So, how fast could a beginner like me who studied C++ for one month be able to get all of this?

Potentially very quickly. Try compiling a small class into a library and try using it from another program. First try creating a static library and then a shared library.

EDIT: ninja'd

[hellohellomoon]

Wow, thank you Disch and thank you shacktar for both of your long, well written answers.

I'm going to read your answers again and again until I full get the concept of it. If only we can favorite threads on this website so I don't lose this information.


Yeah, crash courses are great! Your crash courses, Disch, really helped me and yours too Shacktar.

Thanks again guys :D This really helped