2

I'd like to ask a few specific questions regarding writing C++ on Unix as opposed to windows.

  1. In windows, to call native OS functions you usually link to a .dll or include windows.h Likewise, how do you refer to the underlying OS functions in Unix?

  2. Is there a reference guide for all the underlying OS functions within Unix? (so that one could see what functions are available).

  3. What is the best method to "include" the boost libraries? To use an IDE like the eclipse C/C++ version and include boost like one would on windows?

Thank you

AusCBloke
  • 18,014
  • 6
  • 40
  • 44
user997112
  • 29,025
  • 43
  • 182
  • 361
  • man pages are your friend in 'nix. – AusCBloke Nov 15 '11 at 04:15
  • The best way to "include" the Boost libraries starts with using your chosen *nix distribution's package manager ("yum" on Red Hat, "apt-get" on Ubuntu...) to install the Boost development package. – John Zwinck Nov 15 '11 at 04:16
  • You might find these SO questions useful: http://stackoverflow.com/questions/2672470/where-can-i-obtain-a-list-of-unix-system-calls, http://stackoverflow.com/questions/24109/c-ide-for-linux & http://stackoverflow.com/questions/1089490/eclipse-cdt-how-to-reference-3rd-party-includes-via-a-relative-path – another.anon.coward Nov 15 '11 at 04:56

3 Answers3

2

1) There is no single header file. You do not call system calls directly, instead they are generally invoked indirectly through the standard c library like fopen (in the case of fopen, you can also call the underlying function open, but that makes a program less portable). Mentioning which system calls specifically you refer to would help

2) It sounds like you are a new to development on the Unix platform. I highly recommend "Advanced Programming in the UNIX Environment" by Richard Stevens.

3) You should get familiar with the make utility. Something that is generally hidden on windows by your IDE. In addition the boost library comes with example programs.

steve
  • 5,870
  • 1
  • 21
  • 22
  • With regards to #1: I wasn't suggesting there was a single file to allow including, I was just asking how do you call the underlying OS functions? Do you simply call the function? – user997112 Nov 15 '11 at 04:38
  • Yes, you just call the functions. The man pages will tell you what header to include. – bames53 Nov 15 '11 at 04:45
1

  1. There is no single header that you can include to have access to all *nix functions; see the corresponding man page in sections 2, 3, or 3p for the relevant function in order to tell which headers and libraries you need.

  2. Each *nix tends to follow POSIX or SUS to varying degrees.

  3. ... What?

Ignacio Vazquez-Abrams
  • 776,304
  • 153
  • 1,341
  • 1,358
1

On Unix systems the Unix functions are typically in libc along with the C standard library. The compiler automatically links this to your executable, typically as a 'shared library', which is sort of like a Windows DLL, but also not exactly.

As for the headers to include... most Unix systems come with the command line man command which allows you to pull up manual pages about various calls. These manual pages generally mention the header you need in order to use a particular function.

There are special functions that are implemented as system calls. For the average C programmer, the fact that a particular function is a system call is an implementation detail. But it's often worth noting exactly which functions these are as they help you understand what the OS does for you, and what's being done by a library you're using. This distinction tends to be very difficult to ascertain on Windows.

Most Unix programmers still use make and command line utilities. That means there's no IDE settings or anything. You're going to have to figure out what flags to pass the compiler. This is generally not all that difficult.

Also, most Unix systems do not install software willy-nilly all over the filesystem. If it's an include file that's part of an installed package, it will be in the /usr/include directory. This means you will not have to magically divine the locations of the Boost include files. They will be in /usr/include along with everything else.

And while you might have to figure out exactly which Boost libraries you need (like -lboost_filesystem), all the Boost libraries will be in /usr/lib, or /usr/lib64 with all the other libraries, so you won't have to figure out where they are.

Omnifarious
  • 54,333
  • 19
  • 131
  • 194
  • Wouldn't those locations be if you untarred boost to that particular director? – user997112 Nov 15 '11 at 15:31
  • @user997112: Well, yes and no. In general, you shouldn't be installing boost by hand if you can help it. Almost all Linux distributions include some kind of package management, and almost all of those have a package for boost. And, IMHO, if you install boost by hand, you should run it's install instructions and point them at `/usr/local`, which means that the include files will go in `/usr/local/include` which is also on the standard search path. – Omnifarious Nov 15 '11 at 15:59
  • @user997112: On Unix systems, there is a standard location for everything. `/usr/local` is the place where stuff that isn't being managed by a package management system goes. – Omnifarious Nov 15 '11 at 16:00
  • Im glad you mentioned the package management method. I once tried installed Eclipse the manual way and it was a nightmare. The other day I used the package management system and it was 10 seconds! – user997112 Nov 15 '11 at 18:43
  • could you give a one-liner example of a man command which pulls up one of the OS functions for asynch communications? – user997112 Nov 15 '11 at 18:44
  • @user997112: `man 2 epoll`. Though, that will only work on a Linux system, because `epoll` is Linux specific. A better one might be: `man 2 socket`. The number is the manual section. If you don't specify it, `man` will hunt through all the manual sections. But, for example, on Linux there's a `man 7 socket` which gives you an overview man page talking about all kinds of socket related stuff. These are often referred to as _socket(7)_ or _socket(2)_. – Omnifarious Nov 15 '11 at 20:30
  • @user997112: Package management makes things simple. There are so many little configuration things to set up otherwise. Which Java are you using, for example, and how to make the classpath work correctly and a whole ton of other stuff. And that's just for a Java program. Other kinds of programs have different concerns. – Omnifarious Nov 15 '11 at 20:35