2

Is there a good 'how-to' or 'getting started' guide for getting started using g++ and gdb?

Some background. Decent programmer, but so far I have done everything on Windows in Visual Studio.

I have a little experience using terminal to compile files (not much beyond a .h and 1 or 2 .cpp). But nothing beyond that.

Anyone know of a good primer on on how to get started coding on Linux?

Taylor Huston
  • 1,104
  • 3
  • 15
  • 31
  • 1
    You might want to ask for clarification on the no "IDE" rule. IDEs are used on Linux just as much as in Windows. If you're allowed to use an IDE on Windows, it doesn't make sense to not be allowed to under Linux. – Nikos C. Oct 23 '12 at 02:46
  • 1
    This isn't really the place to ask these kind of questions, but I will give you this link to point you in the right direction. http://www.youtube.com/watch?v=keWNLqW31r4 – CalMlynarczyk Oct 23 '12 at 02:47
  • Another link to get started: http://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html – Nikos C. Oct 23 '12 at 02:48
  • @NikosChantziaras I like your link better. – CalMlynarczyk Oct 23 '12 at 02:50
  • 3
    @NikosChantziaras: I suspect that the point of the restriction is to force people out of the IDE bubble so that they experience what it is that the IDE is hiding from you (and deciding for you). This can be either traumatic or liberating, depending on your perspective. As someone who has never programmed professionally within an IDE (unless you count `emacs`) I personally believe the latter. – Dale Hagglund Oct 23 '12 at 05:09
  • 1
    @NikosChantziaras: I never use any IDE for C or C++ or MELT programming. I only use `emacs`. And most GCC contributors don't use any IDE, so you can code under Linux without IDEs. – Basile Starynkevitch Oct 23 '12 at 06:35
  • Just do as you are told: Learn `vi`, `make`, `gcc` and `gdb` and your done for the first round. Then go for learning `sh`, `grep`, `sed` and `awk`. – alk Oct 23 '12 at 06:43
  • And btw @other commenters: I'd consider `emacs` being at least a 'sort of' IDE. – alk Oct 23 '12 at 06:49
  • I'm sure you'll be looking for an editor. Others have already mentioned emacs and vi. Coming from a Windows world you might like the Geany editor. If you're willing to spend a little money I've always been a fan of [SlickEdit](http://www.slickedit.com/). Welcome to the world of *nix! I made the switch in 1998 and haven't regretted it once. – Benny Hill Mar 29 '13 at 21:42

2 Answers2

4

Read some good books, notably Advanced Linux Programming and Advanced Unix Programming. Read also the advanced bash scripting guide and other documentation from Linux Documentation Project

Obviously, install some Linux distribution on your laptop (not in some VM, but on real disk partitions). If you have a debian like distribution, run aptitude build-dep gcc-4.6 gedit on it to get a lot of interesting developers packages.

Learn some command line skills. Learn to use the man command; after installing manpages and manpages-dev packages, type man man (use the space bar to "scroll text", the q key to quit). Read also the intro(2) man page. When you forgot how to use a command like cp try cp --help.

Use a version control system like git, even for one person tiny projects.

Backup your files.

Read several relevant Wikipedia pages on Linux, kernels, syscalls, free software, X11, Posix, Unix

Try hard to use the command line. For instance, try to do everything on the command line for a week or more. Avoid using your desktop, and possibly your mouse. Learn to use emacs.

Read about builder programs like GNU make

Retrieve several free software from their source code (e.g. from sourceforge or freecode or github) and practice building and compiling them. Study their source code

Basic tips to start (if a command is not found, you need to install the package providing it) in command line (in a terminal).

  • run emacs ; there is a tutorial menu; practice it for half an hour.

  • edit a helloworld.c program (with a main calling some hello function)

  • compile it with gcc -g -Wall helloworld.c -o helloworld; improve your code till no warnings are given. Always pass -Wall to gcc or g++ to get almost all warnings.

  • run it with ./helloworld

  • debug it with gdb ./helloworld, then

    1. use the help command
    2. use the b main command to add a breakpoint in main and likewise for your hello function.
    3. run it under gdb using r
    4. use bt to get a backtrace
    5. use p to print some variable
    6. use c to continue the execution of the debugged program.

  • write a tiny Makefile to be able to build your helloworld program using make

  • learn how to call make (with M-x compile) and gdb (with M-x gdb) from inside Emacs

Learn more about valgrind (to detect most memory leaks). Perhaps consider using Boehm's GC in some of your applications.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • If he's very new to unix in general, some of the advanced books you mention (although very good) might be a bit much. Quite a few years ago I spent an hour or two in the bookstore reading _Unix for Dummies_ and I was pleasantly surprised. It's old (circa 2004) but at its level I doubt too much has changed. – Dale Hagglund Oct 23 '12 at 06:43
  • +1 for the Bash scripting guide recommendation alone. All good recommendations here. – Benny Hill Mar 29 '13 at 21:44
3

You've got a lot of things to learn. I won't give you details, but as someone who's done unix and c/c++ development for a couple decades now I'll try to give you some topics to start with.

My main advice is to start experimenting. Write the most trivial program you can in C or C++ (something that prints "Hello there, world!" is traditional) and figure out how to compile and run it from the command line. Then, once you've got a compiled version, start it up under the debugger and play around with breakpoints, printing expressions, etc, etc. Once you've got this simplest program up and running and you sort of understand what the debugger is telling you, add a class, function, struct, or whatever else feels like a good small step and go through the cycle again. You'll proceed much faster this way than if you start with a very large program.

Still at a very high level, here are a handful of topics you'll need to figure out at least a bit about. Note that the "learn by starting small" approach works well for any of the topics below.

  • Running g++: it has pretty good online documentation for the command line syntax, and although you're bound to find it intimidating at first, try to look for the simplest starting point.
  • Find a text editor to use. Vim and emacs are traditional (and very very powerful) but both have a relatively steep learning curve. If you have someone around to help you, that's so much the better. There are other alternatives, but as an emacs user myself, I'm afraid I'm not that familiar with them.
  • Get familiar with gdb. It's an incredibly powerful tool for understanding your program. Again, it has extensive online documentation that will repay close reading.
  • Some familiarity with standard unix commands will be useful: ls, cd, and moving basics of the navigating unix directories; grep for quickly searching source files.
  • You'll have to get used to the command line approach versus the ide approach. The former is the traditional unix developer model, where you put together the operations you want from a collection of other tools, rather than having the ide hide most of this knowledge from you.

If your project is multi-file, and especially if it's a full-semester project, you might also consider learning something about the following topics.

  • Make is a tool for describing how to compile and link a multi-file project so that you don't have to remember how to do it by hand each time. Make, unfortunately, has a well-deserved reputation for being tricky to use, but this is mostly true in very large projects spanning multiple directories, and there are probably good simple examples online.
  • I would strongly consider making use of a source code control system such as git or hg, even for a few relatively small project. It's so much safer to have an archived version of what you've done so that you can back up quickly. Both git and hg are overkill for a small one-shot project, but they are worth learning on their own. Conventional wisdom as I understand it today is that they're very similar in philosophy and core functionality, but that hg is definitely a bit more consistent at the command line level, and therefore easier to start with.

I suspect this is rather intimidating, especially if you've got effectively no exposure to a unix command environment before. I re-emphasize my first piece of advice above: learn by starting simple and experimenting. This minimizes the amount of new stuff you're having to wrap your head around at any given point in time.

Dale Hagglund
  • 16,074
  • 4
  • 30
  • 37