CS220 Summary

"In America we stopped using corporal punishment and things have never been better. The streets are safe, old people strut confidently through the darkest alleys and the weak and nerdy are admired for their computer programming abilities." -- Homer J. Simpson

While taking a closer look at the foundation of C++, the C programming language, we delved deeper into the fundamental concepts of programming such as

• pointers
• complex declarations
• memory layout
• code generation
• efficiency
• etc.

C has been accused of making it easy to shoot yourself in the foot. Hopefully, you have learned some ways to avoid it. (Or at least walk away...)

Below are some fundamental and high-level points regarding C.

C is a subset of C++

• Everything we've done in CS220 can be used in C++.
• C++ is more about high-level abstractions than the lower-level details.
• You can use C without C++, but you can't do the opposite. (You can like C without liking C++, but you really can't like C++ without liking C.)
• The first homework (Bits.c) would have been 99% the same in C++:
  • BinConverter.h
  • BinConverter.cpp
  • A driver

It's very difficult to gauge performance without knowing what code the compiler generates.

• All compilers are different.
• A compiler's main task is to generate assembly code from source code.
• Most compilers can optimize their code generation.
• Look at the assembly code to better determine the efficiency of your source code.
• In Microsoft Visual C++, to produce a listing file, add a /FA or /FAs switch to the Project Options.

  Visual Studio.Net:

  

  Visual Studio 6.0:

  

Set the compiler warnings to the maximum level whenever possible.

• The compiler is your friend.
• Don't ignore warnings; if necessary, change your code to suppress warnings.
• Use pragmas if necessary to suppress "safe" warnings.
• Don't check-in code that contains any warnings or errors. It makes it difficult to find the "important" warnings from the "safe" warnings.

Don't assume all computers are little-endian.

• Endianness is a function of the CPU, not the operating system.
• Windows runs mainly on x86-compatible CPUs (Intel and AMD), which are little-endian, but others are in widespread use:

  Processor Family           Endian
  ---------------------------------
  Pentium (Intel)            Little
  Alpha (DEC/Compaq)         Little
  680x0 (Motorola)            Big
  PowerPC (Motorola & IBM)    Big
  SPARC (Sun)                 Big
  MIPS (SGI)                  Big
  

• Binary files (e.g. graphics, sound) shared between computer systems may need to account for this.
• Networking code will definitely force you to deal with this. (By definition, networked computers are sharing data between computers.)

Computer memory is just a bunch of 1's and 0's.

• It's up to the programmer (you) to interpret these bits.
• You can't tell the "value" of a bunch of bits without knowing the type they represent.
• Don't be afraid to cast bits to specific data types to make them easier to manipulate.
• Know and use the bitwise operators for maximum efficiency.
• Document your code liberally when you are writing "cryptic" code.

The compiler hides a lot of pointer arithmetic.

• This doesn't absolve you from knowing how it works.
• At times, you will need to do the math yourself (not the compiler).
• Array subscripting is just a convenient way dereferencing the addresses associated with each element.
• Accessing structure members is also like array elements in that the member's offset is dereferenced by the compiler.

• The compiler must know the size of the elements of each dimension if it is to perform the pointer arithmetic. If it doesn't know the sizes, you have to do the math.
• It helps to think of all arrays in C as having one dimension. (e.g. A 3x4 array of integers is really just a single dimensional array where each element of the array is an array of 4 integers.)

Write code for the long term.

• Most code is in maintenance mode its entire life. "It's only new until the ink dries."
• Documentation and testing are equally as important as "coding" the solution. If you don't have time to document or test your program, you might as well not waste time coding anything.
• Ninety percent of the coding errors can be discovered with simple testing.
• It will be far easier to understand your own code (or someone else's) by reading the documentation, rather than trying to figure out the code.
• Choose a coding style and documentation style and be consistent. Use a tool to automatically generate documentation for your code. (Doxygen, Doc++, ccDoc, Doc-O-Matic, DocJet, etc.)
• Link to documentation, if necessary
• Understand which parts of your program must be efficient. Don't micro-optimize your code and don't try to optimize until you've proven that the inefficiency negatively impacts the program.
• Make sure the program works before attempting to tweak or optimize it.
  1. Correctness
  2. Readability
  3. Compactness
  4. Performance
• After your code works, refactor it to achieve points 2, 3, and 4. Most first-attempts at implementing an algorithm are rarely ideal. Don't stop at step one.