tags:

views:

138

answers:

5

Is there a C library available for operations such as file operations, getting system information and the like which is generic, which can be used when compiled in different platforms and which behaves in a similar way?

Edit: Something like Java or .NET platform abstracting the hardware.

+9  A: 

Have you tried the standard library? It should be implemented on any system that has an ISO compliant C runtime.

Nathon
+1  A: 

For anything not found in the standard library, GLib is a good first place to look along with other libraries built to interact with it. It offers for example threads, mutexes and IPC that you won't be able to write portably using plain standard libraries, and you can use many more GNU libraries that follow the same conventions up to a full GUI in GTK+. GLib supports the usual popular operating systems.

jjrv
+4  A: 

Yes; the ISO Standard C library. It may not cover all the functionality you want, but that is exactly because it is generic, and as such is also lowest common denominator. It only supports features that can reasonably be expected to exist on most hardware, including embedded systems.

The way to approach this is perhaps to specify the range of target platforms you need to support, and then the application domains (e.g. GUI, networking, multi-threading, image processing, file handling etc.), and then select the individual cross-platform libraries that suit your needs. There is probably no one library to fulfil all your needs, and in some cases no common library at all.

That said, you will always be better served in this respect by embracing C++ where you can use any C library as well as C++ libraries. Not only is the C++ standard library larger, but libraries such as Boost, wxWidgets, ACE cover a broader domain spectrum too. Another approach is to use a cross-platform language such as Java, which solves the problem by abstracting the hardware to a virtual machine. Similarly .NET/Mono and C# may provide a solution for suitably limited set of target platforms.

Added following comment: Hardware abstraction in a real-machine targeted language (as opposed to a VM language such as Java or CLR based languages) is provided by the operating system, so what you perhaps need is a common operating system API. POSIX is probably the closest you will get to that, being supported on Linux, Unix, OSX (which is Unix), QNX, VxWorks, BeOS and many others; but not importantly Windows. One way of using POSIX on Windows is to use Cygwin. Another is to use a VM to host a POSIX OS such as Linux.

Clifford
Exactly! I was looking for some cross platform library which does the same job as Java and C# by abstracting the hardware.. Let me edit my question as well.
bdhar
A: 

If the C standard library is not sufficient for your needs, a minimal hyperportable subset of POSIX might be the target you want to code to. For example, the main non-POSIX operating system Windows still has a number of functions with the same names as POSIX functions which behave reasonably closely - open, read, write, etc.

Documenting what exactly a "hyperportable subset of POSIX" includes, and which non-POSIX operating systems would conform to such a subset, is a moderately difficult task, which would be quite useful in and of itself for the sake of avoiding the plague of "MyCompanyName portable runtime" products which appear again and again every few years and unnecessarily bloat popular software like Firefox and Apache.

R..
A: 

If you need facilities beyond what the Standard C library provides, take a look at the Apache Portable Runtime (APR). You should also review whether POSIX provides the functionality you are after, though that comes with its own bag of worms.

If you want to get into graphics and the like, then you are into a different world - GTK, Glib and Qt spring to mind, though I've not used any of them.

Jonathan Leffler
-1 for recommending APR. It belongs in `/dev/null`. Programs I've seen using APR (svn comes to mind) spend hundreds of lines of code (packed with possible failure conditions like possible allocation failures) performing the equivalent of a single `printf` call. If you want that kind of useless overhead you should be using C++ and STL.
R..
@R..: You may be right about APR but using that to have a cheap and ill-informed shot at C++ and STL is unnecessary.
Clifford
At least C++ makes the exception handling and failure cleanup a lot easier, but I don't think you can argue that using C++ and STL does not introduce a lot of unnecessary allocation operations that may fail to trivial operations which could be performed entirely on the stack with no allocations and no chance of failure.
R..