Linux installations generally install function reference information on your system in the form of man pages. Help on man.

You can also go online and find browsable man pages. For example, if you want information on open(), you can generally throw "man open" into google and get some results. Some results won't be so good. If you throw "man man" into google you get a lot of information about a punk rock band.

A lot of newcomers are confused by "Linux".

Linux is a kernel. As such, it has no "C++ functions" available from userland. There are syscalls, documented in syscalls(2). syscalls(2) means there is a "syscalls" entry in section 2 of the manual, which you can reach by typing man 2 syscalls on the command line1. Searching the manual entries can be done with apropos or man -k, as in apropos syscalls or man -k syscalls. Another documentation systems — used mostly by GNU projects — is info.

The userland of GNU/Linux systems, BSD systems, as well as most other *NIX-like systems, is made of various API. Most *NIX-like systems (including GNU/Linux and *BSD) comply to a certain level with the POSIX set of standards. Most also have BSD and System V functions, if not total implementations.

On top of that, one will find various libraries and technologies, such as X11 (wrapped in Xlib), SSL/TLS, etc, and even higher-level libraries (GTK+, Qt, ...) Some of these libraries will make use of well established protocols (Bonobo, using CORBA), and some won't (KParts).

In essence, you can't find a reference of "Linux C++ functions" because there is no such thing. *NIX-like systems are made of a kernel and a very tight userland. The rest is really up to the software vendor/distributor. You'll find Qt references, POSIX references, Bonobo references, but no "Linux C++ functions "reference. *NIX is made of small building blocks2. [smile]

Hope this helps.

1. or, in many cases, just man syscalls, because there is no "syscalls" entry in other sections of the manual;


2. so is Windows, in a sense, but it's tightly controlled by Microsoft. You'll find various subsets to the so-called "Win32 API" that include cryptography, distributed components (DCOM, and now .NET), etc.

Quote: Original post by Revelation60
So there is no other way of finding the right functions?

Is this really the way you all learned the linux-specific c++ functions?

The Linux Documentation Project has a lot of documentation about various sides of GNU/Linux, be it using it, administrating it, programming it, etc.

I suspect a lot of us received at least a minimal amount of formal training in development, including development for *NIX-like systems.

EDIT: spelling.

Quote: Original post by Revelation60
I also found out that linux hasn't got a registry

Linux doesn't have any universal configuration storage system. Many programs store their configuration in /etc/program (for global settings) and ~/.program (for user-local settings) in simple text files. There are some other conventions such as ~/.config/program and ~/.gnome2/program and so-on as well. GNOME has GConf for storing simple configuration, but it's recommended that complex data be stored outside of GConf.

Quote: Original post by Revelation60
I can't find a syscall to load in an ini. :( Am I correct?

There's no standard "Linux" way to load INI formatted files or a reason for there to be one really. There is a GPL-licensed library known as libini that should do what you want (though I can't claim to have ever used it). It wouldn't be too hard to throw together a simple INI parser either, really.

Quote: Original post by Revelation60
Thank you both :)

By the looks of it there are far less syscalls than Win32 API calls!

That's because syscalls are for talking to the kernel. Windows has syscalls too, but you've probably never heard about them before. [smile]

Quote: I also found out that linux hasn't got a registry, but I can't find a syscall to load in an ini. :( Am I correct?

You're getting this backwards. You don't want to use syscalls unless you need to talk to the kernel (which you don't, most likely). I simply said that Linux is a kernel and offers only one way for userland programs (what you're writing) to talk to it (the aforementioned syscalls). That's why you can't find documentation about "Linux C++ functions", because there is no such thing.

As Null and Void said, there is no standard configuration storage system for GNU/Linux systems. Qt abstracts settings away with its QSettings class, using the registry on Windows, PList files on Mac, and INI-like files on *NIX (under ~/.config/software_author/program_name). Depending on your needs, this may or may not be the solution to your problem.

For clarity's sake, let me repeat that you don't want to use syscalls. The kernel doesn't deal with such high-level concepts as configuration storage. It deals with memory management, task scheduling, permissions, CPU/space quotas, filesystem monitoring, packet routing and filtering, etc.

Quote: Original post by Revelation60
If I understand you all correctly, the Linux variants haven't got something like a uniform API. So basically I have to use additional libraries, which I don't really like, or write all those functions that Windows has in its API from scratch.

All of those "Windows API" functions are part of some library or other too. You don't remember installing some program or other in Windows and having it you request that you install DirectX, framework blah, or msvcrt60.dll? Much like Windows, there is a set of libraries that you can generally assume will be present a targetted subset of Linux systems beyond the kernel syscalls. The obvious being the C and C++ runtimes (generally glibc and libstdc++; those are libraries too, even in Windows), Xlib on virtually all desktops, et cetera.

Quote: Original post by Revelation60
Porting my game gets very complicated if I have to create functions for even the most little things like setting the mouse to a certain position, myself. :|

That's what Xlib is for. Sure, it's a library, but so is the Windows API for the same function. (Though, I'd recommend using SDL if you don't need to go any lower level. Yes, another library, but a common dependency of games in *nix).