1

Preamble (Skip if you don't like to read)

I've been learning C/C++ in school for a year now and all the assignments in the book, after reading through the chapters, were not too difficult to implement. Some examples of programs I've written are abstract data types like binary trees, queues, stacks, lists, and other types of programs were palindrome searching, encrypting and decrypting files, and other similar first-year type programs. As stated, after reading the chapters, I was easily able to implement and understand the algorithms used to solve many of the problems. So I feel comfortable with the syntax and logic of these small manageable problems.

Background (You can skip this part)

In preparation for my transfer to UCSD in the fall, I installed Linux on my machine and switched to using Vi -- definitely a change from Visual Studio. To keep my mind sharp and venture into real-world programs, I decided to download the source for a famous Linux console utility called Wget (http://www.gnu.org/software/wget/), with the intentions of re-writing the program as a C++ object-oriented version. The challenge I am facing is the program, while being a simple single-purpose utility, is still quite enormous when staring at the code.

...The Question (You CAN'T skip this part)

How does one begin to look at a program they didn't write and study it in order to try to re-write it, change it, etc? I guess I'm looking for advice/guidance on a divide and conquer type approach to studying a program written by other people in order to try to re-write it. I understand massive programs like OpenOffice, the Linux kernel, Gnome, etc. don't fall into this "I'm going to re-write them" sort of thinking. But small utilities I would imagine do.

gnat
  • 21,442
  • 29
  • 112
  • 288
  • Why are you shooting yourself in the foot by using vi? Get a full featured IDE like KDevelop (if it's still around) or maybe even Eclipse. Also, what you're doing is very commendable! – James May 30 '12 at 00:03
  • @James I thought the same thing at first, but now that I've been using it for a while, it's actually awesome! –  May 30 '12 at 03:56
  • @James: fhaddad78: Though vi is much better at text editing than any IDE, it can't compile your projects and open an error window. Try vim or gvim instead. These are vi derivatives which add support for that feature. Vim comes included with most Linux distributions; gvim is also sometimes included and is even better. – unforgettableidSupportsMonica Nov 05 '12 at 23:10

2 Answers2

1

I think a really good approach is to study any unit tests that are in the system. Unit-tests, by definition, only focus on one (usually small) section of the code in isolation. This means you can work through the unit test suites and understand the code one module at a time.

If there aren't any tests (or not enough), you can try to write them yourself. This is an even better way to learn the codebase since you have to directly use it. Again, because it's unit tests, you are really focusing on a small unit of code, which helps compartmentalize your study of the source code.

Oleksi
  • 11,874
  • 2
  • 53
  • 54
  • 2
    Thanks for your answer and explanation of unit-tests. I looked in the src directory and found a file test.h which is exactly what you described. (= I will definitely look at that first. –  May 29 '12 at 15:52
0

I wouldn't call wget a small utility. It can communicate over several different protocols, has numerous command-line options, features very robust (and tuneable) error handling, etc. It only looks simple because the designers must have put a lot of thought and effort into making it easy to use.

As for your issue of understanding a project, learn to appreciate find and grep. Also, I've found that I can understand what a program is doing just by running it through strace and (occasionally) ltrace. If you really want to get your hands dirty, look at the commit logs in the version control, but that's a bit extreme.

chrisaycock
  • 6,655
  • 3
  • 30
  • 54
  • Thanks for the answer. I kind of know how to use grep. I use it very basically at the moment. E.g. find 'main(int argc' main.c when I'm searching for a function or some other text. I'll have to read up on strace and ltrace. –  May 29 '12 at 15:54
  • 1
    When looking at other people's code, I use `find . -name "*cpp" | xargs grep FunctionName` all the time. – Gort the Robot May 29 '12 at 16:03
  • @StevenBurnap Wow! "find ... | xargs ..." is powerful! Thanks for that. –  May 29 '12 at 17:09