Iar C C++ Development Guide For Arm

[Adele Strecker]

Idecided to leave my windows install behind and am now running Debian as my default OS. I have always coded in Windows and specifically with Visual Studio. I am currently trying to get used to compiling my code under linux.

Although I still have a lot of documentation to read, and don't expect you guys to make it too easy for me, it'd still be nice to get some pointers on where to start. I have some specific questions, but feel free to suggest/recommend anything else regarding the subject.

Looking at other linux software, they almost always seem to have a 'configure' file. What exactly does it do? Does it only check if the required libraries are installed or does it more than just checking requirements?

It's a script usually used to set up various things based on the environment being used for building. Sometimes it's just a basic shell script, other times it invokes tools like Autoconf to discover what is available when building. The "configure" script is usually also a place for the user to specify various optional things to be built or excluded, like support for experimental features.

How do I link libraries, and how does this relate to my makefile or g++ parameters? In windows I would compile the library, include some header files, tell my linker what additional lib file to link, and copy a dll file. How exactly does this process work in linux?

ld is the GNU linker. You can invoke it separately (which is what most makefiles will end up doing), or you can have g++ delegate to it. The options you pass to g++ and ld determine where to look for included headers, libraries to link, and how to output the result.

Recommendations for code editors? I am currently using nano and I've heard of vim and emacs, but don't know what the benefits of them are over eachother. Are there any others, and why would I consider them over any of the previous three? Note: I am not looking for an IDE.

Vim and Emacs are very flexible editors that support a whole bunch of different usages. Use whatever feels best to you, though I'd suggest you might want a few minimal things like syntax highlighting.

Creating make files by hand is usually a very unportable way of building across linux distro's/unix variants. There are many build systems for auto generating make files, building without make files. GNU Autotools, Cmake, Scons, jam, etc.

The configure file is usually associated with autotools. As the name of the script suggests, it allows you to configure the software. From the perspective of the developer this mostly means setting macros, which determine variables, which libraries are available, and such. It also tests for the availability of libraries. In the end the script generates a GNU Makefile, which you can then use to actually build and install the software.

The GNU build system is only one of many. I don't particularly like the GNU build system as it tends to be slower than others, and generates an ugly Makefile. Some of the more popular ones are CMake, Jam (Boost Jam might be of interest for C++) and waf. Some build systems simply generate Makefiles, while others provide a completely new build system. For simple projects writing a Makefile by hand would be easy, but "dependency checking" (for libraries, etc) would also have to be done manually.

Editor: vim and emacs are popular. What matters the most, as with most tools, is to master one. I like using vim because vi (its descendant) is available everywhere, but that may not be very relevant, specially if you stay on Linux. Any programming editor is fine.

configure: unless you do big projects, don't bother with it. It is a nightmare to use and debug. It only makes sense if you intend to distribute your project - in that case, read the autobook: As other said, there are alternatives (cmake, scons, etc...). I am quite familiar with both scons and autotools, but I still use make for small (couple of files) projects.

Concerning shared library: it is almost as windows, except that you link against the shared library directly - there is no .lib vs .dll distinction in Linux. For example. for one library foo with a function foo:

So to get you started I will first point you to this guide for makefiles, it also covers some linking stuff too.

It's just a little something my university Computer Science prof gave us I found it to be very clear and concise, very helpful.

And as for an IDE, I use eclipse usually because it handles the makefile as well. Not to mention compile and standard output are right at your fingertips in the program.

It was mainly intended for Java developing, but there is a C/C++ plugin too!

Vi and Emacs are the two quintessential Unix editors; if you are set on using a text editor rather than an IDE, one of them or their derivatives (vim, xemacs, etc) is the way to go. Both support syntax highlighting and all sorts of features, either by default or via extensions. The best part about these editors is the extensibility they offer; emacs via a variety of lisp, and vim via its own scripting language.

EDIT [Dec 2014]: There seems to be a trend of cross-platform and highly extendable editors recently. This could be a good choice if you'd like something less than an IDE, but more graphical than vi/emacs and native-feeling across multiple platforms. I recommend looking at Sublime or Atom; both of these work across Windows/Linux/Mac and have great communities of plugins and themes.

For editors, you probably want either Vim or Emacs. They are both different and which one is better is more about personal taste than anything else. I use Vim. It is great for quickly moving around the code and making changes. I didn't like Emacs as much but many people do. Emacs is extremely extensible and can be used for everything from a news reader to an ide. Try both and see what you like.

If you're using Linux with a window manager (KDE, Gnome, etc.) you could also consider using the standard text editor for your window manager. The main benefit it would have over vim/emacs/nano is that it would seem more familiar to one coming from a Windows environment - an editor written to run on the window manager has a menu bar, file open/save dialogs, undo/redo, and plenty of other neat features that console editors probably can't match. (Though emacs and vim are pretty sophisticated these days, so who knows ;-P)

On KDE (which is what I use) I can recommend KWrite, which is a well-featured but fairly basic text editor with syntax highlighting; or Kate, which is a fancier text editor with some extra features: session management, a builtin terminal panel, automatic invocation of make, and several plugins including a C/C++ symbol viewer. I usually use Kate for my C++ work when I don't want to bother with setting up a full IDE project. (FYI the IDE for KDE is KDevelop)

the space between invoking g++ directly and using an autotools build chain is pretty narrow. Get good at autotools, which is really the closest thing to a 'project' available in the Linux/Open Source world.

For someone coming from Visual Studio, all this commandline stuff might seem arcane and messy.Before you turn into a bash shell/vim/emacs junkie, try a few GUI based tools first so you have some transition time...

I'm sure the longhairs will scoff and claim that vim or emacs gives them the best and fastest development environment, but different strokes for different folks. Someone accustomed to an IDE will take some time to switch or may not wish to switch at all.For all their editing prowess, creating GUI apps is certainly not a job for 80x25 tools.It takes years to become an expert with the command line side of things, its more of a transformation of worldview than anything else.

I advise using SCons in place of Make, it does the same job but it's easier to use and handle out of the box how to make dynamic libraries, dependencies, etc. Here it is a real life example for a simple prog

C++ is one of the main development languages used bymany of Google's open-source projects. As every C++programmer knows, the language has many powerful features, butthis power brings with it complexity, which in turn can makecode more bug-prone and harder to read and maintain.

The goal of this guide is to manage this complexity bydescribing in detail the dos and don'ts of writing C++code. These rules exist tokeep the code base manageable while still allowingcoders to use C++ language features productively.

Style, also known as readability, is what we callthe conventions that govern our C++ code. The term Style is abit of a misnomer, since these conventions cover far more thanjust source file formatting.

There are a few core goals that we believe this guide shouldserve. These are the fundamental whys thatunderlie all of the individual rules. By bringing these ideas tothe fore, we hope to ground discussions and make it clearer to ourbroader community why the rules are in place and why particulardecisions have been made. If you understand what goals each rule isserving, it should be clearer to everyone when a rule may be waived(some can be), and what sort of argument or alternative would benecessary to change a rule in the guide.

The intent of this document is to provide maximal guidance withreasonable restriction. As always, common sense and good taste shouldprevail. By this we specifically refer to the established conventionsof the entire Google C++ community, not just your personal preferencesor those of your team. Be skeptical about and reluctant to useclever or unusual constructs: the absence of a prohibition is not thesame as a license to proceed. Use your judgment, and if you areunsure, please don't hesitate to ask your project leads to get additionalinput.

3a8082e126