Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
Can you recommend me what should I read/learn in order to make a well organized code in C?
One of the things I want to learn is the principles of splitting project in .h and .c files, what goes where and why, variable naming, when to use global variables ...
I am interested in books and articles that deal with this specific problem.
A good book that covers a lot of this (for both C and C++) is Large Scale C++ Software Design, by John Lakos:
Also, a good rule of thumb to remember is "Never do anything that allocates memory in a header file"
Regarding the files layout there are not too many alternatives.
The partitioning is typically one of the following (package here is a single library or binary):
.../project/.../package/module.{c,h}
.../project/.../{src,include}/package/module.{c,h} // non-interface headers go to src
.../project/.../package/{src,include}/module.{c,h} // non-interface headers go to src
The partitioning (1) is convenient in that all files belonging to particular package are stored in a single directory, so package can be easily moved around, but with this approach detaching API headers from private ones and detecting API changes is not trivial.
(2) and (3) are very similar, they make API release and API changes detection trivial, while (2) is slightly easier for the case when you always release the whole project and (3) is slightly better when you release individial packages (e.g. for patching purposes)
In any C/C++ project there is typically the following common packages:
Common macros, and data types
Logging package
Application bootstrap package (in case there are
more than 1 binaries in the project).
Specific to unix (and not to c, natch), but none the less:
Recursive Make Considered Harmful
With the build structure described, you can afford to use a lot of files. So each logical unit gets a header and a source file.
I think the best educational reading you're going to get on this subject, is reading something like the Linux Kernel source. It's got a good source layout, and is basically the standard large C project. Here is a guide for how source files should be put together for BSD source, as well.
Seriously, just start reading Kernel source and get a feel for how everything is put together. It's a very well planned project, obviously.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 6 years ago.
Improve this question
I'm beginner C programmer and I have one not very big project in C.
I written simple perl script for building it with different options. And my project wasn't split into object files, I just included .c into each other and built all with one compiler call.
But my project was growing and compilation time reached 1s+ (I like script-style debuging with lot of change little bit && run steps), so I decided to split my project into object files, link them together and use gnu make to check if source have changed, as everyone does.
I expected that this will make building faster. BUT NO! make is so slow, it made compilation even slower several times and I even haven’t split my project completely (one .o per .c file) yet, just in about 5 object files (project has about 20 .c files) !
It even slower or about same time for make to check if files where changed than to rebuild entire project when .c files just included into each other!
So now I just using enhanced version of my perl script "build system". I split project into several big parts and rebuilding only one of them (other are 3rd party libs mostly) and it works very fast. Also it's more flexible and easy to manage for me than makefiles, because I have lot of build option including crosscompiling. But this is reinventing the bicycle.
Having all c files included into each other isn't best practice, yes?
What should I use?
I wanted to name this question "Why make is so slow?" but I know why - launching a shell for every code line is heavy task. Maybe for really big projects it works ok, but for me it has too much overhead.
So what are best practices and tools for managing C projects? What building tools are fast and flexible?
I don't want make-like crap forking on every move, making build slower than naive include-all-into-one-file even if using several cores
I would recommend you try the combination of CMake with the ninja generator.
Ninja is a lot faster than make and CMake makes it easy to configure the project.
http://www.cmake.org
https://martine.github.io/ninja/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 8 years ago.
Improve this question
I have built a small program for plotting data from serial port using Qt and QCustomPlot. I am an engineering student, and I had a project that required me to manipulate data from the ADC of an mbed, so I built this app for my convenience and for experience. I would like to share it with other people who need such a tool (will put it on the mbed website).
I am not a programmer and I do not know a thing about licenses. The QCustomPlot is under GPL. I read that I cannot use static linkage with the GPL licence for QT; I do not intend to, (I will post the source too), but would like to include a statically built version of the program for people who would rather just use the program.
So without going in too much detail, what can I do? Also, do I need to include any disclaimers in my source?
First of all: choose a license for your software. The website http://choosealicense.com can help you in doing that.
Usually a license requires to add a text header to your source code files. This is just a fragment of text which shows the terms of the license right within the source code.
Also, a license.txt file is often required in which the full license has to be pasted. Anyway choosealicense.com clearly explains what to do.
Notice that some licenses (e.g. the GPL) need that a list of changes is added to your source code. This list has to be mantained through the entire life of your software distribution and updated when you provide new releases.
When you are ready with your package use a website like GitHub to distribute it as a source code.
Do not include binaries. Just add the source code and a README file in which you explain how to compile them.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I started a while ago to learn the C language, and has spent several hours I search THE miracle software.
I am looking for software that import sources of software in C (files.c) and generates a "mind map" of the code with all files, functions, variables, etc ...
Do you know if it exists? It'll help me a lot to understand the architecture of complex software.
Thank you very much for all your answers.
Take a look at the "call graph". This sort of visualization should get you started.
As the comment suggests, Doxygen is a good open-source tool. Take a look at some output here. Doxygen is straight-forward to configure for call-graph generation under *nix. It's a little more complex for Windows. First, check out this SO post: how to get doxygen to produce call & caller graphs for c functions. Doxygen's HTML output provides a number of nice cross-referencing features (files, variables, structs, etc.) in addition to caller/callee graphs.
On the commercial side, Understand for C/C++ has first-rate visualization features. Google "c call graph diagram" for other commercial and open-source options.
Finally, there are some older SO posts, like this one Tools to get a pictorial function call graph of code. Take a look at it.
Look into the program ctags. It is an indexer of names and functions based on the structure of the programming language.
It is quite mature, and has integration with a number of other tools. I use it with an older (but very nice) text editor called vi, but it can be used independently from the command line.
It does not generate a graphical view of the connections. However, in my estimation there are probably too many connections in most C programs to display visually without creating a large amount of information overload.
This answer differs from Throwback's answer in some interesting ways. A call graph can mean a few things. One thing it can mean is the path a running program took through a section of code, and another is the combination of all paths a running program might take through the code, and another is the combination of all paths in the code (whether they can be reached or not).
Your needs will drive which tool you should use.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 8 years ago.
Improve this question
I've got a project where I want to do some stuff that would be trivial in bash but where I want/need a binary with has zero external dependencies. So, has anyone written a self contained lib (i.e. not a wrapper around system()) that lets you do bash like stuff from inside C?
Off hand, the things I expect to need are: cp, rm, wget, tftp, ar, tar, guzip and maybe dpkg but I think I can side step that one.
To answer the comments: I'm looking for something along the lines of a statically linked busy-box but where I don't need a shell file as a program for it and where things I don't use automatically don't even get linked in.
You need busybox.
I fully agree with Busybox. Additionally, if you get the source code for dpkg, you'll find a small library inside that gives you access to most of its functionality.
You have a lot of custom requirements, and as you say, you don't want "things I don't use don't even get[ting] linked in", so you're going to have to do a lot of hand-hacking.
If you compile all the external dependencies into object files, you should be able to link them in to your own tool (assuming no namespace conflicts; a big assumption, but not too bad if you're careful), you should be able to do it if you just excise their main() functions.
In fact, for the dependencies, you can probably even just rename their main(), and have the tool available to you as if you were calling it from the command-line yourself, by packing their argc/argv, though this would likely have some overhead, rather than calling the individual functions yourself.
The aforementioned busybox already offers all the features you require (even tar and wget) except for dpkg, and since there's already a lib for that, I'd say you're well on your way.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
We don’t allow questions seeking recommendations for books, tools, software libraries, and more. You can edit the question so it can be answered with facts and citations.
Closed 7 years ago.
Improve this question
I'm after a very tiny XML parser for an embedded project. It needs to compile down to 10-15k, doesn't need to validate, and needs to be simple and portable.
I was able to tweak the compilation flags of the following XML parser libraries for C, and cut down more than 50% of their size on my Ubuntu machine. Mini-XML is the only one close to what you requested:
Mini-XML (36K)
Expat (124K)
RXP (184K)
There's a good discussion here:
C XML library for Embedded Systems
I was searching for one recently and I found SimpleXML (http://simplexml.sourceforge.net/) and the slightly larger sxmlc(http://sourceforge.net/projects/sxmlc/)
I find SimpleXML more interesting because it's simpler, I didn't try it but it looks like it matches what I have in mind, a single file(well .h and .c) library that doesn't support exotic XML features.
The simple XML parser is a tiny parser for a subset of XML (everything except entities and namespaces). It uses a simple "one-handler per tag" interface and is suited for use with devices with limited resources.
Try yxml — it's really small and fast non–validating parser.
You can always roll your own implementation. I did this a few years ago, and just now added some interface documentation to the code at mercurial.intuxication.org/hg/cstuff.
Please note that the parser has never been used in a production environment or even been tested more than rudimentarily; comments are non-existent as well, so have fun grokking the code if you need to modify it ;)
I developed sxmlc ("Simple XML in C") exactly to be like that: as little files as possible. It's only one file, with an optional "search" file you can add if you need XPath-like search through the document.
It handles DOM-style loading (the whole document tree in memory) or SAX-style loading (calling callbacks whenever a node is read with its attributes, or text was read on a node). If memory is a concern you'll be interested in SAX.
Some people were also interested by the fact that it can parse either files or memory buffers (useful when you get XML as a web reply).
It handles Unicode files since version 4 through #define, so if you don't need Unicode, just don't define the SXMLC_UNICODE and there won't be any weight increase in the binary.
I also have to say it keeps comments when writing back XML to disk! I always felt sorry when people spend time explaining configuration syntax in XML files ("put 'true' to enable special compression..."), which are wiped when saved back by the application.
It compiles under Linux and Windows. I had good feedback from people happily embedding it in routers.
As I want to keep it as simple as possible, I will probably not add new functions but rather improve the existing ones (and correct bugs, of course! :)). I am not very active in its development, unless bugs are reported.