I'm looking for a "core" C cross-platform toolbox, because I need lots of "useful" functions (read/write ini files, network routines, arrays, lists...)
I was thinking about GLib, may be Qt (the core part) but I would appreciate a pure "C" stuff
I think glib is a fantastic choice, but it's perhaps somewhat less widely scoped than what you're after, there is no networking in glib as far as I know.
For that, you need to add GIO from the same family of libraries.
Apache Portable Runtime (APR) may be the solution you are looking for. It is used, among other projects, for the Apache http server and Subversion.
I think glib is great. It comes with a great deal of core algorithms and data types. There are many libraries build around GLib and GObject. You have indeed GIO for all kinds of different input and output on files, over network etc (will remind you a bit of the Java like IO operations), and you gtk for Gui applications. All These libraries were designed with portability in mind and extendibility to other languages (eg. python, perl etc). But learn to use GOjbect as well, because the best work comes from using these libraries ( http://www.gtk.org/documentation.php ) together.
Related
I have an existing library in C, which I want to be able to allow remote access to (either from Linux or Windows).
I looked at the usual RPC suspects like Thrift and Protobuf, but neither of these deal cleanly with C-style function calls (things like pass-by-ref, char* instead of string, * instead of List<> etc).
In short, to use either of these it looks like I would need to write a complete IDL from scratch, and add a lot of boilerplate code to transfer C-style function calls into these environments.
Are there any RPC libraries around that
can deal directly with C header files (or have tools to auto
generate the initial IDL from C definitions)?
are cross-platform Linux/Windows compatible?
require the absolute minimum of boilerplate code?
support sockets
are relatively high performance (XML-RPC i'm looking at you)?
Well, there's protobuf-c, an implementation of protobuf in C.
And then there's the classical XDR, found on most/(all?) unix-like systems, versions exist for windows as well. See also the Linux xdr(3) man page which contains an overview of the API.
Note that both protobuf and XDR are serialization libraries, they don't provide RPC. The "companion RPC library" to XDR is called, well, RPC, but I don't think anyone writes new code with that, and AFAICS it's unix-specific (portmap doesn't run on windows, does it? And it's generally a bad idea anyway.). Then there's protobuf-c-rpc which is the C version of the protobuf RPC library; probably a better bet than classic RPC.
What are some common general purpose library as Boost is to C++ but for C? It should be a cross-platform library and include collections such as trees, linked-lists, queues, etc...
What are the advantages/disadvantages to those libraries?
glib is pretty nice because:
liberally licensed (LGPL)
constant development
tons of data structures
trees
lists
queues
caches
etc.
good documentation
lots of sample code
development "assistance"
logging
thread abstraction
thread pools
test framework
timers
Unicode support
many supported platforms
regular expressions
tons more...
The Apache portable runtime project
http://apr.apache.org/
is good. Covers basic datastructures and is very good at network and IO abstraction.
The later is a magnitude better then glib.
Unfortunately most document links on the apache websites are broken at the moment :-(
But this one works work http://apr.apache.org/docs/apr/1.4/modules.html
Is there a standard way of reading a kind of configuration like INI files for Linux using C?
I am working on a Linux based handheld and writing code in C.
Otherwise, I shall like to know about any alternatives.
Final update:
I have explored and even used LibConfig. But the footprint is high and my usage is too simple. So, to reduce the footprint, I have rolled out my own implementation. The implementation is not too generic, in fact quite coupled as of now. The configuration file is parsed once at the time of starting the application and set to some global variables.
Try libconfig:
a simple library for processing structured configuration files, like this one: test.cfg. This file format is more compact and more readable than XML. And unlike XML, it is type-aware, so it is not necessary to do string parsing in application code.
Libconfig is very compact — a fraction of the size of the expat XML parser library. This makes it well-suited for memory-constrained systems like handheld devices.
The library includes bindings for both the C and C++ languages. It works on POSIX-compliant UNIX and UNIX-like systems (GNU/Linux, Mac OS X, Solaris, FreeBSD), Android, and Windows (2000, XP and later)...
No, there isn't one standard way. I'm sorry, but that is probably the most precise answer :)
You could look at this list of Linux configuration file libraries, though. That might be helpful.
Here are four options:
Iniparser
libini
sdl-cfg
RWini
If you can use the (excellent, in any C-based application) glib, it has a key-value file parser that is suitable for .ini-style files. Of course, you'd also get access to the various (very nice) data structures in glib, "for free".
There is an updated fork of iniparser at ccan, the original author has not been able to give it much attention over the years. Disclaimer - I maintain it.
Additionally, iniparser contains a dictionary that is very useful on its own.
If you need a fast and small code just for reading config files I suggest the inih
It loads the config file content just once, parse the content and calls a callback function for each key/value pair.
Really small. It can be used on embedded systems too.
I hate to suggest something entirely different in suggesting XML, but libexpat is pretty minimal, but does XML.
I came to this conclusion as I had the same question as you did, but then I realized the project already had libexpat linked-in--and I should probably just use that.
I don't ever recall coming across anything for C that's as extensive as C++'s Boost library.
You can have a look at glib. It provides quite a few interesting things like containers, unicode support, threading...
Have a look at its documentation
I've never seen anything. Really, C++ templates are the enabling technology for STL and much of boost, and C doesn't have them. I've seen many C-interface libraries for things like image processing, 3D graphics, networking, etc., but never a real general-purpose library like boost. You can find pieces though - threading libraries, string libraries, etc. - that are similar to sections of boost.
Depending on what exactly you're trying to do there is APR (The Apache Portable Runtime library) which is what the Apache http daemon is built on
http://apr.apache.org/
For GUI, there is wxWidgets (formerly wxWindows)
http://www.wxwidgets.org/
Glib does compensate it partially in form of various unicode, string types. If you add Gobject you could get some object programming even some garbage collection.
ACE (Adaptive Communication Environment) is sometimes mentioned. It's not quite an apples-to-apples comparison. Boost provides more "basic building blocks" whereas ACE provides more of an tightly integrated framework geared towards telco products. I have used both extensively and I find Boost vastly superior. One big advantage of Boost is that many of its features will show up in the STL extensions for the upcoming C++0x standard (see, for example, http://en.wikipedia.org/wiki/Technical_Report_1).
or you can look at ccan http://ccan.ozlabs.org/
but no, there really isn't any complete package, glib comes closest
What things should be kept most in mind when writing cross-platform applications in C? Targeted platforms: 32-bit Intel based PC, Mac, and Linux. I'm especially looking for the type of versatility that Jungle Disk has in their USB desktop edition ( http://www.jungledisk.com/desktop/download.aspx )
What are tips and "gotchas" for this type of development?
I maintained for a number of years an ANSI C networking library that was ported to close to 30 different OS's and compilers. The library didn't have any GUI components, which made it easier. We ended up abstracting out into dedicated source files any routine that was not consistent across platforms, and used #defines where appropriate in those source files. This kept the code that was adjusted per platform isolated away from the main business logic of the library. We also made extensive use of typedefs and our own dedicated types so that we could easily change them per platform if needed. This made the port to 64-bit platforms fairly easy.
If you are looking to have GUI components, I would suggest looking at GUI toolkits such as WxWindows or Qt (which are both C++ libraries).
Try to avoid platform-dependent #ifdefs, as they tend to grow exponentially when you add new platforms. Instead, try to organize your source files as a tree with platform-independent code at the root, and platform-dependent code on the "leaves". There is a nice book on the subject, Multi-Platform Code Management. Sample code in it may look obsolete, but ideas described in the book are still brilliantly vital.
Further to Kyle's answer, I would strongly recommend against trying to use the Posix subsystem in Windows. It's implemented to an absolute bare minimum level such that Microsoft can claim "Posix support" on a feature sheet tick box. Perhaps somebody out there actually uses it, but I've never encountered it in real life.
One can certainly write cross-platform C code, you just have to be aware of the differences between platforms, and test, test, test. Unit tests and a CI (continuous integration) solution will go a long way toward making sure your program works across all your target platforms.
A good approach is to isolate the system-dependent stuff in one or a few modules at most. Provide a system-independent interface from that module. Then build everything else on top of that module, so it doesn't depend on the system you're compiling for.
XVT have a cross platform GUI C API which is mature 15+ years and sits on top of the native windowing toollkits. See WWW.XVT.COM.
They support at least LINUX, Windows, and MAC.
Try to write as much as you can with POSIX. Mac and Linux support POSIX natively and Windows has a system that can run it (as far as I know - I've never actually used it). If your app is graphical, both Mac and Linux support X11 libraries (Linux natively, Mac through X11.app) and there are numerous ways of getting X11 apps to run on Windows.
However, if you're looking for true multi-platform deployment, you should probably switch to a language like Java or Python that's capable of running the same program on multiple systems with little or no change.
Edit: I just downloaded the application and looked at the files. It does appear to have binaries for all 3 platforms in one directory. If your concern is in how to write apps that can be moved from machine to machine without losing settings, you should probably write all your configuration to a file in the same directory as the executable and not touch the Windows registry or create any dot directories in the home folder of the user that's running the program on Linux or Mac. And as far as creating a cross-distribution Linux binary, 32-bit POSIX/X11 would probably be the safest bet. I'm not sure what JungleDisk uses as I'm currently on a Mac.
There do exist quite few portable libraries just examples I've worked within the past
1) glib and gtk+
2) libcurl
3) libapr
Those cover nearly every platform and so they are extremly useful tool.
Posix is fine on Unices but well I doubt it's that great on windows, besides we do not have any stuff for portable GUIs there.
I also second the recommendation to separate code for different platforms into different modules/trees instead of ifdefs.
Also I recommend to check beforehand what are the differences in you platforms and how you could abstract them. E.g. this is some OS related stuff (e.g. the annoying CR,CRLF,LF in text files), or hardware stuff. E.g. the previous mentioned posix compability doesnt stop you from
int c;
fread(&c, sizeof(int), 1, file);
But on different hardware platforms the internal memory layout can be complete different (endianess), forcing you to use conversion functions on some of the target platforms.
You can use NAppGUI for both console and desktop apps. The SDK uses ANSI-C and your code will work on Windows/macOS/Linux.
https://www.nappgui.com
It's free and OpenSource.