Introduction

Let’s design our first full Unix-style command line utility. Since a large number of you have had some experience with checking a string for balanced parenthesis or curly braces we will use that idea as a starting point.

Program Behavior

1. What type of input should our program accept?

   A list of files given on the command line, or if no files are given, then read from /standard input/. See ~grep~ as an example.

2. What output will it give and how will it be formatted?

   The C and C++ compiler provides a good example to follow: print the output in an easily parsed, structured formate that contains all the information available:

   file_name:line_number:column_number: description of error

   for example

   test1.c:7:1: unmatched closing brace
   

If there are no balancing errors then the program should not produce any output. [[http://www.catb.org/esr/writings/taoup/html/ch01s06.html#id2878450][Silence is Golden]].

1. What kind of errors might be encountered?

   1. How will our program detect them?
   2. How will our program handle and report them?

Getting Started

Once we have decided how our program should work and have written up some test cases we can start coding. You may choose to use write in C or C++¹

Initialize a new git repository

initialize a new git repo and add a remote

Start Coding

1. Start simple. Write an empty ~main()~ function and compile it.
2. Write a simple Makefile that will compile a program named balanced when make is run.
3. Get in the habit of working in short code/compile cycles. Using ~make~ it is easy to quickly build a project and check for errors. It is usually easier to find and fix compile errors soon after they were introduced into the code rather than waiting until even more lines and potentially more errors are introduced.
4. commit often. git makes commits cheap and easy. Use them judiciously. As a rule of thumb, make a commit each time you make a change that results in a successfully compiling project.

Useful libraries and macros

Remember, when listing library calls that have man page entries I will use the format function(N) where N is an integer cooresponding to the manual section the function is defined in. To view the manual page for fopen(3) you would run man 3 fopen

• C++

  • Data structures

    check out the standard containers provided by the STL.

  • files streams

    The fstream header provides ifstream and ofstream for input/output file streams, respectively. std::cin, std::cout and std::cerr are the streams provided for standard input, standard output and standard error.

    The std::istream::get method can be used to extract the next character from an input stream.

• C

  • Data structures

    you may find the queue(3) macros useful for implementing lists/stacks

  • file streams

    See the manual pages for fopen(3), fclose(3), fgetc(3)

Tips

• If you have trouble understanding how argc and argv are used, try writing a simple program that simply prints out the arguments provided on the command line:

  #include <stdio.h>
  
  int main(int argc, char* argv[])
  {
        int n;
  
        for(n=0; n < argc; ++n)
        {
                printf("argv[%d]: %s\n", n, argv[n]);
        }
        return 0;
  }

  compile it and run it with a few different arguments to see how the argv array works.

The source files should exist in their own git repository, if you change to the directory containing your source files and run ls -a you should see a directory named .git. If not, run git init to initialize a git repository in the current directory. You should only run git init once for each new project.

Push your git repository to the remote at git@ece2524.ece.vt.edu:USER/balanced.git where USER is your git user name.

If you have initialized a new repo but have not added a remote yet:

$ git remote add origin git@ece2524.ece.vt.edu:USER/balanced.git

where is your git user name.

If you have already added a remote named origin, but the URL is incorrect, replace add with set-url in the above command. You can always check that remotes you have added by running git remote -v.

Remember, if this is the first time pushing to a new remote you need to specify a destination branch (usually `master`). Using the `-u` option will save this default destination for future pushes.

$ git push -u origin master

Feature repo path: features/balanced

The following features will be tested using cucumber:

You can run the tests manually with

$ cucumber /usr/share/features/balanced